Notes after 7 years as a software engineer

Wed, 30 Sep 2026 19:43:56 +0300

1. Knowns and unknowns are not always straightforward

Donald Rumsfeld spoke about three categories of knowledge: known knowns (things we know we know), known unknowns (things we know we don’t know), and unknown unknowns (things we don’t know we don’t know). I’ve personally found this paradigm very useful in software engineering.

My first projects as a software engineer were pretty similar, in the sense that they were SaaS products that we hoped would gain traction but never really did. That meant I got good at making software that worked pretty well as long as there wasn’t too much traffic or unusual usage of the app. Having this as your only experience as an engineer is particularly bad because, firstly, even your known knowns come with a question mark. Does this software work because of me or despite me? The tools we use (runtimes, databases, frameworks, etc.) are so good that they can absorb mistakes up to a point without many downsides. Secondly, if your system isn’t under enough pressure and not enough things go wrong, you can’t even begin to really discover known unknowns and unknown unknowns.

The first project where there was real pressure on my code was when I built and released three microservices to 1 million+ users. Even before I deployed anything, there were stress tests in place that put pretty much every line of my code under scrutiny. Naturally the code I’ve wrote was nowhere near ready to support the required throughput.

This experience helped solidify the knowledge categories I mentioned earlier. Known knowns now have a huge asterisk next to them, as they are provisional, which means they may or may not hold true in this new context. Unknown unknowns also begin to properly form as a category of knowledge. Doing stress tests for the first time can lead you to issues you never thought possible. This not only converts unknown unknowns into known unknowns but also solidifies another core idea about tackling harder/newer problems: you will always have a set of unknown unknowns that need to be discovered (either proactively or reactively).

2. The cognitive surrender to LLMs is scary

It seems like software engineers (and many others) are finally getting a taste of Lisanne Bainbridge’s automation paradox. The better a machine is at automating work, the more you depend on humans to supervise it for the rare situations where it cannot regulate itself, but now humans never get the chance to practice the skills required to intervene.

This goes even beyond deskilling people, into realms where people don’t even get to the point of being skilled in the first place. Given the competitive nature of our society, which starts in school, refusing to use any available advantage will leave you behind. But proper, productive use of LLMs is really hard as long as you feel pressured to produce immediate results regardless of the long-term cost. This basically leaves people, from a very young age, with the complex responsibility of using LLMs with enough balance that they don’t get left behind and don’t lose their capacity to reason and develop skills of their own.

Bainbridge pointed out decades ago that automation raises the bar for the humans overseeing it rather than lowering it, and there’s no reason to think LLMs are an exception. LLMs have lowered the bar for producing code and raised it for everything else: supervising, judging, and knowing when the output is wrong. Improper use of LLMs, bordering on complete cognitive surrender, cannot produce individuals capable of supervising what is basically a super-machine.

3. There is a lot of value to be added from properly applied scrutiny

A big part of an engineer’s time is spent evaluating information that comes their way. Doing this properly can prevent lots of issues:

Code reviews: preventing improper or incorrect code from getting merged
Scrutinizing tasks before doing them: avoiding wasted time, added tech debt, and unclear trade-offs
Properly vetting an interview candidate’s stories and CV: avoiding bad hires
Vetting a more senior engineer’s proposal like any other: sometimes the most senior engineers need that vetting the most, because most people will just assume they are right and that it is useless to try to review their work, thus making it harder for them to spot issues proactively
Evaluating LLM output while knowing its limitations: LLMs fundamentally make statistical predictions based on a very large dataset that is impossible to curate perfectly (simplified pre-training) and on human preferences (simplified post-training). They will make (confident) mistakes.

This part of engineering is not safe from lots of psychological phenomena: assuming things are true, assuming somebody else will point out that they’re not, agreeing with something in order not to upset somebody, etc. It can also become unproductive when you start nitpicking everything, going to the other extreme from taking everything at face value. So it is not meant to be trivialized. Getting better at this involves more than just pure cognition/logic. It requires awareness and practice to improve on the psychological biases we have. It also requires us to constantly work at maintaining a healthy balance of scrutiny.

All in all, there is a lot of value engineers can add by properly scrutinizing incoming information. You have the power to catch a variety of problems early, before they become a lot more expensive to fix. And a lot of the time, it only involves asking clarifying questions.

4. We are all vulnerable to unexamined assumptions

As software engineers, we are expected to solve problems without knowing exactly how everything is supposed to work. Bridging the gap between product and working software is non-linear and involves ambiguity that we are expected to handle. This inevitably leaves us with two fundamental ways of working: based on presumptions (an educated guess based on probability or evidence) or based on assumptions (an uneducated guess with no rational foundation). Sometimes we have no choice but to work based on assumptions because we simply have nothing to rely on, and that’s OK as long as they’re explicit. But one particular flavor of assumption is really dangerous: the unexamined kind.

Unexamined assumptions can come from lots of sources: being overwhelmed at work, being more tired than usual, working on autopilot, confirmation bias, etc. It’s unreasonable to expect ourselves to always reason through everything we do perfectly, but it’s still good to keep this in the back of our minds. The cost of acting on unexamined assumptions can be pretty high, ranging from a huge waste of time to actual damage to the system or company. This vulnerability we’re all exposed to is another reason why everyone should have their scrutiny hat on.

5. Every piece of communication adds either clarity or ambiguity

Every time you know something to be true or false and say “maybe,” “it should be,” or “I think,” you pass up a chance to make something clear, and instead you leave it ambiguous for no proper reason except protecting yourself in case you’re wrong. This doesn’t mean you should sound certain all the time. It means you need your words to match what you actually know.

Code works the same way. Every line either reads naturally or makes the reader’s brain work harder than it needs to: a vague name when a precise one exists, a giant expression crammed into one line, control flow that makes you dizzy.

In isolation, each case might not seem all that relevant, but do not underestimate how much vagueness adds up over time.

6. Politics are inevitable in groups of people

Going from coding as a hobby to working for a business is a completely different experience. Coding becomes a means to an end. Everyone has their own personal goals, biases, frustrations, etc. Every department (management, engineering, product, etc.) naturally trivializes the others, because everything seems more straightforward from the outside. Resources are limited, so competition and politics naturally become part of companies. This fundamental truth will not change based on our emotions towards it.

7. Every system is a compromise shaped by messy reality

If something has enough complexity and constraints, you can bet any solution you come up with will be based mostly on compromise. You will hire from a limited pool of available candidates who will never perfectly match your budget or your technical and cultural requirements. The time and resources you’re given are never a perfect fit for the needs of the project. Whatever perfect system design you come up with will gather technical debt and deviate from best practices. Plans, people, and deadlines will change unexpectedly.

This helps remind you that you are not planning and executing for some ideal scenario in your head, but for real life, which is unpredictable and imperfect.

Posts on Robert Dordai