Hacker News Reader

Comment by wilbowaggins | Hacker News Reader

Some of these feel to be just beginner/expert. Like the one about optimization. Beginners are the ones to try optimizing everything

View on HN

This one threw me off as well because the common "middle of the curve" advice is to avoid "premature optimization", but then you get experts that talk about "non-pessimization" as an euphemism for writing optimal code.

Same with the "technical debt" one. The midwit opinion is that you should take it on in the short term so it can be paid off by the business later on. But experts tend to just want to do the right thing(s) faster because they have the capacity to do so and don't sacrifice future speed towards often unjustified short-term goals.

IIRC, the midwit opinion was the original idea of technical debt. To you, is the beginner/expert version a misuse of the term, or has the thinking on technical debt changed?

Basically I wouldn't say that the idea of taking on technical debt in order to pay it off at a later date is beginner or expert. It's simply the norm within most businesses.

The expert probably goes deep on some problems and punts on others depending on how intractable or voidable they might be in future, but I wouldn't say there is a hard/fast rule they can apply. Also, I suspect they probably avoid the worse technical debts you get in weaker teams, so even if they appear to leave technical debt in some cases these are rarer or mitigatable. We can look at their actions instead of their words to see what side of the divide they are truly on...

0: Don't optimize anything, it's too difficult, just hack on the code until it produces correct answers without regard to performance.

1: Optimization takes time, so optimize the critical sections (by choosing appropriate algorithms + data structures) and don't worry about the rest.

2: Don't optimize anything, just write code naturally. The libraries your code calls into are already fast enough because they're written by experts.

3: Optimizing makes code more complicated, so only optimize the critical sections (e.g. with vector intrinsics or atomic memory operations).

4: Just write the code naturally and avoid writing any slow code.

You could create many Twitter-appropriate bell-curve images out of a single real-life distribution of skills/experience.

Beginners may try to optimize some things, but by fact of their newness, don't even understand the extent to which they can optimize.

Think of the futility of ex-FAANG engineers who try to implement similar technology (e.g., reproducible and declarative build systems) at a 10-person startup.

Reply on news.ycombinator.com