Ask HN: What mental models you found useful in delivering impact as an engineer?
I hear people talking that it takes more than great programming skills for an engineer to be successful (particularly at fast moving tech companies). As an engineer, I have learned certain mindsets that have helped me do better in my work. For example: 1) an average to a problem well understood can potentially deliver bigger impact than a great solution to a problem poorly understood, 2) not all problems are worth solving and ability to prioritize them in terms of impact is a core skill, etc.
What mental models have you found useful in your career as an engineer? Or if you're not an engineer, what mental models you think engineers need to have to deliver bigger impact?
1 comment
[ 4.2 ms ] story [ 13.8 ms ] threadThese things come with experience over time, but the fact that you've made it far enough to ask the right questions in the right place to ask them is 90% of the journey.
I realize this sounds cliche, but I can't stress enough that health comes first. I would make the following a priority if you feel you're not taking as good care of yourself as you should:
Eat reasonably healthy (just avoiding junk food is enough, no need to go overboard)
Get enough sleep (and eliminate whatever habits get in the way of that) - Without enough sleep, your mind will in subtle ways try to put the least amount of effort toward doing things. This is especially dangerous if you are trying to counteract those effects with things like caffeine or stronger stimulants.
Don't do anything stupid to harm your body. Contrary to popular belief, you are not a Zerg mutant with infinite bodily regeneration capabilities. It will catch up to you sooner than you think it will.
It's quite hard to improve one's mental habits when not in the best shape (but if you fucked up early on like I did, it's never too late to make things better).
Assuming you're already doing all that, I'll speak specifically to your post:
1. Don't burn yourself out, especially for a job you don't enjoy.
Not a mental model per se, but more of a disclaimer that I highly advise against pursuing such efforts unless you feel the company is a good fit for you. I've personally found that being successful at a company depends as much on the company as it does you. All the talk about culture fit applies here (though I personally hate the terminology). Sometimes you can adapt to environments that are challenging, but sometimes that can be a case of learning bad and toxic habits. And sometimes, no matter how much better you think you perform, it won't improve your job security. So you have to first understand whether you're really happy in that environment. Don't burn yourself out to try to get ahead of the technical debt curve just to try to earn some job security in an environment that you don't feel at home with in the first place.
2. Document what you're going to do, and why, before you start doing it.
This doesn't mean you can't amend the plan when you see a reason to, but your technical changes should be driven by your written plan, and nothing else. If you don't do this, the complexities of the technical systems you're touching will bleed into the mental model you've set for yourself with what you're trying to build. You'll exert subconscious effort to try to maintain some grounding, but inevitably you'll slip at some point and end up doing too much or too little changes. Then you may exert significantly more effort trying to explain to your peers or boss why you spent extra time building something that has no apparent need, especially these days with the plague that is Scrum (fragile, not agile).
You don't necessarily have to do this for all of your work, but deviating from this procedure should be the exception and not the rule.
3. Avoid band-aid workarounds
Always fix the root cause! Always! Okay, there are times when this is not possible. Sometimes, the root cause is part of a piece of legacy software that can't be modified easily or at all. Sometimes the problem is with a closed-source library, an API, or data feed from external partners. It's okay to do workarounds in those cases, but you should be extra vigilant for the pros and cons of doing it. Make sure the business, not just your Scrum Lord, is getting a real benefit from seeing it done. In any case, when doing a workaround, it's wise to include detailed documentation in the appropriate places as to why that workaround exists, or it will contribute to the pain, suffe...