U gebruikt een verouderde browser. Upgrade uw browser om deze site correct weer te geven.

Things I believe about software engineering


Having spent my moderate effort and a non-trivial amount of time building software, there are some things I've come to believe about software engineering. Inspired by posts like this one and this one, I write down my current beliefs not because I know them to be immutable, but because I like the idea of looking back in a few year's time to see what's changed. It's a write-up without context or nuance, meant to trigger thought more than to illuminate it. Enjoy!

  • Fatigue flatlines productivity.

  • Disruptions flatline productivity.

  • 'Increasing productivity' is when you take focus-starved people and through having them work longer hours create fatigued and focus-starved people.

  • Keeping disruptions to a minimum does more for productivity than the choice of language or framework.

  • Yet you can remember the last time you debated technology selection.

  • There is a culture of contempt coursing through the industry that incites flame wars, damages inclusivity and is, frankly, quite tiresome. I apologise to all PHP developers.

  • Estimates at small scale are useless because the uncertainty is much bigger than the project.

  • Estimates at large scale are useless because a breakdown is a best-case scenario and the unknown unknowns remain surprisingly unknown.

  • Outside-in estimates work, but nobody bothers with those because 1) it's hard to get the data you need, and 2) people happily resolve to outperform expectations by the sheer power of their can-do mentality. Go team!

  • Ability in years of experience is a laughably poor indicator of skill.

  • Yet there is no substitute for experience: An expert programmer in his or her domain is incomparably faster and less error-prone.

  • Listing all the tools and technologies your company has ever worked with on a vacancy is a disservice to your hiring practice.

  • Distrust anyone who advocates a rewrite.

  • If a rewrite is clearly the best option, distrust yourself.

  • For any non-trivial problem, actively try to reject your first solution.

  • At no point will your codebase embody your coding standards.

  • Once every while you will learn something that completely reshapes your understanding of code or reframes a subset of problems in a way that you cannot unsee.

  • Refactoring a meaningful piece of code that's not covered with tests is like a surgeon carefully operating with a kitchen knife.

  • A SaaS adaptive machine learning on the blockchain serverless augmented reality IoT progressive web-app unicorn start-up? Such wow!

  • Nothing is required for success except mediocre skill and mediocre effort, following a clear goal for a non-trivial amount of time. And marketing.

I'd love to talk more indepth about all of these, but that would defeat the purpose of this post. When I look at the list I notice that the don'ts dominate the do's. That's more than just a matter of wording: between naming a problem and solving it, the first is often the easier of the two (except when debugging). I believe there are real issues that our profession has to find answers to. But I also believe the sheer joy of applying solutions to a domain, and delivering value to people through the software we write more than compensates for any of them.


We gebruiken cookies en vergelijkbare technologieën om de gebruikerservaring te verbeteren en om content te leveren die relevant is voor onze doelgroepen. Afhankelijk van hun doel, kunnen analyse- en marketingcookies worden gebruikt naast technisch noodzakelijke cookies. Door op "Akkoord" te klikken, verklaart u akkoord te gaan met het gebruik van bovengenoemde cookies.