Canonical blog posts of software development

There's something missing here, which is something about "minimising the feedback loop in everything I'm working on".

Speed and efficiency:

• Dan Luu "Some reasons to work on productivity and velocity"
• Nelson Elhage "Reflections of performance"

Workflow:

• Start by understanding the domain of the problem as best as possible. Problem-solving code derives its value from how well it solves the problem, so if you don't have a goal, then there's no way to tell if the code is "right" or not.
• Julia Evans "What does debugging a program look like?"
  • Specific to C: Niklas Gray "A taxonomy of bugs"

Design (and Style):

• Casey Muratori "Semantic compression"

  Starting with the details and repeatedly compressing to arrive at the eventual architecture avoids all the pitfalls of trying to conceive the architecture ahead of time.

• Jimmy Koppel "My favorite principle for code quality"
  • For more inspiration, also check out "The Essence Of Software" by Daniel Jackson (summary here)

  Finding a good structure for the code was easy once we saw the structure of the design.

• John Carmack "Inlined code"
• Hillel Wayne "Clever vs Insightful code"
  • Provides a reasonable pathway to reason your way between "boring readable boilerplate" and "APL/J/K golf"
• Salvatore "antirez" Filippe "code comments"

  ... a key goal in writing readable code is to lower the amount of effort and the number of details the reader should take into her or his head while reading some code. So comments can be, for me, a tool for lowering the cognitive load of the reader.

• "The majority of useful program code will be to handle errors and edge cases, rather than the 'business logic'. The real domain knowledge is often the error handling."
  • I can't recall where I read this from, unfortunately.

Architecture:

• Dan McKinley "Choose boring technology"
• Nikita "tonsky" Prokopov "the question of utils"
• Rachel "by the bay" Kroll "One computer"
  • and associated links

Documentation:

• David Laing "the grand unified theory of documentation"

Company dynamics:

• Yosef Krenin "People can read their manager's mind"

  So they ignore your requests and become valued, instead of following them and sinking into obscurity.

• Marianne Bellotti "Why is this idiot running my engineering org?"

  People tend to think that the biggest deciding factor in their career is their talent or skill, but I don’t believe that. The way you process risk and handle fear has more impact on what kind of career you have than any other single factor.

Also other things about "the dream":

• The state of the art in programming could be so much better! But here we are, playing computer.
• Jimmy Koppel "Developer tools can be magic. Instead, they collect dust."
• Jamie Brandon "Pain we forgot"
• Graydon Hoare "What next?"

Thoughts about my influences:

• These are biased towards the advice of people who have built effective (at solving problems within a domain) software with an unusually low amount of organisational support -- individuals and small teams who seem to be strangely prolific at creating useful things.

Other peoples' notes:

• Jamie Brandon https://www.scattered-thoughts.net/writing/coding/
  • I agree with a lot of this perspective, and Jamie's influences overlap a lot with mine.
• Ben Kuhn https://www.benkuhn.net/progessays/