Books chapter three

In my recollection, it's presented as speculative. It'd definitely be interesting to know the experiences of those who've tried it in fullness since.

Thanks to a3n and dllthomas for your attempts to explain this. I realized that my question is better suited for SE than for HN:

https://softwareengineering.stackexchange.com/q/355203/69228

I don't know. Maybe it'll work, maybe it won't, but detractions I've seen seem to mischaracterize the proposal in ways that undermine it. Your complaint here seems an example of (or derived from) that. (Though of course I assume it's a difference of interpretation and/or misreading by one or more of us, rather than any malfeasance!)

First, as a bit of an aside, it's not strictly true that "no one goes to school to learn to be a programmer so that they can not be a programmer." Some people go to school to learn to be a programmer so they can manage programmers. Further, some people go to school to learn to be a programmer, then find there's something other than programming that they'd rather be doing instead. And of course some programmers didn't go to school at all.

All of that said, I take your general complaint to be about the roles other than "surgeon" essentially requiring programmers who are essentially not programming?

I think that's not really the case, as the concept was intended. Many of the roles on the "surgical team" are still programming. Those that genuinely aren't can be filled by people trained specifically for the role.

Additionally, some of the roles are likely to rotate project to project. A co-pilot one project might handle tooling the next. All roles call for competent people, and a variety of perspectives is likely to be a boon.

~~~

Examining the roles in turn, as to "is it programming?" and "does it require a programmer?":

"The surgeon" - Obviously this is principally a programming role, although it does include managing documentation. As that's often presently part of a programmer's role, I don't expect this is your complaint - if it is, state it more clearly and I'll address it.

"The copilot" - Ted implies this is not "really" a programming role. I disagree. In addition to what sounds like pair programming and/or code review, and coordination with other teams, we find in the TMM description: "He researches alternative design strategies[,]" which is likely to involve prototyping, and "He may even write code, but he is not responsible for any part of the code." It is true that the role is probably less actual coding than being the surgeon, but doesn't sound like less than some programming roles in industry today.

"The administrator" - This is clearly not a programming role, but equally clearly doesn't require someone trained in programming. The same is true of the secretaries and the program clerk, with a note that much of the workload in these roles can be dramatically reduced by automation (Git + Travis seems to be 70% of "the clerk") and in many cases these roles can probably be shared by one or two people.

"The toolsmith." This clearly benefits from a programming background. Whether it's a programming role seems to depend on context. Certainly, rolling custom editors isn't likely to still be a thing. Massaging an editor plugin might be (and with fewer people working directly on the code, targeting their environment is maybe more tractable). Tools for interacting smoothly with any custom data formats (or any additional semantics on top of standard data formats). I could see this easily extending to "I need a library that does X" - from Brooks: "The tool-builder will often construct specialized utilities, catalogued procedures, macro libraries." - although that may overlap with "the co-pilot".

"The tester" - people wanting to code winding up in testing is already a thing that happens. That said, there's actually quite a lot of coding that can be done here, especially moving into generative testing. I'd also consider, on smaller projects, collapsing "the editor" in here, with an eye to assuring the test suite keeps the docs honest.

And lastly, "The language lawyer" is all about the code - probably more so than "the surgeon", who has some additional responsibilities. This is a role for experimentation and demonstration. "The language lawyer can find a neat and efficient way to use the language to do difficult, obscure, or tricky things. Often he will need to do small studies (two or three days) on good technique."