I've recently been re-reading a lot of the articles on Joel on Software, mainly to remind myself of the way things should be done as opposed to the way things are done in my current employment. I came across a definition of what a "Program Manager" is within Microsoft. If you've ever read any of the MSDN blogs or watched any of the videos on Channel 9 you'll have heard the term before. I'd always wondered what they do, and had assumed that they were simply the line managers of the development team for a particular product or feature. I was wrong.
In the third article of a series on writing painless functional specifications, Joel talks about how you get around one of the main points of the book The Mythical Man-Month. Joel explains the point in his article, so I won't repeat it here, but I will add my support to reading that book if you haven't already - it should be required reading for every software developer!
Joel explains that the position of Program Manager was originally created to be the "master programmer" with a number of junior developers under them. The master programmer would prototype each function, effectively architecting the code and then have the juniors implement them according to those prototypes. As any developer will tell you, being one of those juniors will lead to a short-lived self-terminated employment. As Joel puts it, "nobody wants to be a code slave".
When Microsoft realised this they reinvented the position such that they would own the design and the spec for the products.
When I read that it hit me... that's the type of job I'm looking for.
My interests in software development have always focused on two areas. The first is purely and simply doing cool stuff with software. That's why I have a lot of snippets of code but few finished projects. Which leads me on to my second main interest: software design.
In my personal software development I tend to start a lot of projects but don't finish many to the point where I'd be happy to release them. I think this stems from the fact that I like solving problems, and the seemingly endless detail involved in taking that solution and creating a shippable product tends to frustrate me.
Whenever I start thinking about a new idea for a project I grab my notebook and start scribbling out ideas. I rarely jump straight into writing code unless the idea depends upon the technical feasibility of doing something, and even then it will just be to prove that it can be done before thinking about the rest of it. In my experience this makes me a bit unusual, but hey, that's just the way I do it!
I used to think this meant I was looking for an R&D position. Something where I could take problems, come up with solutions, prototype it as a proof-of-concept and then pass the successful ideas off to a 'real' development team to make it into a 'real' product.
Does this mean I'm not capable of writing top-quality software when it's part of my job? Of course not. In fact I get a certain satisfaction from seeing a project through to delivery, and particularly from seeing users happy with the difference it will make to their lives. But that doesn't mean it's what I want to be doing with my life. I'd much rather design and spec the overall architecture and leave the details to other developers who prefer that type of development.
So, in conclusion I hope my next career move will be towards this type of position. In the meantime I'm going to try to push my current employer to take the need for a specification for every new feature seriously. It would also be nice to concentrate on fixing the multitude of non-critical outstanding bugs before we bend to the next customer desire, but I think I just fell asleep and started dreaming. Ooh, fluffy clouds.blog comments powered by Disqus