With conventional coding, if your house of mental cards falls, you may potentially lose all of your work. By working from working code to working code, even if you lose your train of thought you get to keep most of your work so far.

A number of other techniques also allow you to work more from working memory than memorization. This helps when writing code a little bit, but most of the payoff is for readers or subsequent additions.

The thing with DRY is that code reuse means that a breakpoint most likely can fire from multiple paths, which makes it hard to trace why you’re getting null/undefined instead of an empty array as your second argument. Conditional breakpoints can help for some of these scenarios, but it’s better if the code in the middle of the call stack tries to be as contained and organized as leaf node methods eventually become.

You can’t modify code if you can’t read it, and if it’s difficult to read then interruptions become more problematic, because both the cost of interruption and the likelihood of interruption go up when thinking time increases.

The cleverest code is the code which is easiest to understand.

Things I used to do 10 years ago:

- launch headlong into a task as soon as I understand the problem statement

- pick up a ticket/bug, quickly attempt to do as little as possible to make it go away

- unit tests/integration tests pretty much never

- lots of (many times unnecessarily) complex SQL

These habits led me away from a place of understanding an overall system and towards a place of adding lots of entropy to the codebase. In an ideal world, every time you touch a codebase you should be trying to remove entropy. If ever you introduce new rules or ideas into a codebase, it should be like pulling teeth because every time this happens the cognitive model you have to hold onto just to work on the project increases, which slows down the entire team. Being contemplative about the repercussions of a change (especially its impact on cognitive load) can help steer a team as a whole toward better decisions. Being quick to point these factors out in kick-offs and PRs helps protect the codebase as well. It's a lot of work, but when a project operates under this kind of structure there just aren't that many things that require a large amount of focus. And those that do don't necessarily require active focus.

Having a variety of things to do helps. If I start to death spiral on a problem (which is how I describe the feeling that I'm overloading my mental map), I'll put the problem down for a bit and work on something else.

Having a strong grasp of the subject matter is also a huge help. E.g. I work on a payroll platform. Learning how payroll should ideally work while at the same time writing code for the platform wouldn't be an ideal scenario (we definitely had to do this at times, but most of us had at least a few years background around payroll-related business functions). I've found this to be the biggest blocker to my productivity whenever I start a job in a new field.

Over the last 10 years I've worked in:

- Payroll/HR

- Luxury/Athletic Clubs

- Autism care providers

- Workers' Compensation Insurance

- Financial Performance Reporting

I've done the above using probably half a dozen different programming languages, team sizes everywhere from 2 to 50+, and (I believe) because of the way I approach my work that there's really never been a time in that period where I couldn't hit pause and pick it up later.