Getting caught up in cognitive biases is itself an example of a problem that interferes with our productivity. It doesn't strike me as a useful view of the big picture, other than the realization that perhaps software engineering is all about balancing these sorts of conflicting factors. E.g., know when to experiment, quick and dirty, and now when to go deep in refactoring.
Editor magic is overrated. I learned on vim and was proficient in it, but over time discovered productivity was higher by just using dumb navigation.
Every editor feature I need to think about is some feature about the problem I'm working on that I need to forget.
I would like to add a couple more - I'd be interested if either of these has a name:
* Assuming that complexity is additive.
* Assuming that complexity of an extension to a piece of software is proportionate to the difficulty of imagining such an extension.
I love it when my initial assumption that an imagined new feature would be a complex and painful refactoring exercise only to find out that a few lines of change was all that was required!
Those days I almost feel like the universe has purpose.
I would agree it helps to become aware, but I honestly don't know how to mitigate any of them. It seems like all of them involve predicting the future. I don't know what payoff I'm going to get if I learn vim's wacky and hidden keyboard commands, and the payoff isn't likely to be large if I avoid using vim whenever possible.
Hyperbolic discounting seems like a generally good bias to have - unless I have a very specific bet in mind or the big payoff is an obvious benefit to me or a requirement of some kind, then choosing quick wins is probably the right choice more often than not.
Premature optimization seems like almost the exact opposite of hyperbolic discounting, and avoiding premature optimization feels like the right decision the majority of the time.
But I never know for sure which one was actually the right choice until long after the decision has been made. I've certainly optimized things that didn't need to be, and I've certainly gone for quick wins and regretted not planning for a bigger payoff.
>If you’ve ever worked for a company that used a dumb internal tool rather than a better out-of-the-box solution, you know what I’m talking about.
This is probably not what the author is talking about, but there is a valid case for "inferior" in-house tools or libraries this overlooks. In some cases a suitable off the shelf component exists, but is an over-generalised, over-complicated black box with the associated disadvantages. If this component is an important piece of your product or business, and you only need a fraction of the functionality provided by the off the shelf one, then it can be preferable to create an in-house version to gain simplicity, focus, insight and control.
As i'm sure many people have experienced the opposite of "dumb internal tools" in the form of frustratingly buggy and unpredictable off the shelf components, when these problems are too broad to reconcile with upstream contributions it's sometimes worth creating a less-capable "inferior" internal version more suited to your use-case.
For example pretty much everybody who has to use SAP, Navision or other such tools. Especially when it comes to upgrading all the local little modifications to the next service release, gah!
Real problem is that you are forced to use Vim.
For a long time it was the only decent code editor for terminal. Vi is still default editor on many distros.
f1()
for element in array {
f2()
}
for element in array {
f1()
f2()
}