There's no accounting for taste
Future-proofing your career as a software engineer
Programmer’s log. Epoch time 1751221677. London heat is no joke. Even an entire childhood in the swamps of Florida still did not prepare me for the stuffiness of London summers. Yes, there is definitely the urban heat island effect that absorbs extra heat. But the apartments flats here trap hot air and stubbornly refuse to release it. We needed to purchase an air circulator fan just to get a cross-breeze going through our living room…
Happy Sunday!
This is part two of my explorations of AI-assisted code on the tech industry. You can check out part one here.
There’s no accounting for taste
Future-proofing your career as a software engineer
Looking ahead to the future of programming that increasingly involves LLMs, it’s becoming clear that the most important thing for software engineers to cultivate is taste. As I discuss in GenAI is not a silver bullet, training great software designers will continue to be the essential challenge of the industry at large. The opinions and style of these humans is what will distinguish great software from mediocre as the cost of outputting the code itself continues to precipitously drop.
What is engineering taste
Even though we’re still in the early days of AI-assisted software development, we are already seeing a big gap who can most effectively leverage LLM tools. Senior engineers can consistently get more long-term value by deftly minimizing autogenerated bad code through best practices and technical discipline.
Non-engineers and less experienced developers often hit a wall at 70% of a project because they lack of knowledge and inadvertently create mounting tech debt. Minor mistakes can compound into a terrible mess of a codebase. And even if the code itself might work, it can suffer from fundamental limitations in the chosen architecture. By its very nature code is not self-healing and is prone to software rot, so much so that most of the work of software engineering is actually maintaining legacy code to ensure that systems don’t actively degrade.
Unfortunately there is no easy shortcut to upleveling to a senior engineer.1 While many of the elements of high quality technical craft can be learned through study, there is a certain intangible intuition that can be only gained through lived experience.2
This kind of expertise is even reflected in our technical jargon. Typically, engineers use language that is concrete and often obnoxiously precise. But inevitably there are vague problems that have equally squishy terms. Systems can have “code smells” and proposed solutions don’t pass the “sniff test”. Even inexperienced developers can detect these suspicious patterns, but they don’t know enough to determine if it’s a real problem or how to fix them. Advice like YAGNI and YAGRI are obvious, yet can be easily dismissed unless you have deeply internalized these lessons. These principles eventually are drilled into your psyche from repeat struggles with overengineering or missing logging context.
Even worse, there are entire classes of software patterns with hidden footguns. Steven Sinofsky, who led Office and Windows divisions at Microsoft, lists engineering patterns that sound good but almost never work as intended. The design choices themselves are not flawed, but there is vastly more nuance and complexity than appears on the surface:
I offer this recognizing engineering is also a social science and what works/does not work is context dependent. One life lesson is that every time you say to an engineer (or post on X) that something won’t work it quickly becomes a challenge to prove otherwise. That’s why most of engineering management (and software architecture) is a combination of “rules of thumb” and lessons learned the hard way.
Senior engineers are not just differentiated for their ability to churn out a high volume of code. They can also draw on a deep well of experience building software with a large group of people. This experience is crucial understand how theory actually gets translated into reality, since previous success with the identical tools and architecture may not lead to same outcome in a new environment. Engineering disasters still happen at companies even despite hiring a lot of smart, experienced people to work together. As Mike Tyson once said, “Everybody has a plan until they get punched in the mouth.”
…
(Click here to read more)
📖 Links and books
Here’s some recent fantastic reads:
Five years of home-cooked apps (Robin Sloan)
Making games in 2025 (Noel Berry)
Un Kyu Lee, creator and designer of the Micro Journal (The Write Keys)
Why Tokyo bikes more than NYC (Dispatches from Post-growth Japan)
Falsehoods programmers believe about aviation (Angle of Attack)
This is not my side hustle (starbreaker.org)
California hummingbird beaks transformed by feeders (The Guardian)
Myriad (Tulips) (Anna Ridler)
I am listening to Moral Ambition by Rutger Bregman on audiobook. I just finished reading Biting the Hand by Julia Lee.
That’s all for now! See you later alligator 🐊
