I started writing software in the mid-1990s. I've worked through changes in languages, frameworks, and database versions ever since. Looking back, five lessons stand out in the way I work now. Some took much longer to learn than others.

1. Know what actually runs. When I write a query, I want to see its execution plan and understand which indexes it uses. If it is slow, I want to investigate the statement the database received. That is a large part of why I still use Dapper. I'm comfortable working directly in SQL, and I want to be able to follow a query from the application into the database when I need to diagnose a problem.

2. The data outlives the code. This took me longer to fully respect. I recently moved an application first written in 2013 onto current .NET, and the production database under it did not change at all. The schema I had designed years earlier was still doing its job after the original application was replaced. Database design deserves care on its own terms, because the application being built today may be only one of several that eventually use it.

3. Test the way the application actually runs. Before changing a piece of authentication logic recently, I ran a read-only check across thousands of real accounts, connecting the way the real application connects. The connection path was part of what I needed to verify. A simplified test could exercise the logic and still miss a problem caused by how the application accessed those accounts. For that change, I needed evidence from the conditions it would actually encounter.

4. Understanding the business often takes more work than writing the code. Early on, I expected the difficult part to be the implementation. Over time, I became more concerned with understanding what the business needed and keeping those rules clear in the application. When a rule is scattered across database logic and screen behavior, even a small change can require looking in several places to understand what it will affect. I want to be able to find the rule, explain it, and change it without having to rediscover how the business works.

5. Keep reviewing my own decisions. During a redesign of My New Password, I found a security bug in the password generator I had written years earlier. I used the site frequently myself, and the passwords looked as random as I expected. It took looking at the implementation again to see the problem. I want to give code I wrote years ago the same attention I would give a change I was reviewing today.