Cognitive loads in programming
One of the goals of any code base of significant size should be to reduce the cognitive load (not lines of code per function).<p>Assume the developer working here just had a 45 mins sync, has a meaningless repeat meeting about vapourware in 10 mins and a 2 hours town hall meeting after lunch... and still have to deliver that mess of a requirement you made him promise to deliver before any of these interruptions were even on his calendar!<p>- Always aim for declarative programming (abstract out the how it does it),<p>- limit the depth of the function calls (rabbit hole developers...),<p>- separate business logic from framework internals and<p>- choose composition over inheritance.<p>- Also avoid traits and mixins (run from the dark magic)<p>- don't over document the language or framework, only the eyebrow raising lines, the performance sensitive stuff and the context surrounding the file if it isn't obvious.<p>- name stuff to be easily grepable<p>Easy rules to go by, (there are probably more), they can make or break your ability to work, so that you can get interrupted 12 times an hour and still commit work.<p>I don't find these in books, just decades of sweating and pulling my hair "why does it have to be so hard!?" I have met plenty of senior devs who naturally do the same thing now.<p>The code size fallacy is a prime example of the wrong way to look at it. Plenty of extremely large code base in C++ are far more manageable than small JavaScript apps.<p>Mixing boilerplate framework junk with your intellectual property algorithms "what makes your software yours" is a sure way to hinder productivity in the long term.<p>You write code 3-4 times. You read it 365 times a year.<p>One last thing I recommend if you deal with a lot of interruptions and maybe multiple products, various code bases... keep a<p><pre><code>    // @next reintegrate with X
</code></pre>
The @next comment 'marker' is a great way to mark exactly which line of which file you were at before you left this project, for a meeting, for lunch, for the day, etc.  And it allows you jump back into context by searching for @next and go. Also since it's visual and located, your brain has a much better time remembering the context, since we're good with places and visual landmarks.<p>It's far more efficient than roughly remembering what I was doing, looking at the last commit, scrolling endlessly through open files. Don't commit @next though :)