My father-in-law is a carpenter. When we talk about work, he talks about things we can drive around and see: porches, houses, parts of big buildings, housing pr

My father-in-law is a carpenter. When we talk about work, he talks about things we can drive around and see: porches, houses, parts of big buildings, housing projects. I have nothing to point to that would mean much of anything to him. At least I didn't up until the last ten years or so. I used to focus on the code. People wanted stuff and the code had to be "correct" so that they could get what they wanted. I found "correct" to be endlessly complicated, but heck, that was part of the fun of it. Then I focused on the people. How am I interacting with the people I'm trying to help such that I have a better idea of what "correct" means? I found that people don't know what they want, they don't know how their desires might change, and even if they did they are incapable of describing that to me in a way that would provide significant architectural guidance. Finally, I balanced them. I created a definition of good code. Good code is code that does something for people that they value that I can walk away from and never touch again If the code doesn't do anything valuable or I can't walk away from it, it's not good code. This made me realize that as much as I knew about people and programming, I suck at good code. I get wrapped up in the people part, not figuring out value or being able to scope it well. I get wrapped up in the coding part, building out things that I'll only need in my imagination. It made me feel a little better to see that so many other developers suck at my definition of good code also, but it was a terrible blow. Humbling. I'm happy I made the change. I don't feel the way I used to a decade or two ago. My journey is not this author's journey, but I feel the pain he expressed in his essay, and because of that pain I began mine. Best of luck.