TL;DR - Good engineers deal with reality. We bring concrete, practical, and real implementation to precisely architected solutions that solve for value. We need to remember that this doesn’t change no matter what gets thrown our way. We are a sect of craftsman/woman of the reality in our business - and reality is where dragons go to die.
Yet. At least in the short term. This title is slightly click bait, but my thoughts are more scattered and boring here so I need to at least make it seam controversial to hold you through this article. Although, calling it out probably defeated the purpose.
TL;DR: As a technologist, taking point on projects is dangerous not because you might not be up to the task, but because you have an impact beyond the technology. Anyone can learn to write code and build stuff, and yes, I also believe that over time anyone can learn to build stuff well. However, it requires a deep fundamental change in oneself to take on the mantel of leading humans.
I posted an article from my blog on my LinkedIn a little while back (see the post here) and I had a colleague ask 2 super interesting questions. Herewith my attempt to answer them.
Considering recent trends like so-called “vibe-coding” and the amount of tension around these seemingly “hands-off” exercises in creating solutions, I have some naive and simplistic thoughts (as usual). In this article I attempt to break down the wild and complex ways us humans share information and, with many a stretch, compare us humans to computers (hah! what a funny comparison, but bear with me). As a side effect to me very happily nerding out on foundational computer science concepts, hopefully, I can somewhat convince you that we’re seeing an evolution of what we know as a ‘Compiler’.
Tl;dr - It is a necessary condition to be empathetic, the sufficient condition is to ask the right questions and challenge the right things.
I acknowledge you, oh one who’s urge keeps my senses sharp. The one that burns my idle being into action. You who keeps me alive in the face of danger.
Over my relatively short tenure as a software engineer so far, I’ve had a few thoughts on how to deal with “efficiency” and “maintainability” across multiple facets within my teams’ estate. It’s lead to a useful4 rule-of-thumb1 when trying to design/make decisions about systems in a way that balances efficiency and maintainability.
We often hear (at every bloody interview) about the SOLID Principles. It’s regarded by some as the major driving force of good software. But why do so many engineers get (at the very least) 1/5 of the principles wrong at a fairly consistent rate?
A little while back, I came across a beautiful concept on the Software Engineering Radio podcast. The topic was Managing Dependency Freshness which spoke about how we could better manage dependencies within and beyond our software systems. the concept that caught my attention however, was “Api’s as Dependencies”.