Wisdom

When you know Link to heading

This page is just a collection of knowledge and wisdom I have stumbled across over the years. Mainly favorite quotes and software design principles. Hopefully someone one day stumbles across this and finds it as useful as I have.

Learn to think for yourself. Link to heading

Many software engineers seem to miss an important nuance: they often treat principles like SOLID or books such as Clean Code as absolute doctrines rather than as tools to enhance their own thinking. Conversely, some engineers dismiss these principles and books entirely, labeling them as worthless.

In my view, both extremes are misguided. The intent of these principles and books is to inspire engineers to consider their code from different perspectives, sharing the valuable insights of their authors. They are not meant to be rigid dogmas dictating the only way to write software.

Like in the movie, when you truly understand your craft, you’ll recognize when to adhere to the rules and when it’s appropriate to deviate from them.

The Developer Loop Link to heading 

* Planning 
    * Domain: Fully understand the business requirements.
    * Component: Create a clean, maintainable architecture that aligns with the domain
    * Contract: Establish clear communication boundaries to reduce coupling
    * Prototype: Prototype to uncover unknowns - then throw it away!
* Coding - No production code without a test!
    * Write just enough of a test so it fails.
    * Write just enough production code to pass the test.
    * Repeat.
* Production Code
    * Determine where you are
    * Identify where you want to be
    * Take smalll steps towards your destination
    * Reevaluate your position
    * Fix what you broke
    * Repeat

Quotes Link to heading

Simplicity is prerequisite for reliability.
~Edsger W. Dijkstra

We will never be rid of code, because code represents the details of the requirements
~Robert C. Martin

If you can’t describe what you are doing as a process, you don’t know what you’re doing W. Edwards Deming

If you can’t explain it simply, you don’t understand it well enough Albert Einstein

Quidvis Recte Factum Quamvis Humile Praeclarum
(Whatever is rightly done, however humble, is noble)

A good commit shows whether a developer is a good collaborator.
~Peter Hutterer, Linux.

When you first create a method, it usually does just one thing for a client. Any additional code that you add later is sort of suspicious.
~Michael Feathers Working Effectively with Legacy Code

We will never be rid of code, because code represents the details of the requirements
Clean Code

Indeed, if the discipline of requirements specification has taught us anything, it is that well-specified requirements are as formal as code and can act as executable tests of that code!

The fact remains: Good design is testable, and design that isn’t testable is bad.
~Working Effectively with Legacy Code by Michael Feathers

Align the happy path to the left; you should quickly be able to scan down one column to see the expected execution flow ~Medium Mat Ryer

The bigger the interface, the weaker the abstraction ~Rob Pike

The primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it. – Richard Gabriel

Software Design Principles Link to heading

  • ETC (Easy to Change): One principle to rule them all; your code should be easy to change.
  • RTFM (Read The Friendly Manual): Just read the docs bro…
  • LOB (Locality of Behavior): The behavior of a unit of code should be as obvious as possible by looking only at that unit of code.
  • DRY (Don’t Repeat Yourself): This is more about repeating knowledge not code. You may have two identical pieces of code that fulfill different business requirements. You want to make sure that if you need to update one it does not affect the other.
  • SRP (Single Responsibility Principle): A class should have one job and only one reason to change.
  • OCP (Open-Closed Principle): Software entities should be open for extension but closed for modification.
  • LSP (Liskov Substitution Principle): Subclasses should be completely substitutable for their parent classes.
  • ISP (Interface Segregation Principle): A client should never be forced to implement an interface that it doesn’t use.
  • DIP (Dependency Inversion Principle): Entities must depend on abstractions not on concretions.
  • KISS (Keep It Simple, Stupid): I call myself the SimpleDev for a reason. Simplicity is a perquisite for reliability.
  • Only When Needed: Do not abstract or implement features until they are required.
  • SoC (Separation of Concerns): Divide responsibilities to keep your code focused and clear.
  • Law of Demeter: Keep your code’s reach short—each unit should have limited knowledge and only talk to its direct friends, not strangers.
  • Composition over Inheritance: Assemble behavior from smaller parts rather than building deep class trees.
  • Command/Query Separation: A function should do something or answer something not both
  • Tell Don’t Ask Principle: Modules should operate autonomously by taking responsibility for their own behavior

Security Principle Link to heading

  • Principle of least privilege: Give the lowest privilege required for the shortest time required.

Naming Conventions Link to heading

  • Class: Noun
  • Function: Verb or Verb/Noun
  • Variable: Descriptive
    • Boolean: is/has/can/should name