It’s winter! Well, it’s winter from quite some time but I actually felt it this week with regular snow and white roofs and roads. I hope you’re keeping warm and bundled in. I’ll get to my learnings this week.
Shame on you
This week’s Brain Science podcast was about shame. There was nothing strikingly new here for me but it was the little parts that reminded me of the words I need to choose when talking to people every day. I try to be careful with the words I use to describe situations or events. It becomes even more important when I talk to my children. They might forget a word I might speak in anger or frustration but the feeling is much more difficult to forget, and that terrifies me.
Which is why it is important to think about the feelings of shame–specifically, the feeling of incompetence or lack of worth. There’s a reason why we are programmed to feel ashamed (evolution, of course). But that is less and less important today. Like with everything, the trick is to find a balance between being a pushover and being narcissistic. And like with everything where balance is necessary, it is incredibly hard.
Combined arms
We all may be doing something for a long time without realising what it’s called. When we find someone talking about that concept with a name and you realise you have been doing that all this time, you begin to see it a different light. You now have a tool with which you can find more information about what you have (probably) internalised. With that information, you can further improve that practice. Names are powerful.
This is what happened to me this week when I found this term “Combined arms” while talking about software. I only had to skim through the Wikipedia article to see that we do this every day at work. There is also a contrasting term–”supporting arms”–which can be used to describe some of the other behaviours I see at work. For example, the development and the QA team would work on a task sequentially, which is the “supporting arms” strategy. Whereas, a single task might need the teamwork of a backend engineer and a frontend engineer, or different numbers thereof. Them working in coordination is an analogy of “combined arms”.
Now, I have worked in this style for years (over a decade in fact). I have internalised how I do this. But learning about this term helps me think of this approach in a different light. This, at the very least, will help me be more deliberate about my actions.
Management 3.0
Software has taken over the world. Nothing affirms that more than seeing version numbers used for things that have existed long before the software industry has. I found a meetup group in Mississauga called “Agile Dialogue Mississauga” and their upcoming meetup titled “Management 3.0“. As cliched it sounded to me, I still planned to go because I was happy it wasn’t in Toronto. I also wanted to see what it was all about. After all, you need to have a corny name to stand out in today’s content-rich world.
I am glad I went because under the corny name of Management 3.0, it is a set of practices that I identify with very much. From what I could see before the talk started and in my conversation with people who were attending, I thought I could have just given a talk on how we work at Axelerant. I was gratified on the validation of our practices at Axelerant. Just like what I said in the “combined arms” section above, seeing all our practices under the name of Management 3.0 gives me a way to think about it and improve further.
What I learnt from the meetup and subsequent reading from the website is probably a subject of another blog post. Check it out if you’re interested in management and leadership.
Boring Technology
I have long heard of how the term “boring technology” is used nowadays (in a good way). But I guess I never bothered to check it in depth. I attended a talk called “Thoughtful infrastructure” at a meetup this week. There, the speaker made a case of the MVP, i.e., build only what needs to be built, nothing more. I will probably talk more about the talk in a separate post but I will talk about the “boring technology” aspects here. Coincidentally, another talk at the same meetup touched upon that and I then read the original essay and the talk as well.
The boring technology I use on a daily basis is Drupal. It is my responsibility at work to keep excelling at it and that can be a challenge. It is difficult not because Drupal is hard, but because it has matured and the problems are left to be solved elsewhere now. I share this with people in my conversations and proudly say that Drupal is one of the boring technologies. Now, I have learnt the formal method of describing it.
The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.
– Boring Technology
Drupal can certainly do a lot better in being more user-friendly to those new to it. But collectively, we understand how Drupal works and its failure modes. With years of experience on Drupal, it is quick and easy to fix it whenever there is a problem. Further, this experience is being carried over with Drupal 9, thanks to semantic versioning.
Faster Docker builds
There is a good chance that I get invites to a few webinars every week. I attend some of them hoping to learn something new but it has always been a mixed bag. That is why I didn’t have much hope when I received a virtual meetup notification for faster Docker builds. I missed it but thought of watching the recording. If it could make even a small difference to my Docker image builds, it was worth it. I was both right and wrong. There was something entirely new to learn and I am excited to try it, but I don’t think it will make a significant difference in my case. Still, every bit helps.
The improvement is mainly for multi-stage builds in Docker in parallelizing them. This is done using a new engine called BuildKit and can be switched on using an environment variable. Setting DOCKER_BUILDKIT=1 for the docker build context uses the BuildKit engine which supports a lot more features including parallel builds for multi-stage builds, secure handling of secrets during the build, and even a different way for cache warming (useful if you have several Docker daemons). The meetup also covered some tools like goss (for testing images) and trivy (for scanning images). I am hoping to try them in my builds soon.
A lot of small things
There are also a lot of smaller things I learnt but I can’t write enough about them to make their own section.
- Embarrassingly Parallel: Used to describe problems which are very easy to solve in parallel.
- Apache Beam: Batch and stream processing system with multiple runners.
- Cupcake analogy for software: Just another name for the MVP paradigm. This highlights the nature of a small solution which is still complete–contains cake, frosting, and even sprinkles.
- Personal Map (in Management 3.0): Something similar to a mindmap but describes you. This is very similar to manager READMEs I have written.
That’s it for this week. I don’t know if I will be able to write a post next week given my schedule. If it doesn’t work out, see you the week after.
Leave a Reply