Absolute rules in engineering

2026-07-21T08:30:00.000Z

LinkedIn is full of absolute rules for engineers, very few of which are actually absolute.

Over the last few months I’ve been reading more technical posts there, and I’ve started to notice a pattern.

It’s very easy to come across strong, confident advice from people with impressive profiles, large followings, and many years of experience. The kind of posts that say things like “never do this”, “always avoid that”, or “this technology is a bad idea”.

Sometimes the advice is good. Sometimes it’s oversimplified. Occasionally it’s just wrong or at least wrong outside of a very specific context.

Engineering rarely deals in absolutes.

I’ve seen long discussions about limiting the number of function arguments to future-proof code, blanket statements about languages being unsuitable for embedded systems, and claims about design techniques causing problems that only occur if they’re used in a particular way. In most cases the real answer is the same as it’s always been: it depends on the constraints.

The more systems you work on, the more you realise that rules which make perfect sense in one environment don’t always survive contact with another.

That doesn’t mean the people writing these posts don’t know what they’re talking about. It usually just means their experience comes from a different set of problems, with different trade-offs.

It’s a useful reminder, especially for those of us who’ve been doing this a long time, to stay cautious of absolute statements, including our own.

Good engineering judgement isn’t about knowing the rule.

It’s about knowing when the rule doesn’t apply.