How good engineers write bad code at big companies

I think this is worth exploring. Not shoving the details of work in people's faces to assert its quality, but somehow creating some drama or interest in its quality. In a way compatible with the immediate practical needs.

This isn't an easy problem to solve. And the example of a boutique Japanese restaurant is a good one. In this case, the process is designed to make consuming the food, the immediate practical problem, more satisfying.

Perhaps the code equivalent, would be seeing changes in sequence, where each change is obviously well done from the user's and manager's perspective. A process more easily achieved by green field work. Which is also relevant to the restaurant example, where each dish is its own creation (within a well thought out process).

A $20 IKEA chair is not "bad furniture". It's just optimized for different constraints than a Herman Miller. Most consumers are totally happy with the $20 IKEA chair.

An underrated part of engineering skill is knowing what corners to cut. I think large tech companies have structures that impose this on engineers who view this as dereliction of duty.

The flip-side is: you need the money more than your employer needs you. Which puts you in a bad position to negotiate salary, makes it hard to stand-up against bad decisions, etc.

I think that it can (not sure if the author meant this) also mean that you have a buffer and are OK with switching jobs, but are also in a position where your employer wants you (because of something you can do). This puts you in a GREAT negotiation position.

From the perspective of the organization that pays you to do it, it is? At best there may be another mission that it genuinely cares about, usually there’s only a profit motive (which is also fine). If you want to create software as an end in itself or enjoy the craft without compromise, it usually can’t be in the context of a job or a business

Our job is to produce the best possible outcomes given the constraints we’re faced with, and inform leadership so that they’re aware of the tradeoffs when they make their decisions. Sometimes those decisions are going to be bad, and obviously it’s justified to be frustrated then. Other times they are correct, even when it means compromises on the engineering side. That’s when we have to just suck it up (or go elsewhere)

I still think there’s room for enjoying the work of creating software even under imperfect conditions. Striving for perfection is for hobbies, or the very rare circumstance when it’s justified by the goals of the organization

Bad, over-complicated code is code that requires you to form an unnecessarily detailed mental model of it in order to answer a particular question you may have about it.

People rarely read code in its entirety, like a novel. There is almost always a specific question they want to answer. It might be "how will it behave in this use case?", "how will this change affect its behaviour?" or "what change should I make it to achieve this new behaviour?". Alternatively, it might be something more high level, but still specific, like "how does this fit together?" (i.e. there's a desire to understand the overall organisational principles of the code, rather than a specific detail).

Bad code typically:

* Requires you to read and understand large volumes of what should be irrelevant code in order to answer your question, often across multiple codebases.

* Requires you to do difficult detective work in order to identify what code needs to be read and understood to answer the question with confidence.

* Only provides an answer to your question with caveats/assumptions about human behaviour, such as "well unless someone has done X somewhere, but I doubt anyone would do that and would have to read the entire codebase to be sure".

Of course, this doesn't yield some number as to how "complicated the code is" and it depends on the question you're asking. A codebase might be quite good on some questions and bad on others. It can be a very useful exercise to think about what questions people are likely to seek answers for from a given codebase.

When you think about things this way, you come to realise a lot of supposedly good practices actually pessimise code in this sense, often for the sake of "reusability" of things that will never be reused. Dependency injection containers are a bête noire of mine for this reason. There's nothing wrong with dependency injection itself (giving things their dependencies rather than having them create them), but DI containers tend to end up being dependency obfuscators, and the worst ones import a huge amount of quirky, often poorly-documented behaviour into your system. They are probably the single biggest cause of having to spend an entire afternoon trawling through code, often including that of the blasted container itself (and runtime config!), to answer what should be a very simple and quick question about a corporate codebase.