Thread by @dan_abramov

I think how people deal with this feeling is one of the most noticeable differences between experienced engineers and those who are new to the field. It’s something you can get much, much better at.

https://twitter.com/dulcedejae/status/1366698181388607491

I thought I need to become “smarter” to get out of this. Turns out, it’s not primarily that but:

- Noticing when your mind can’t hold the whole picture, and using tools (pen and pencil)
- Learning good debugging strategies
- Grouping code to create guarantees I can rely on

Even the smartest people in the field aren’t some kind of cognitive monsters. We all have similar brains with similar limitations. But experienced developers are better at slicing the program in a way that each piece can fit in a human brain, while other pieces stat predictable.

*stay

Also sometimes the best solution is indeed just to take a walk or a nap and leave the problem alone. A tired developer is not a productive one.

One more technique I’ve noticed senior engineers do is “bailouts”. When they refuse to think about a problem because it’s unreasonably complicated. Like “with these conditions, there’s no point for me to dig into it — I won’t understand it”. And then work to simplify the problem.

A bailout is very different from randomly giving up. It’s recognized early by specific warning signs (e.g. thread-unsafe code). The whole point is to *not* go into a rabbit hole that’s too deep and holds no reward at the end because the answer is too detached from the mistake.

In React, mutating things during rendering is an example of that. Sometimes people show me code mutating during render and ask, “why exactly does it cause [a weird consequence]”. They’re trying to reason through it. But I can’t — it’s not worth the effort. Let’s fix it instead.