Three Life Lessons Learned from 17 Years of Programming

Marking his seventeenth year of programming, the author reflects on a career that began in the late 1990s with table‑based web design, classic ASP, and Microsoft Access, evolving from a hobby into a lifelong passion.

Lesson 1 – Trade‑offs are often negotiable. He describes how debates in the developer community (e.g., TDD vs. other web‑development methods, ORM vs. raw SQL) always come down to weighing benefits and drawbacks. He recounts his early belief that ORM tools were the ultimate solution, only to discover that mature ORMs can hide inefficiencies such as the classic n+1 select problem and make non‑standard queries harder, so the choice must be driven by data volume, performance constraints, and long‑term scalability. He now prefers micro‑ORMs like Dapper for fine‑grained control.

Lesson 2 – Clarity is not always synonymous with conciseness. The author argues that the goal of code should be effective communication, not just brevity. He presents a verbose conditional example that, while longer, conveys intent more clearly than a terse version. The code is shown below:

<ol style="margin: 1em 2em; padding: 1px; max-width: 100%; color: rgb(174, 174, 174)"><li><p><code>if(HasFarm() && HasBoat())</code></p></li><li><p><code>{</code></p></li><li><p><code>Broadcast("You are wealthy!");</code></p></li><li><p><code>}</code></p></li><li><p><code>else if(HasFarm() && !HasBoat())</code></p></li><li><p><code>{</code></p></li><li><p><code>Broadcast("You are OK!");</code></p></li><li><p><code>}</code></p></li><li><p><code>else if(!HasFarm() && HasBoat())</code></p></li><li><p><code>{</code></p></li><li><p><code>Broadcast("You are OK!");</code></p></li><li><p><code>}</code></p></li><li><p><code>else if(!HasFarm() && !HasBoat())</code></p></li><li><p><code>{</code></p></li><li><p><code>Broadcast("You are poor!");</code></p></li><li><p><code>}</code></p></li></ol>

He also shows a more compact ternary version, noting that while some may find it clearer, the longer form can be more explicit for readers.

<ol style="margin: 1em 2em; padding: 1px; max-width: 100%; color: rgb(174, 174, 174)"><li><p><code>(HasFarm() && HasBoat()) ? Broadcast("You are wealthy!") : </code></p></li><li><p><code>(HasFarm() || HasBoat()) ? Broadcast("You are OK!") : </code></p></li><li><p><code>Broadcast("You are poor!");</code></p></li></ol>

He concludes that sometimes the best explanation is not the shortest, but the one that conveys the intended meaning most unambiguously.

Lesson 3 – Accumulate good technical debt and repay it continuously. Drawing from his family’s experience with paying off a mortgage without credit, he explains that debt can be a strategic tool when used responsibly. In software, taking on short‑term debt—such as postponing abstraction or accepting sub‑optimal SQL—can speed delivery, provided the team schedules regular refactoring (e.g., dedicating 10 % of weekly time) to “pay off” the debt.

The article ends with references to the original blog and translation credits.