3 ms·

Learning to write code is not too hard, maybe not the easiest thing but really not too hard. Writing good code - readable, maintainable, secure code with few bu

by danbruc 10y ago

Learning to write code is not too hard, maybe not the easiest thing but really not too hard. Writing good code - readable, maintainable, secure code with few bugs - on the other hand is really hard. The gap between a non-programmer and a junior developer is way narrower than the gap between a junior developer and a good senior developer. And something that I am missing in most of those articles is that writing code is actually the easy part of the job, 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.

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.
icehawk219 10y ago
I agree with this but one other side affect of lowering the barrier to entry (which is a good thing I completely support) is it also makes it easier for people who genuinely don't care about that to get into the game. I've met so many devs who absolutely could write readable, maintainable, secure code with few bugs (while working in places where higher ups supported it and allowed for the time for it). They just didn't give a crap. Those are the ones that drive me up the wall. I have no problem taking time out of my day to help a junior developer learn those things. I'll gladly spend my work day helping someone and then make up the time in the evening but when I meet someone who already has the know-how and just doesn't care I want to scream at them.

by danbruc 10y ago

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.

icehawk219 10y ago

I agree with this but one other side affect of lowering the barrier to entry (which is a good thing I completely support) is it also makes it easier for people who genuinely don't care about that to get into the game. I've met so many devs who absolutely could write readable, maintainable, secure code with few bugs (while working in places where higher ups supported it and allowed for the time for it). They just didn't give a crap. Those are the ones that drive me up the wall. I have no problem taking time out of my day to help a junior developer learn those things. I'll gladly spend my work day helping someone and then make up the time in the evening but when I meet someone who already has the know-how and just doesn't care I want to scream at them.