Notes

• In software engineering there are two things you are trying to get right:

  • Software Validation - Did we build the right thing?

  • Software Verification - Did we build the thing right?

• Software simplicity is a prerequisite to reliability.

• A small, simple API is usually also a hallmark of a well-understood problem.

• Run/Right/Fast.

  • Make the code work I write is working. Then I can make it fast (if necessary). Solving the “correct/clean/performant code” problem all at once can be overwhelming. Don’t be overwhelmed. Solve one at a time.

• Reducing the maintenance burden is, for most codebases, the biggest optimization I can do.

  • Of course it's all about striking a balance, but 99% of the time there is a choice between performance and readability, readability is the right answer. Performance should only be chosen if it is absolutely necessary.

• If I write ugly code, anyone who intends to fix a bug or add a feature will not enjoy his work and likely avoid it next time.

• Explicit over implicit is almost always better.

• ​One of my principles is to always strive for simplicity when creating. In retrospect, I've learned many thing that I previously thought too complex to understand. The complexities tend to dissolve when you realize they are mostly just extra distractions emerging from the pressures of engineering the thing... distractions that you probably find yourself inventing all over again once you've assimilated the core idea.​

• Readme driven development is pretty neat. Write the README first as a specification. Then write the code for it. Zeit do it often.

• We are about to study the idea of a computational process. Computational processes are abstract beings that inhabit computers. As they evolve, processes manipulate other abstract things called data. The evolution of a process is directed by a pattern of rules called a program. People create programs to direct processes.

• Always be looking for patterns. Abstract them always and only when it simplifies.

• Persevere in getting an abstraction just right. When you find it, everything will magically fall into place.

• The implementation is the design.

• Hide whatever the caller shouldn't care about. In particular, you can remove type parameters with appropriate quantification.

• Declarative configuration means that you write down the desired state of the world in a configuration and then submit that configuration to a service that takes actions to ensure the desired state becomes the actual state.

• Every single feature makes product more complex, makes testing more complex, puts constraints on UI design etc. Controlling feature creep (also by revisiting old features) is very important to keep project healthy. Larger the project, more important it is.

Links

• ​One Bite At A Time: Partitioning Complexity​

• ​Being A Developer After 40​

• ​What's code?​

• ​Portability matters​

• ​On being an effective developer​

• ​Advice to the newish programmer​

• ​Comment Your Code​

• ​Things You Should Never Do​

• ​Writing good bug reports​

• ​Tips for reading new codebases​

• ​Engineering Principles at Monzo​

• ​Awesome Cold Showers - For when people get too hyped up about things.

• ​Fish Design Principles​

• ​List of resources about programming practices for writing safety-critical software​

• ​In Pursuit of Production Minimalism​

• ​The 12 Factor App​

• ​Mostly avoid unit tests​

• ​Software disenchantment​

• ​In search of software perfection - Xavier Leroy (2016)​

• ​Communicating Sequential Processes (CSP)​

• ​Ask HN: What's the largest amount of bad code you have ever seen work? (2018)​

• ​HN: Please do not attempt to simplify this code (2018)​

• ​HN: Minimalism: Practical Guide to Writing Less Code (2018)​

• ​HN: Software Engineering at Google (2018)​