Wisdom

This page contains key pieces of wisdom I’ve gathered throughout my career in software engineering. These insights have shaped how I think about code, architecture, and software craftsmanship. Rather than technical tutorials or specific learning paths, this page is about timeless advice and core principles.

Learn to think for yourself. Link to heading

Philosophy of Craft Link to heading

A common mistake I’ve observed is treating design principles or famous books as strict rules. Conversely, some dismiss them outright. Both perspectives miss the point. These ideas exist to help us reflect and improve our thinking—not to limit it.

“Learn the rules like a pro, so you can break them like an artist.”
— Pablo Picasso

When you truly understand your craft, you’ll know exactly when to apply certain rules—and when to set them aside.

Favorite 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, Clean Code

“If you can’t describe what you’re 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).”
— Latin Proverb

“A good commit shows whether a developer is a good collaborator.”
— Peter Hutterer, Linux Developer### Learn to think for yourself.

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

“Good design is testable, and design that isn’t testable is bad.”
— Michael Feathers, Working Effectively with Legacy Code

“Align the happy path to the left; you should quickly be able to scan down one column to see the expected execution flow.”
— Mat Ryer

“The bigger the interface, the weaker the abstraction.”
— Rob Pike

“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

Core Software Design Principles Link to heading

  • ETC (Easy to Change): Code should be easy to modify—this is the most important principle.
  • RTFM (Read the Friendly Manual): Good developers read documentation carefully.
  • LOB (Locality of Behavior): Keep behaviors easily understandable within their context.
  • DRY (Don’t Repeat Yourself): Avoid repeating knowledge. Similar code solving different problems isn’t necessarily repetition.
  • SRP (Single Responsibility Principle): Each class should have one clear reason to exist and change.
  • OCP (Open-Closed Principle): Code should be open for extension but closed for direct modification.
  • LSP (Liskov Substitution Principle): Derived classes should be substitutable for their base classes without altering correctness.
  • ISP (Interface Segregation Principle): Never force a client to depend on methods it doesn’t use.
  • DIP (Dependency Inversion Principle): Depend on abstractions, not concrete implementations.
  • KISS (Keep It Simple, Stupid): Simplicity is key to reliability and maintainability.
  • Only When Needed: Delay implementing features or abstractions until they’re clearly necessary.
  • SoC (Separation of Concerns): Clearly divide responsibilities for easier maintenance.
  • Law of Demeter: Components should interact only with their immediate neighbors or “friends.”
  • Composition over Inheritance: Prefer building functionality by combining smaller, independent components.
  • Command/Query Separation: Functions should either perform an action or provide data—not both.
  • Tell, Don’t Ask: Modules should autonomously handle their behaviors without external micro-management.

Security Principles Link to heading

  • Principle of Least Privilege: Always grant the minimal permissions required for the shortest necessary duration.

Naming Conventions Link to heading

Consistent naming improves readability and maintainability:

  • Classes: Nouns (Logger, UserManager)
  • Functions/Methods: Verbs or Verb/Noun combinations (updateUser, sendEmail)
  • Variables: Descriptive (userCount, emailList)
    • Booleans: Prefixed with is, has, can, or should (isLoggedIn, hasEmail)