"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.

"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.

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.

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.

One of my mentors, on the subject of the books and consultancy of a particular signatory to the Agile Manifesto, pointed out that this person had a team that he worked with most of the time.

He asked me the question, "So is it the team that works or the process?". That has stuck with me, especially since another mentor was fond of saying you haven't proven you know how to do something until you can repeat the results.

If you have a team with the right kinds of flexibility and the right set of boundaries (they are inflexible about things that tend to end badly), most processes can be made to work, because of all the things they do that aren't prescribed. Some of the hardest parts of development are breaking down big units of work into sane pieces with clear exit criteria. So far I know of has captured the essence of how to do that. If you can't get that part right none of the other stuff helps much, and if you can get that part right the rest is mostly background noise.