5 ms·

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

rckrd 4y ago
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.
resonious 4y ago
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.
- lhnz 4y ago
  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.
  - shadowofneptune 4y ago
    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?
    - lhnz 4y ago
      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...
- jmillikin 4y ago
  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.

rckrd 4y ago

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.

resonious 4y ago

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.

lhnz 4y ago
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.
- shadowofneptune 4y ago
  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?
  - lhnz 4y ago
    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...
jmillikin 4y ago
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.