Hacker News Reader

Comment by revvx | Hacker News Reader

It's the second time I mention Fred Brooks on HN today, but he dedicates a chapter in Mythical Man-Month that agrees with the assertion of the article:

> Much as a surgical team during surgery is led by one surgeon performing the most critical work, while directing the team to assist with less critical parts, it seems reasonable to have a "good" programmer develop critical system components while the rest of a team provides what is needed at the right time.

Other team members perform other tasks, and some of those even administrative (!), but all of them supporting the "vision" of the surgeon.

IMO this is a healthier way of communicating roles, avoiding fights and training juniors. It's better than the "everyone is replaceable" mindset companies have this day.

View on HN

Surgery is a dangerous comparison to make. Most surgeons get to their seniority by doing a lot of surgery. Most of which are near identical to each other.

Programmers? We, for some reason pride ourselves on doing something new every time around, it seems. I've argued before with my leadership that, if we really wanted something done better/faster, we shouldn't be promoting the folks that did it out of the position for the next go around. Rather, we should have them do it again. And then again. And then again. Not only would they be learning from their experiences, but benefiting much more directly.

> I've argued before with my leadership that, if we really wanted something done better/faster, we shouldn't be promoting the folks that did it out of the position for the next go around

This is similar to what Fred Brooks suggests in the "Surgical Team" chapter of "Mythical Man Month", although he's a bit harsh, I'll grant that:

> if a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming.

EDIT: We were also talking about it yesterday here at HN: https://news.ycombinator.com/item?id=19763562

And not forget to fire those other managers who never wrote a single line of code.

Or anyone who thinks in terms like 'programmers' and 'resources'.

Brooks idea was even more radical:

Put non-coders to work under the chief programmer. Let them help instead of control.

That makes total sense to me. Having engineers in charge of the challenges that require engineering.

Completely agree. Thomas Pornin told me he wrote 10 TLS implementations before writing BearSSL. And it shows.

Fred Brooks agrees with that. That's what he says in Mythical Man Year, referring to prototypes:

"Plan to Throw One Away"

> We, for some reason pride ourselves on doing something new every time around, it seems.

You can't copy and paste a successful surgery from one patient to another.

> I've argued before with my leadership that, if we really wanted something done better/faster, we shouldn't be promoting the folks that did it out of the position for the next go around.

I'm confused by this - why are you (re)building the same thing multiple times?

Why are you not building on what was done before, regardless of who did it? It seems to me that either the people choosing to start over are making the choice irresponsibly, or the previous work that got someone promoted actually wasn't that great (not extensible/reusable/documented/etc). In both cases, I'd be asking management some tough questions about what they've done and/or allowed to happen.

The ideas are built on. The code? Our industry is constantly modernizing things in the name of technical debt. Often, the call gets made to make a new offering to replace the mistakes of the old.

And I'm, frankly, calling bs if you are claiming this as not something that happens regularly. Just look at all of the articles that constantly crop up of the form "why we left technology x for y".

What if the surgery analogy doesn't compare favorably with an entire project. How about a code review comment or an email thread?

I don't pride my team on doing something new when there is a tried and true way of doing it. Only when there is a need for a new way that the tried and true way doesn't cover and is a bottleneck.

From my experiences, this attitude is in a large minority.

I'm tempted to say this isn't bad, either. It is amazing what people can do retreading topics.

I agree, but time and place.

Microsoft has an idea like this - with the same surgical analogy. Sometime during the MS Word initial development process they tried it out - and the "surgeons" loved the idea, but everyone else hated it - especially as the half fleshed out ideas from the surgeons turned out poor or wrong.

I think the skill differences between individual contributors are never as great as you think.

cf "Software Heroes" book - has a wireframe cowboy hat in the front cover. v good

Joel Spolsky talks a little about this: https://www.joelonsoftware.com/2000/10/04/painless-functiona...

Microsoft's idea was very different from what Brooks describes in his book.

Microsoft approach was more about having senior programmers telling juniors what and how to do their job, aka micromanagement.

Brooks is about having programmers actually coding (and documenting), and have other people handling and other important tasks such as clerical non-programming tasks, developing tools, language research, version management, doing adversarial testing, helping with documentation, etc. Some of the tasks he describe are obsolete these days, but the book is from the early 70s.

According to him, doing that "relieves programmers of clerical chores, systematizes and ensures proper performance of those oft neglected chores, and enhances the team's most valuable asset — its work-product".

Except that you're usually building knowledge specific to the organization in which you're working. IMO, you should avoid monopolizing vision and knowledge. I see this as different to the surgical team, where each patient is a different "project".

Communication and knowledge should be considered part of the product. You often times still need these kinds of developers to deliver even this aspect. Basically someone who groks the project so thoroughly that they can synthesize disparate pieces of information into something holistic and absorbable.

Building good documentation and sharing knowledge is crucial for such teams to work, according to Brooks. Brooks is all about (good) communication. The "Surgical Team" chapter comes right after the "Communication" chapter in MMM.

