3 ms·

The hard part, as you describe it, is usually not the job of coders. It's the job of project managers. In lesser organization the coders are doing work that man

by x5n1 10y ago

The hard part, as you describe it, is usually not the job of coders. It's the job of project managers. In lesser organization the coders are doing work that management is suppose to be doing, so they might be doing multiple roles which makes their job much harder.

danbruc 10y ago
I don't think that would be part of the job of the project management or at most it would be their job to keep the number of change requests as low as possible. In my current project, for example, with have people dedicated to requirements engineering and things are reviewed several times, at least in theory, before they end up in the sprint backlog. But nonetheless I would say that just reading a user story and coding it out is the exception, usually you write a if statement and then notice that there is nothing in the specification that says what to do in case the condition is false. And then you ask and suddenly it turns out that this whole thing totally conflicts what somebody implemented a month ago. Personally I have never worked in a project where people where just supposed to code out a given specification, they were always also involved in gathering requirements and at least to some extend in shaping the architecture. Only the overall system architecture is usually already fixed by architects, most of the time to ensure that the system integrates well with the existing environment.
collyw 10y ago
Junior coders maybe, but a senior level engineer should be able to make these decisions. Often PM's aren't particularly technical or their tech knowledge is dated, so its good for someone doing the implementing to help with the decision making.
nilkn 10y ago
I don't agree. This isn't to disparage the job of project managers, but I think you're going too far in the opposite direction and disparaging the job of developers too much here. Quoting from the top-level comment: > Writing good code - readable, maintainable, secure code with few bugs - on the other hand is really hard. How is a project manager going to help with this? This is clearly the responsibility of the programmer, not the PM. > the hard part is talking to the customer and figuring out what they actually want you to do and then keep up with them changing their mind every four weeks and still somehow manage to ship something that roughly does what it currently is supposed to do. I wonder if you interpreted this too literally. Sure, the act of talking to the customer is itself a bit challenging in some cases, but I think the point is that it's especially challenging to engineer a system subject to changing requirements because if you're not good and careful you could build yourself into a corner. A good PM can help a ton here by figuring out how to talk to the customer and spending a lot of time doing so. But I don't think there's any reason to believe that's actually harder than building the requested system, and if any requirement does change, it's not going to affect the PM directly at all -- it will be an order of magnitude harder for the developers to deal with that than the PM. Finally, I think developers taking on management roles is exactly what's needed, and it's exactly what happens in most top tech companies. Sure, if you look at extremely high ranking VPs at a place like Google, you'll find many ex-McKinsey Harvard MBAs (alongside engineers as well), but in general the middle management at these places is composed of programmers to a very significant extent.

by x5n1 10y ago

danbruc 10y ago

I don't think that would be part of the job of the project management or at most it would be their job to keep the number of change requests as low as possible. In my current project, for example, with have people dedicated to requirements engineering and things are reviewed several times, at least in theory, before they end up in the sprint backlog. But nonetheless I would say that just reading a user story and coding it out is the exception, usually you write a if statement and then notice that there is nothing in the specification that says what to do in case the condition is false. And then you ask and suddenly it turns out that this whole thing totally conflicts what somebody implemented a month ago. Personally I have never worked in a project where people where just supposed to code out a given specification, they were always also involved in gathering requirements and at least to some extend in shaping the architecture. Only the overall system architecture is usually already fixed by architects, most of the time to ensure that the system integrates well with the existing environment.

collyw 10y ago

Junior coders maybe, but a senior level engineer should be able to make these decisions. Often PM's aren't particularly technical or their tech knowledge is dated, so its good for someone doing the implementing to help with the decision making.

nilkn 10y ago

I don't agree. This isn't to disparage the job of project managers, but I think you're going too far in the opposite direction and disparaging the job of developers too much here. Quoting from the top-level comment: > Writing good code - readable, maintainable, secure code with few bugs - on the other hand is really hard. How is a project manager going to help with this? This is clearly the responsibility of the programmer, not the PM. > the hard part is talking to the customer and figuring out what they actually want you to do and then keep up with them changing their mind every four weeks and still somehow manage to ship something that roughly does what it currently is supposed to do. I wonder if you interpreted this too literally. Sure, the act of talking to the customer is itself a bit challenging in some cases, but I think the point is that it's especially challenging to engineer a system subject to changing requirements because if you're not good and careful you could build yourself into a corner. A good PM can help a ton here by figuring out how to talk to the customer and spending a lot of time doing so. But I don't think there's any reason to believe that's actually harder than building the requested system, and if any requirement does change, it's not going to affect the PM directly at all -- it will be an order of magnitude harder for the developers to deal with that than the PM. Finally, I think developers taking on management roles is exactly what's needed, and it's exactly what happens in most top tech companies. Sure, if you look at extremely high ranking VPs at a place like Google, you'll find many ex-McKinsey Harvard MBAs (alongside engineers as well), but in general the middle management at these places is composed of programmers to a very significant extent.