The Scientific Method and Value-based Software Engineering - A novice take

Why do we struggle to be excellent engineers in corporate? From my view, talking to quite a few people in the same space as me, I get the impression that, although ‘Corporate’ is where many innovative solutions come from, a large majority of individuals that I’ve spoken to have complained and ranted about the amount of friction they’ve experienced getting something through and out of this machine. This article will attempt to break it down within my immediate and limited context based on my observations (be warned though, this might not be as objective as the title might suggest).

Simplify mundane thing A if you want to do valuable thing B

TL;DR: Let’s invest in simplifying mundane things to enable us to deliver more valuable things.

Of Igloos and Ice-sculptures

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.

A team grounded in reality is where dragons go to die.

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.

Apple Liquid Glass - I get it but I don’t think it will work - yet

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.

John O’Hara’s QCon Keynote - A Growth Checkpoint

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.

AI/NLP. Evolution of Compilers? - Part 1.1 - Interesting questions and my thoughts

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.

AI/NLP. Evolution of Compilers?

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’.

Growing Up in Engineering - A checkpoint on the way to being a 'grown-up' engineer

Tl;dr - It is a necessary condition to be empathetic, the sufficient condition is to ask the right questions and challenge the right things.

An Acknowledgment - Anxiety, my Tumultuous Friend

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.