
Ask HN: What mental models you found useful in delivering impact as an engineer? - um304
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.<p>What mental models have you found useful in your career as an engineer? Or if you&#x27;re not an engineer, what mental models you think engineers need to have to deliver bigger impact?
======
Nuzzerino
_(sorry for the formatting, I haven 't gotten the hang of HN's formatting
syntax yet and wrote this freeform without much proofreading)_

These 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, suffering, and
burnout of future members of your team. While this can happen to companies of
any stage or size, the real danger zone here IMO lies with companies in the
Series B range, as hacky throwaway code could be done with no consequence
before then, and is even somehow encouraged by some as a best practice for
early stage companies.

The other major exception to this is emergencies, involving downtime,
prevention of downtime, or other significant operational incidents. However,
meeting the deadline for your Scrum sprint is not an emergency. If your boss
can't be convinced to understand this, your choices are to do a better job of
convincing, invite them to convince you otherwise (they may succeed!), or to
find another place to work. If something is time-critical for business
reasons, it's your product manager's job to inform you of that.

If your job feels threatened even slightly by the concept of missing sprints,
then you must make it a priority to resolve that, because even the presence of
that feeling is itself a good reason for the job to be at stake, as it's
indicative of critical communication problems with your immediate team. And it
most likely isn't your fault but rather just a failure of the team as a whole
(though you have the most power to do something about it regardless of the
root cause). It is a growing pain that can be solved, as long as you're not
working with assholes.

There is one time where this no-bandaid rule must be broken when you are short
on time, but you should work to avoid having ever happen in the first place.
If the business you work for (via CEO, PM, whoever) is mandating a hard
deadline for a given feature, then you probably should err on the side of
getting it done ASAP. If you are in this situation, don't panic. See if you
can work it out with your team to spend time after the release to ensure that
technical debt is manageable and things are working reasonably smoothly after
some code polish. You can prevent some of these scenarios in the future by
having a maintainable codebase, and you get a maintainable codebase by
reducing technical debt, and you minimize technical debt by not implementing
band-aid solutions to appease Scrum Lords. To put it simply: Business
deadlines are real, but Scrum deadlines can amount to a hoax. Refer to this
article to see Scrum actually addressing this problem:
[https://www.scrum.org/resources/commitment-vs-
forecast](https://www.scrum.org/resources/commitment-vs-forecast)

Another thread/post regarding technical debt:
[https://news.ycombinator.com/item?id=19850629](https://news.ycombinator.com/item?id=19850629)

4\. __Maintain Good Relations and Build Influence __

Building influence will make it easier to succeed in virtually all tasks, big
or small. I can 't recommend quick wisdom on this one, but could point you to
a few good books (or audiobooks if you prefer). Takes years to learn this. I
personally prefer to allow time to digest and sleep on the knowledge gained
from books, though others (notably Bill Gates) swear by the method of binge
reading.

[https://www.amazon.com/Influence-Psychology-Persuasion-
Rober...](https://www.amazon.com/Influence-Psychology-Persuasion-Robert-
Cialdini/dp/006124189X)

[https://www.amazon.com/48-Laws-Power-Robert-
Greene/dp/014028...](https://www.amazon.com/48-Laws-Power-Robert-
Greene/dp/0140280197)

[https://www.amazon.com/Principles-Life-Work-Ray-Dalio-
ebook/...](https://www.amazon.com/Principles-Life-Work-Ray-Dalio-
ebook/dp/B071CTK28D)

[https://www.amazon.com/Extreme-Ownership-U-S-Navy-SEALs-
eboo...](https://www.amazon.com/Extreme-Ownership-U-S-Navy-SEALs-
ebook/dp/B0739PYQSS)

I decided to spend a good chunk of time writing this as I start a new job
which I really hope to be successful at, and I want to reinforce and review
what I think will lead toward that goal. But I hope this is found to be useful
to others too.

