Everytime I see some article about how software is created it always looks like a series of meetings with lots of white boards being used by project managers of various kinds to detail the desired specs to a room full of programmers. Do these top guys very hunker down with the code monkeys and write any software themselves? Can they write software in most cases?
I would guess it depends on the manager - and his/her experience level. Just from the title project manager, I don’t see him/her as a developer. I see their role more as a a co-ordinator - like you said, getting the people in a room to draw up a vision to create a spec. Might also be a conduit for communication between the coders and the other people dependent on the software - whoever put in the first request, basically. Most of the work I have done in companies has to do with internal programming, so I do have to wonder how much interaction the manager has with external forces when working on the project - how much communication is gained from the consumer, and through how many channels it has to go before it reaches the target base - basically wondering about the communication loss factor.
I’m working my idea of the role from what little work experience I’ve had with project managers as a whole - most of the companies I’ve worked with consider it a miracle to get complete specs done before the project is started. I’m very good at educated guessing of client needs - and since most of my work is company internal, that’s mostly expected.
Susan
My PM at the moment came to us from a marketing background. I don’t know that she can’t code, but I don’t think I’d bet my life savings on it.
The role of a PM in software development is to maintain an up-to-date schedule and to make sure that the people who need to talk are talking. It’s a full-time job, so I seriously doubt you’d ever want them involved in coding (another full-time job).
Some software is made by one guy sitting in his bedroom with an el-cheapo PC. Other software is made by big groups of people in a corporate environment, and you may have project managers, senior programmers, and all sorts of folks involved. As a hardware and software developer, I’ve worked in both types of environments, and some in between.
In the large type of setting, usually (but not always) the marketing department decides what the product needs to basically look like and do. This person does not need to know programming, only how the product works from a practical level. Then someone who both understands the product and knows programming has to figure out exactly how to put the plan into action. Tasks will be handed out to junior and senior level programmers (obviously the junior level guys get the easier stuff) and it’s up to the guy in charge to put it all together and make it work. There may be a “project manager” who does things like keep track of schedules and resources (i.e. how much money they are spending on development) who would not be a programmer at all, or project management duties may be done by the lead programmer. Depends on the structure of the company and how big the project is. More complex programs need more project management, and therefore would have a greater need to have someone dedicated to the job.
In smaller companies, the same sort of thing is done but the project manager, programming lead, and the guy doing the bulk of the programming may be all one person, with only another developer or two working on the project.
What Mr geek says. A Project Manager’s job doesn’t involve any programming. Certainly where I work none of the PMs codes (and wouldn’t know how). Most of the middle management have sort of ‘risen through the ranks’ and used to be programmers*, although there are some equally senior guys who are still (in our lingo) Analyst/Programmers.
*astro I recon you’re allowed to use “code monkey” if you are one. It’s like the “N” word. 
There are project managers and programming managers, different in large projects, the same person in smaller ones. In large ones the project manager should know project management more than programming. However I think programming managers or project managers for smaller projects had better know how to program. I’ve seen managers seriously underestimate jobs, and I’ve seen programmers blow up two day projects into several month projects, because no one knew enough to call bull. But they shouldn’t be programming anything serious, since you need an uninterrupted stretch of time which managers never have. I write code for experimental purposes, but I’ve taken to using Perl because it can be written in tiny chunks better, and I’m not fooling myself about its state of productization.
I know quite a few SW Project Managers that that are former programmers and still like to code. I also know the programmers that work for them and how much they hate this. The managers’ goals should be direction and coordination first and when they let that slide because they’d rather be programming, their in the wrong job.
As everyone else has pointed out, it depends. My title is software manager and I do project management as well as other things. I rarely write code any more, but will pitch in if the schedule is tight, or will pitch in if the problem is particularly tough to debug. Mostly now I spend my time doing design and managing people. However, I try to keep my skills sharp enough that if I wanted, I could go back to writing code.
However, in some parts of our company, they have pure project managers who only manage people and time and some of them have never written code.
My projefct manager is familiar with the generalities of coding, and could perhaps knock out a few lines of syntactically-incorrect Java before someone pulled him away from the keyboard, but does not code as an ordinary thing. I work for a very large T company.
My girlfriend is an IT project manager for a small-to-midsized company, and has a bachelor’s in Computer Science and Engineering, so she presumably COULD code is she wanted to. But she doesn’t, and doesn’t.
If relatively few “managers” actually know how, or want to, write code where is (or who is) the usual gatekeeper in the software writing process for the quality vetting of what is well done code vs not so great code in the finished software product?
The project manager may or may not know how to program. It’s not a requirement for the job, as project managers are usually coordinators, as was said in a previous post.
However, the software developers’ manager, in my experience, has a programming background. They do not write code themselves, however. If they wanted to keep writing code, they wouldn’t have gotten into management.
There are a lot of ways to write code that works. Generally, it’s the give and take between QA and the developers (with the PM coordinating) that determines whether the software is good enough. If it works without serious bugs, it’s generally okay. If it is determined that there is something seriously wrong with the software (too slow, memory leaks all over the place, etc.) management may get highly pissed and order a code review. Then, everybody sits down and goes through the code line by line. This is, of course, extremely time consuming. Fortunately, it doesn’t need to be done very often, at least not in my company.
IAAPD. (I am a PowerPoint Developer).
Marketing has zero input to what our products do. The way it works around here is the PMs sometimes (but not always) have some programming experience, but they are rarely called upon to use it. They write the Specs, then Spec Review meetings are held between PM, Dev and QA owners for that feature. After a few meetings have hashed out what can and can’t be done, Dev starts writing the code for an early “does this work but let’s not check it in to the builds yet” build and QA goes through it. Once all those bugs have been hashed out, it then gets checked into the builds and QA is free to log as many bugs as they can find.
The Spec review meetings work all of this out. Once that is done, QA is responsible for findings the bugs, and Dev is reponsible for making sure the code is well done. There are several internal tools we use to ensure the code quality is good, but there’s also some glass box testing that we do. We also shore up code from previous versions, fix punted bugs from that version, etc.
Most of the Project Managers where I work can code.
Although, since it’s been a while for a lot of them that would only extend as far as old COBOL.
You don’t have to be able to code to project manage software development but I find those that can get more respect from the “code monkeys” than those that can’t.
In all the companies I’ve worked for, my manager was part of the programming team and did some of the coding himself.
That said, I’ve only once worked for a company that employed more than a dozen programmers…and that was a dot-com company, where the corporate atmosphere differed from most standard companies. In a place like Microsoft or IBM, I don’t know what the answer would be.
You work in a small company? Where I am (a very large company), the only thing that matters as far as a PM’s respect is how well they can juggle all the scheduling and communications for the 30+ individuals involved in a project.
From my own experience… I’ve never had a manager who could write code at all. Generally (in my company at least)… the programming manager’s responsibilities include scheduling, designing programming requirements, liasing with other departments/external clients about progress, testing, (and in the case of external clients, pricing.) Ideally, they know enough about the process of designing software to be able to consult on strategy and inform the developers what external factors might affect design decisions.
One other thought that I think would be relevant to throw in here is that, whenever I’ve been working in a team of developers, (I’m not the only qualified programmer left – downsizing,) normally one or another developer would take a leadership role with respect to a particular project. The leader would do most or all of the design work and hand specific modules off to other developers if it was needed. (Sometimes, if a project was so large that no one developer could handle the design work, it might get split co-operatively into parts – and asking other developers for their opinions on difficult design decisions was common.)
A typical (and very simplified) project timeline might go as follows:
assistant director from department 7 goes to the manager and presents a project idea.
manager consults with any developers who aren’t on crash priority projects and discusses the idea. At this point some developer B steps forward and volunteers to be project leader.
manager arranges a meeting with developer B, the assistant director and possibly other personnel from department 7… (underlings/users – possibly the director if it’s important.) Idea is formalized into a set of project requirements at this point.
developer B sketches out his design, consulting with developer A on tricky points. Comes across a few ambiguities, which he takes to the manager, who answers most of them and relays one to the assistant director of 7.
developer B asks developer D to assist and provide 2 modules to do this and so. developer D says that she’d like to, but she’s already got a full to-do list. They go to the manager, who says that project for 7 takes priority over everything else on developer D’s to-do list.
Project code is assembled and alpha-tested by developer B. Finds some sort of tricky problem that he can’t diagnose easily, asks developer A to help. developer B feels really stupid when developer A not only finds the error, but corrects it within 4 minutes.
Project is sent to department 7 for user beta testing… a few minor snags are found and corrected by developer B… project is signed off on and launched.
department 7 complains when the finished software doesn’t do something that they never asked for and never noticed while beta testing it… 
(that doesn’t ALWAYS happen - just seems like it.)
hope this was informative or at least entertaining.
Well it only happens nine times out of ten