3 ms·

"my methodology works until management breathes down my neck but so be it! "My methodology works until junior devs show up and don't know how to code" "My met

"my methodology works until management breathes down my neck but so be it! "My methodology works until junior devs show up and don't know how to code" "My methodology just works... except all the times it doesn't and when it doesn't, it's your fault because you did it." That's what I got from this article. It's development itself that's the problem. Software is really complex and things take a long time to build. The relationship between the time it takes for management to say "build it" and to actually build it is asymmetrical. It requires many people to build things of significance. Coordinating understanding of things between people is a hard problem. Gaining the experience to know why you should or shouldn't do something takes years. During that time you have to be working on things and contributing to code bases.

chillacy 8y ago
And this author's been a "dev" for decades on top of that! Junior developers are a fact of life for any growing company with a career path (unless you're netflix), and so is management and coders of all levels. To fix that you need other processes, code reviewers, mentorship, maybe even a google "readability" policy.
- james_s_tayler 8y ago
  Yup. The author does have some OK points in places, but some of them are either (a) facts of Life or (b) organizational/management issues.
hinkley 8y ago
"My methodology works as long as I'm the one who does all of the fiddly bits." (PS: it's all fiddly bits) My only real beef with Fred Brooks is that he put the idea in people's heads that one or two people on the project are all important and everyone else is replaceable window dressing. A surgical team is a terrible structure for software development. It's much more like a team sport, where everyone should be constantly growing and reviewing past outcomes for new wisdom. It's not a perfect analogy/model because I also believe in the power of conceptual integrity, so there's a bit of a paradox in my line of thinking. People should be able to add things to my code without me constantly meddling or taking over. Maybe I can clean it up to make it faster/safer, but my goal should be to be able to get things off my plate. If I'm indispensable, it should be in my ability to take on new areas of concern, not by monopolizing old ones and keeping my coworkers from getting promoted by making them look stupid.

chillacy 8y ago

And this author's been a "dev" for decades on top of that! Junior developers are a fact of life for any growing company with a career path (unless you're netflix), and so is management and coders of all levels. To fix that you need other processes, code reviewers, mentorship, maybe even a google "readability" policy.

james_s_tayler 8y ago
Yup. The author does have some OK points in places, but some of them are either (a) facts of Life or (b) organizational/management issues.

hinkley 8y ago

"My methodology works as long as I'm the one who does all of the fiddly bits." (PS: it's all fiddly bits) My only real beef with Fred Brooks is that he put the idea in people's heads that one or two people on the project are all important and everyone else is replaceable window dressing. A surgical team is a terrible structure for software development. It's much more like a team sport, where everyone should be constantly growing and reviewing past outcomes for new wisdom. It's not a perfect analogy/model because I also believe in the power of conceptual integrity, so there's a bit of a paradox in my line of thinking. People should be able to add things to my code without me constantly meddling or taking over. Maybe I can clean it up to make it faster/safer, but my goal should be to be able to get things off my plate. If I'm indispensable, it should be in my ability to take on new areas of concern, not by monopolizing old ones and keeping my coworkers from getting promoted by making them look stupid.