6 months. . . to become a better developer

Ok.  I’ll jump on this bandwagon since it is forcing me to reflect on how I can make myself a better developer.  Justice Gray started this whole thing, and I was ‘tagged’ by Bil Simser.  It’s a pretty hard question since this is the first time I’m trying to reflect on how to be a better developer.  I don’t consider myself a great developer right now, but I hope to be one some day.  What the definition of that is, I’m not sure.  Will I know it when I see it?  I have, however, progressed enough that I’m pleased with my progress so far, and I believe I’m at least keeping pace with my peers.  I can attribute my current position to voracious reading and listening.  I began this when I was deployed to Iraq with the Army in 2003.  I spent every free minute reading.  I read programming books and other material related to software, and I read all the scriptures in the Old Testament as well. 

When I returned from Iraq, I was a different developer.  I approached problems from a different angle.  By reading, I realized how much I did not know, and the more I learn, the more I learn how much I don’t know.  Since then, I’ve learned to listen to others (quite selfishly) in order to learn from them.

So here are the things I’ll do in the next 6 months to become a better developer:

• Finish my stack-o-books.  I have a stack of software books in my office that is my “to read” stack.  My “read” stack is every bigger, but I’m not nearly finished, so I need to finish those.  They mostly consist of older software books.  I feel that if I’m to have a balance view of software, I have to have a good foundation of past research.  I approach it as engineering.  I need to understand past successes and failures so that I can apply it to today.  Perhaps some could be considered software history books, but I don’t know all the history at this point, and I certainly don’t want to be doomed to repeat it.
• Teach more than do.  Up to this point, I’ve written a lot of code.  I’ve been a code monkey, developer, senior developer, manager, executive, and now consultant, and I’ve realized that my programming skills don’t scale.  I can only create software so fast, and then there is a limit.  In management, I started this line of thinking, but moving to consulting has brought it more to the fore-front.  As the saying goes, teach the men to fish, don’t fish for them.  I will teach more and “do” less.  By that I hope to learn more by teaching and deliver more value to my clients by enabling their staff.
• Educate myself on other ways of developing.  At this point, I have a “default architecture” in my head that has been fine-tuned from every project I’ve worked.  It’s based in part on Domain-driven design and encompasses a lot of other OOP principles.  I prefer to use NHibernate for relation database interaction and MVC for UI whether it be web or windows programming.  But even so, I realize that I will never reach a “default architecture” and that this only represents my knowledge as of today.  There is so much working software that I haven’t studied.  I intend to acquire source code to other successful applications and study it for patterns and other knowledge that has escaped me up to this point.  Of course, some open-source applications come to mind since the source is freely available. 
• Focus on trust.  Product owners often don’t trust the developers and developers don’t trust the product owners.  In many places, the testers don’t trust either and there is a triangle of distrust.  Each group believes they are doing a good job and the other isn’t.  This just isn’t true.  Everyone wants to do a good job, but the lack of trust sabotages productivity of the whole.  Working to form trust can save so much time and keep a project from running over budget.  If ideas can flow without everyone involved finding it necessary to “cover their butts”, we remove a whole category of “work”.  I have began this, but I have a long way to go with it.  At my clients, I will focus on the trust factor first and software second.  I believe the software will come easier when the people involved trust each other.

I’ll keep this going.  For the following 4 people, what are you going to do in the next 6 months to become a better developer?

• Scott Guthrie
• JP Boodhoo
• J. Michael Palermo IV
• Ron Jacobs