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.
Pingback: Dew Drop – March 28, 2012 (#1,296) | Alvin Ashcraft's Morning Dew
I agree 100% with the whole simple approach and always have. Just read the Steve Jobs biography and it’s amazing how that principle along with the ability to focus can bring about success. I’ve been starting to look at Domain Driven design myself as well and the jury is still out for me. Can you provide more details about what you think about Domain Driven design?
Sorry for the late reply. I do like DDD for sure, even though the jury is still out for some parts of DDD for me as well. It works well to push as much down into entities as makes sense (so long as you don’t make your Entities masquerade as services or vice-versa). And I really like the aggregate root approach, which btw, works very well in a NoSql environment. I’m still waiting to see the benefit of the use of Value Objects which proves troublesome at times, but willing to keep trying until I become convinced I have no reason for them.