Hacker News Reader

Comment by taeric | Hacker News Reader

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.

View on HN

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

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

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.

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"

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

Reply on news.ycombinator.com