My perspective on this has always been one of capability driven platforms/systems. If you’re building platforms in a team, it’s crucial to understand that how you build can’t be driven from just one side of the team (the ends of the sides being capability drivers and implementation drivers - or classically Business Analysts and Software Engineers).
It’s been a year and 1 month to date (as of me writing this) as a Lead Engineer (aka squad lead/team lead/senior engineer, whatever you prefer to call me). It’s also been a little while since I last wrote about anything useful. The reason for that is I’ve been getting my ass kicked by the role.
When I started out as a grad, I was super into whitepapers. I couldn’t get enough of reading them. I always dreaded the day that I would inevitably succumb to a more senior career where many people had told me that I wouldn’t have time for such things. Today I can proudly and relatively say that they were wrong. That time never came, and to this day, I cherish the time I set aside in my day to pour through a good research paper. With that context, I’ve decided to start a yearly tradition where I mention things that I am looking forward to in the new year. In this particular article, it would be things in my software engineering career that I hope to be enjoying with glee in the coming 12 months - baring any radical changes to world order that force me to follow my Plan B - becoming a coffee barrista at a mountain lodge somewhere.
TL;DR: Let’s invest in simplifying mundane things to enable us to deliver more valuable things.
TL;DR: (Just this paragraph is generated by ChatGPT - the rest is my shpeel) The author compares the journey of becoming a skilled software engineer to building igloos—practical, experience-based, and essential—and later, to crafting ice-sculptures—elegant, expressive, and technically intricate. After years of chasing deep technical mastery, they shift focus toward a more balanced and fulfilling growth path that values both competence and creativity, while embracing self-awareness, joy, and the human side of development.
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.
I’ve grown tired of saying EDA and then immediately getting shot down because people think Event-Driven Architecture is just Event Sourcing (which I agree is an implementation pain in the ass most of the time). Herewith is the simplest form of an EDA implementation that the limitations of my skill and experience with them allows for.