I've been coding for a quite a while. Unfortunately, I spent a lot of my career not realizing I was writing bad code. A few years ago, I think I started to learn what it really means to write good code (of course, I thought that at the beginning of my career too). This happened when I began working on my first real agile project. The methodology was XP. I started learning about things like loose coupling, dependency injection, test-driven-development, etc...things that began to help me write more simplified code. Having said that, I think I've always had a propensity to try write the simplest code that could possibly work; I just didn't always know how.
Of course, I've written code that started out simple and when I was done I looked back and thought it was a mess. And, admittedly, I still do that. It seems inevitable that today's pride will always be tomorrow's embarrassment. But I do feel I'm doing better.
All around me I see examples of things I could do better, or at least, when I open my eyes that's what I see. There are some things that I believe in that have become guiding principles, things like loosely coupled classes, test-driven development, preferring composition over inheritance, the simplest design that could possibly work, etc. And there are other things that seem like a good idea and that I hope are right, things like Domain Driven Design, for example. And of course, there are more concrete things that I recognize I could learn more about, like when Mike Clement (@mdclement) tried to melt my mind recently in his session "Linq (From the Inside)" at Utah Code Camp.
The more I learn, the more I realize how much more there is to learn. Some things, when you hear them, seem obvious and simple, others can be quite complex and difficult to understand at first. The interesting thing is, learning complex and difficult things about writing good software doesn't lead to more complex code, it leads to simpler code. The more we learn, the more we are empowered to create clean, simple code. The measure of a good developer is not his (or her) ability to create impressive frameworks and complex code; it is instead his ability to identify the most simple solution to a given problem that truly delivers all the desired features to the user. I hope to be able to learn to do that better.
I've found that as I learn, I want to share, and that has led me to create this blog.
It can be my chronicle of today's proud moments turned into tomorrow's embarrassments published to forever live in infamy on the interwebs.
Welcome to the interblogospheres, Jim :-)
ReplyDeleteI hope you'll post some of your insights over on blog.pluralsight.com as well!