Robert on Software Development

The Joy of Coding, and Code Leadership

I love coding. I always have, and I think I always will. When I’m writing code, I’m having fun, I’m satisfying my intellectual curiosity, I’m creating something, I’m accomplishing a goal, and I’m getting instant gratification. I just love to code. The thing is, I don’t get to do much of it anymore. As often happens to developers in IT, I’ve moved from the code-producing job into the application-management job. My responsibilities moved out of the of the design/develop phase of the lifecycle and into the deployment/management phase.

You can’t keep a good coder down, so I find ways to inject my true passion into my current role. I use code to solve problems that are exposed by my job. For example, I created a Windows Workflow application to help me manage the technical review process for change requests, which are my business responsibility. Rather than have a coding role mandated by the needs of a development project, I code tools that help me—and the people I work with—get things done. It’s not any more or less noble than any other coding job; it’s just, well, different.

And because I will always be a coder at heart, I’m looking for ways to extend my knowledge of software development into my role in the PMO, and future roles that I might drop into in the future. So I’m reading a book called Code Leader by Patrick Cauldwell, which came recommended by Scott Hanselman (who wrote the foreword), and quite luckily, I won in a raffle at the Lansing Day of .NET last month. I had been looking for a book that summarized the modern responsibilities of a software development manager so it was quite fortuitous that the book dropped into my lap. It covers a variety of topics that are the hot-button issues of today, like continuous integration, test driven development, dependency management, and Model-View-Presenter. I’ve been pretty pleased with it so far. I had never really understood continuous integration until I read about it in this book. Discussions about CI always leaned toward the details of CruiseControl rather than the theory behind CI.

If I can be a strong development manager and combine that with my IT management skills, then I can achieve my goal of quality software that works. Maybe that should be capitalized. Quality Software That Works. QSTW shouldn’t be a dream. QSTW shouldn’t be a product of processes and meetings. It should just be. And the path to QSTW is established in books like Code Leader and Code Complete.

I am always looking for ways to improve my own coding and the projects under my watch. Keeping up with the changes and new technologies in the software development world is a constant challenge. But that’s a topic for another post.