Last fall I got pulled onto two projects to help get them over the finish line. I think I made significant contributions, but the strange thing to me was that I didn’t do any programming on either of them. For one, I organized the testing and release of several small sites all related to one campaign. For another, I organized the testing, including triaging the defect list to get blocking issues fixed first.
Thinking back on this, I realized there were a number of things that these projects needed a programmer to do that were more than just programming:
- Communication: making sure everyone has the information they need to do what they need to do next.
- Prioritization: finding out what needs to be done first, and doing that.
- Testing: making sure all use cases are covered.
- Architecture: finding out the root causes of bugs, and rearchitecting those so that you fix all future bugs at the same time, as Ender would say.
Talking to the head of my department about these things, we had trouble figuring out what to call them. At first I wanted to call it deployment management, since it started out at the tail end of these projects. Then I realized it’s a big part of what I’d heard called the senior developer role at larger dev shops. My boss preferred the term technical project manager, i.e. someone specifically focused on managing the technical aspects of the project, as opposed a normal project manager focused on the requirements, communication, and scheduling.
There are differences of the range of meaning of each of those terms, so I think any of them could be appropriate depending on the role in your organization. But when I read Professional Software Development by Steve McConnell, I found a term that totally captures what I was getting at.
McConnell draws a distinction between three different terms:
- Programming refers simply to the process of writing code itself; nothing more than that.
- Computer science refers to programming applied to research, solving new problems, and general ivory-tower work. Not many of us do this.
- Software engineering refers to writing code for real-world use for businesses or organizations, and encompasses all aspects of what it takes to make a software product succeed.
This last term, software engineering, captures what I was getting at when I realized that there was more to programming than just programming. Since I read that, I’ve found a whole network of blogs, Twitter accounts, conference talks, and books on the subject. They’re not about specific programming languages or frameworks or even paradigms, and they’re not about project management per se. They’re about what it takes for a programmer to really grow in their profession, produce excellent work, and make a difference.
I’ve got a bunch of thoughts from these resources to share in upcoming blog posts. In the meantime, how much of your time on software projects is spent on programming, and how much on other things that are just as essential? Hit me up on Twitter at @CodingItWrong and let me know.