We are creatures of habit
We are creatures of habit. By repetition, may it be willingly or unintentionally, we add new actions, reactions, ways of thinking... habits come in so varied ways.
Some habits take time to acquire; Some people say you need 60 days of repeating something for it to become a habit... or was it 61 times? I love those off-by-one errors even outside of software development 😂 Anyway, you get the point: they don't simply suddenly appear and "now you have it".
Habits can be good and healthy: For example, thanks to the COVID-19 house confinement (which lasted 2.5 months in Spain) I've introduced myself into meditation, and now have the habit of doing it first time in the morning almost every day. Regarding development, as an example I've been an avid fan of practising the pomodoro technique as a way to maintain focus while working.
But we sadly can also merge bad habits to our lives.
I've always disliked open offices, mostly because of the noise they help spread and the education in silence that employees need when working in such a wide space. Yes, I do have noise cancelling headphones since 2010 or 2011, and many times listening to electronic music gets me into the zone and boosts my coding speed, but I also like sometimes to enjoy the sound of silence. And that is almost impossible in any office nowadays.
And is not just a matter of some noise, is more of an issue of constant interruptions: "Did you read the Slack I just sent you?", "Hey, just in case you didn't saw the email invite and Google Calendar reminder, I come to your place to remind you about that incredibly [irrelevant] meeting everyone including you should attend!", phone calls, mobile phone notifications, a colleage speaking on the phone right next to you, somebody screaming somewhere loud enough you can hear it even without pinpointing the source...
To provide specific metrics, I am still not able to do more than 5 or 6 50-minute pomodoros in a single 8h work shift (not cheating, any distraction means you reset the timer). And I'm usually regarded as a very focused person by my colleagues. I don't think so many people suddenly have ADD (Attention Deficit Disorder) magically. I think is just that, with so many distractions, we've created the habit of doing single-core multitasking (quickly doing context switching, and thus partially losing focus). "Just answering that email and going back to the task", "just replying xxxxx's chat", etcetera. Not counting if you check your phone with each notification, then I simply wonder how anybody can even reach a state of concentration at all.
The good news is that almost, if not all, bad habits, can be also nullified. Sometimes it is hard, because for example a toxic environment is harder to fight than a self-created "fake need". But sometimes it is easy, as eating healthier (you just start removing crappy food and slowly adding better substitutes, and doesn't feels hard to progress). But I believe that it is always in our hands, somehow, a way out of any bad habit. Even if it means a drastic change.
It took me some vacations and one month to be again almost in total control of my attention when coding. Now, most of the time I am the one choosing to check the phone only either then the pomodoro is over, or while the code is compiling, the server starting or some other task that I can't avoid waiting for. And many times, it is actually more interesting to keep reading article X or one page of book Y.
Book Review: Sams Teach Yourself Java in 21 Days
Review
Title: Sams Teach Yourself Java in 21 Days, 7th Edition
Author(s): Rogers Cadenhead
I had three premises while searching for a next read: 1. I needed to learn some Java, because I know some, but university level 2. I needed to target at minimum Java 8 3. I wanted something that covered a broad spectrum of the language, while not being way too entry-level
I decided to go with this book because it covers Java 8, it starts simple but covers everything regarding language fundamentals, and it goes into more "advanced" topics like threading, sockets and web requests. It also strikes a good balance between teaching you about a topic without becoming a reference book that lists every single method, parameter and overload of every class available (which can be useful, but not for initial learning).
I must confess I skimmed through the chapters about Swing and Java2D, RSS and Android. I want to do backend-related development so I don't need Swing (and it looked similar to back when I learned it) and the other topics were interesting examples but not of my interest right now.
I was pleased to see that Java now has channels, generics and lambdas, and the book does a good job of explaining them simply and clearly. I had fun writing some of the book examples and altering them a bit, or doing some tiny refactors here and there.
If I had to complain about something, it'd be that the code sometimes can be improved: There are too many examples in which all (sometimes really heavy) logic is done inside the class constructor, constants are mentioned but never used afterwards, variables are created a bit chaotically, sometimes inside loops and the like, and variable namings are reminiscent of old C days (in, buff, pw, ...). But even with that the code purposes are nice and easily understood.
Google Meet vs Skype on Tethered 4G
During last April I've had to work via my phone's 4G data tethering. I did quite a few code pairing sessions with colleagues each week, and after feeling that Google Meet wasn't working good enough I decided to try Skype (which has quite a few years of focused product building behind). These are my findings.
As I was on 4G, I was probably under a very limited output bandwidth. I had no issues on the reception/input side (nor from the video-conferencing technology at least), but output was poor and the main the reason why I tested alternatives and kind-of measured them.
Most sessions were 1h non-stop meetings, of 2 participants + shared desktop (VS Code, Pycharm, OSX terminal, so not so many moving pixels). I always had OSX Activity Monitor open with the Network Info tab and, while I didn't wrote down the exact numbers of every session, I had plenty of sessions to compare both approaches until I had a decent internet connection again.
Data consumption
Google Meet: ~200 MB input data, ~50 MB output data.
Skype: [50,100] MB input data, [75, 100] MB output data.
Perceived audio quality
Google Meet: Good input, unstable output, sometimes ok, sometimes poor.
Skype: Good input, good output.
Perceived visual quality
Google Meet: Initially unstable input, but "settles down" and remains good meanwhile there's no application switching (e.g. between terminal and IDE). With movement clearly appreciable compression blocks. Same with output.
Skype: Excellent input (almost no compression noticed), good output.
Quality settings
Google Meet: Lowering the video quality to 360p only works if there's not much screen movement, else it feels we're back in the nineties with blocky compressed MPEG videos. Skype: There are no options as Skype handles video quality, resolution, etcetera automatically, and for once it simply works.
Conclusion
Meet is very convenient and good for normal meetings, presentations (without animations/videos, else is awful), team dailies and the like.
Skype has amazing visual quality and overall smaller data consumption without perceived data loss.
Still, whenever possible I prefer to use Live Share for VS Code so there's no need to stream a whole screen.
Book Review: Site Reliability Engineering
Review
Title: Site Reliability Engineering
Author(s): Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy
There are some resources that you know you must read, even if it is a steep ascent. Considering that this title is freely available, that it contains so much good ideas, tips, and practices that many people won't ever put half of them in practice, and that it is a big book (around 500 pages), it is hard to complain about it. But still, I'd like to start with my only complain: Most of the book feels like a bunch of academic papers grouped together, often under a common topic, but sometimes even overlapping in the contents despite being at different chapters and book parts. It's not been an easy book to read because it can get dull at times, up to the point that I stopped reading it halfway, and retook it recently and decided to finish it.
That said, everything else is so interesting. Even if sometimes we're not exactly told how their internal systems work, Google SRE teams authors explain enough techniques, procedures, ideas and advices to create tickets for years of work at any medium or large sized company that has more than a few services in production. From recommending monitoring everything, placing retries and circuit breakers, or explaining their "production readiness requirements" SRE guidelines, to less often heard concepts like "given enough requests per second, a simple random load balancer strategy can perform better than a round robin one", or how Google in some services employs an initially counter-intuitive practice of, in case of high latency, discarding the newer requests instead of the older ones (while also always discarding those that have been waiting for more than X seconds). Tons if ideas of how, what and when to monitor, log, alert, automate, improve, fix, and a myriad of related actions you can take related with services, tasks, teams, scenarios... Just take a look at the table of contents to grasp the sheer amount of topics it covers.
I marked some internal highlights but if you want some really hardcore and useful notes, I can only encourage you to check the in-depth review at danluu.com/google-sre-book/. Every chapter except the final SRE team management and integration ones is summarized.
But even the management final chapters are useful, explaining why interruptions are bad, how to deal with them and mitigate them, how to collaborate between teams, how, when and why to meet...
As I mentioned before, not the easiest book to read but definitely one that most engineers, SREs or not, should read.
Unsung Heroes
It's been quite a while since I started working in tech. I've been in tiny startups, medium companies, and a few big companies; I've done both in-house development and consulting services, the later sometimes outsourced to clients for long periods; I've both seen from within workforces grow and adapt to change, and landed into already well-oiled machinery (theoretically at least).
You learn to recognize some people patterns, some archetypes, that typically either are already present or appear sooner or later. The superstars known in the community, the quick learners, the slower but methodical thinkers, the still-junior-but-will-be-awesome profiles... Some of these people will step forward and also help with the technical outreach, often by becoming speakers and/or participating in local user groups. But there will always be a subset, maybe just shy, maybe just not interested in public spotlight, that in any case won't shine so publicly (and sometimes even internally if the company is big enough), and yet get work done and sometimes achieve great things not expecting any ego boosting public recognition.
They don't speak at conferences, they might not have a blog, Twitter or any "social presence", or if they do they use it rarely... They just work, just focus on doing things the best they can. They usually excel and get great evaluations, and any time you ask about them to a colleague, the answer will always be positive. And if you speak with or, even better, directly work alongside them, you will always learn something new.
Those are the heroes who save the tech world, one company at a time. Those are the people I'm trying to emulate as of late.
Previous entries