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)

Languages Link to heading

Go 2024 to Present Link to heading

“I switched to Go after too many years in JavaScript and Node, where importing one library meant dragging in ten others—half of which you’d never heard of. The breaking point? Watching entire build pipelines fail because someone unpublished left_pad. Like seriously—why are you importing a package to add a few spaces? Just write the &*#! function. That whole ecosystem started to feel like duct-taped complexity. Go was a breath of fresh air: no fluff, batteries included, and simple enough that I can hold the whole system in my head without needing a PhD in package.json.” - Me

C# 2023 to Present Link to heading

“C# is a great language—elegant syntax, solid OOP support, and it feels great for building games. But I’ve always found the tooling around it kind of bloated. Multiple assemblies, project references, build configurations—it’s like you need to manage a mini-ecosystem just to get started. I prefer setups where I can see and reason about the entire system without digging through layers of tooling.” - Me

Node.js and Javascript 2015 to Present Link to heading

“When I first started using Node.js—back in version 0.10—it was a breath of fresh air coming from PHP. Everything was transparent and easy to follow. You could trace how things worked, and building backend systems felt lean and modern. It got me excited about server-side programming again.I even built a Twilio-powered call center using Node.js and MSSQL that ran unattended for three years—handling thousands of calls a day across dozens of agents without a hiccup.” - Me

PHP 2005 to 2015 and 2024 Link to heading

“PHP burned me out. Back in 2013, it felt like I was always chasing weird edge cases, inconsistent behavior, or broken extensions. I know it’s improved a lot since then—I’ve had to touch newer versions here and there—but I just don’t see myself going back. It did its job back then, but I’ve moved on.” - Me