And I don't think that having other members of the team supporting the vision of the leader is monopolizing the vision... it's just being focused on a single goal.

There are trade offs to everything - generally I haven't seen the best results from attempts to make people inteechangeable to put it mildly.

Yeah, because at a certain level it's not monopolizing knowledge, it's just not letting people without ability act as though their lack of ability is inconsequential and their agendas matter. In surgery they don't have lack of ability or agendas.

Let me chime in. I've been consulting crypto(graphic) projects for years and systems that are developed by one person are way way clearer and simple than systems developed by nultiple developers. Things like TLS become a mess once multiple developers start collaborating. It's weird. My theory is that one dev working on a project can refactor it many times during development, whereas this would be an insane thing to do when collaborating.

Why would major refactoring be insane when collaborating? We do this regularly in my team in early stages of projects and only when really required once projects become stable. But these projects are usually not about crypto, so I might miss the difference here.

Yes. After many years I have exactly the same experience that you do.

Programming intent and vision is hard to communicate, so sharing code is always a compromise. It's much better to work with smaller units of code that communicate with each other using simple, clear and testable APIs.

Yep. That what makes Golang so awesome. One person can own one package.

What’s special about Go packages, as opposed to packages in other languages?

> systems that are developed by one person are way way clearer and simple than systems developed by multiple developers

Brooks called this "conceptual integrity":

https://en.wikipedia.org/wiki/The_Mythical_Man-Month#Concept...

You can (should) also give leadership to juniors on appropriately sized projects. That's how you make better programmers.

You should give leadership/ownership/responsibility of smaller components of the larger vision to juniors or people new to the team.

Most companies want more business value, they dont care for better programmers.

Next time said companies complain about a talent shortage, they would do well to remember TANSTAAFL.

Because I had to look it up: TANSTAAFL = There ain't no such thing as a free lunch

TANSTAAFL

Have that ingrained in my mind since reading Abrash forever ago.

You mean Heinlein?

Never read Heinlein.

I know it is reification but most companies end in banrkruptcy.

In all seriousness I have noticed that "business value tunnel vision" is one of the surest ways to run a company into the ground in many if not most fields and Wall Street keeps pushing it anyway to nobody's benefit. The fundamentals of the field are what you have to care about or else you will have a really bad time.

Yes, and investing in employees pays dividends.

Many businesses are poorly invested and put themselves at a disadvantage.

> also give leadership to juniors

You don't give leadership - you assign ownership, and hope leadership evolves from those responsibilities. Leadership is nurtured by helping the junior navigate issues, holding a vision for them long enough until they can realize it on their own.

There's a reason good leadership is so rare and appreciated, and it's not because it grows on trees.

Simon Sinek has a great presentation in regards to that topic if someone is interested.

Famous "Do you love your wife?"question and more.

Link?

https://www.youtube.com/watch?v=TopBJ7fAIgE

This sounds like a question for management. I suspect the healthy attitude is to not even care what a good managerial approach is—simply show up, do whatever the easiest thing that lines up with management priorities, and leave, managing the rest of your career outside this. Unfortunately I feel like some managers become enraged if you “check out” of doing their managerial duties for them

there's one issue that large companies face, after two/three years all the juniors in the "surgery team" model start looking at position of seniority within or outside the company, causing high concentrated turnover in such built teams.

the surgical team is great in a crunch but long term you need to stagger your turnover to keep competency on the project high.

this isn't as relevant on team that are building projects as they were in the mmm time, today companies tend to build service software that has maybe the same shelf life but gets continuously improved instead of being dropped whole and left into maintenance mode.

> after two/three years all the juniors in the "surgery team" model start looking at position of seniority within or outside the company, causing high concentrated turnover in such built teams

Is that a problem?

I mean, the same thing happens with literal surgeons/doctors and residency, where their early years of career eventually end and they expect a mid-level position in the organization.

It sounds like a healthy industry that juniors/apprentices work under journeymen and masters at a large organization early in their career, then move up or branch out after a few years.

I'm not sure why companies expect to be able to cost-optimize away a functioning economy, but remain in business.

while moving on is natural for the persons to a software company it's a costly proposition and quite different than surgeon teams, because while humans are all more or less similar projects are wildly different so there's less interchangeability.

also while surgeon tend to specialize into one in the many fields, programmers that rise in a "surgical team" tend to become of the "full stack" variety

> not sure why companies expect to be able to cost-optimize away a functioning economy

I'm with you here, I'm not stating this is the optimal way to handle the issue, just reporting the patterns I saw on many workplaces of all kind I've ben into

That sounds like a secondary management problem to have other projects lined up. Although that isn't new - one or two years is already an effectively encouraged time to look for new jobs because raises don't keep up and changing jobs is the current defacto way to raise salaries. Seems like a needless expense and hassle to all involved and yet it seems strongly preferred oddly.

Reply on news.ycombinator.com