[TUHS] how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference))

[Marc Rochkind]

Maybe Doug's comment was too succinct.

This back-and-forth personal argument, laced with insults and disrespect,
seems wildly inappropriate for TUHS.

Marc Rochkind

On Sun, Jul 20, 2025 at 4:22 PM G. Branden Robinson <
g.branden.robinson at gmail.com> wrote:

> Hi Larry,
>
> At 2025-07-20T04:38:02-0700, Larry McVoy wrote:
> > On Sun, Jul 20, 2025 at 02:59:08AM -0500, G. Branden Robinson wrote:
> > > At 2025-07-19T20:16:33-0500, Will Senn wrote:
> > > > I've thought about the "if you worked for me", dig and it kind of
> > > > stung.
> > >
> > > Manure often does.
> > >
> > > Larry came up in the soil from which grew tech bro culture.
> > >
> > > A preoccupation with managing the preferences of others, as with
> > > Steve Jobs's "thought leadership", is consistent with the
> > > authoritarian style he advocates.
> >
> > Huh, you won't be surprised I have a different perspective.
>
> Indeed not.  :)
>
> > Allow me to tell you how I describe managing engineers.  Suppose we
> > were artists, there were 4 of us.  Someone brought us a photograph and
> > said "I want a painting of that".  OK, split it into quarters and go
> > do it.  What do we get back?
> >
> > Well, artist #1 likes oil paints so that's what s/he did.  Artist #2
> > likes charcoal so that's what they did.  Artist #3 likes pen and ink.
> > Artist #4 likes water color.
> >
> > Is that a painting?  Maybe if you like a mish mash of stuff that
> > doesn't go together.  Most people would call it garbage and refuse to
> > pay.
>
> Yeah.  I think your analogy is facile and superficial and therefore
> characteristic of of Silicon Valley executive culture.  Here's why.
>
> First, text editors don't leave traces of themselves in the work
> product.[1]
>
> Second, _especially_ in a leadership position (although this is more
> specifically the role of "architect" if someone has it), you have to be
> conscious of the boundaries of your software modules.
>
> A software project of sufficient complexity to be worth commissioning on
> a professional basis is, despite its contractual representation at the
> executive level, not a unitary object like an individual painting or
> photograph or 2½-minute folk song.  Such things are not (formally)
> complex, but "elemental": if you decompose them, they stop being what
> they are.
>
> Often, a first-order decomposition of a software system leaves you
> with...a collection of other software systems, plus, ideally, some
> ancillary documentation and/or an integration test suite.
>
> > My so called "authoritarian style" is nothing more than I was the
> > leader, I had to pick one style.
>
> Right.  To hear you tell it, you preoccupied yourself with matters of
> style and let others worry about the harder problems of architecture and
> interfacing.  Maybe that was the right choice given your skill set and
> those of your staff.
>
> If that characterization cuts, there is a remedy: share a leadership
> anecdote where you made (or mediated) a hard decision on a non-stylistic
> matter.  Maybe two algorithms of the same order in big-O notation were
> pitched for a certain software module, but one was preferable on some
> non-obvious basis.  You've spoken before of the high value of SCCS's
> "weave" to BitKeeper.  Was there anything the weave made hard or was bad
> at?  Were you ever on the verge of reconsidering it?  If so, what, on an
> _engineering_ basis rather than one of style or personal admiration,
> mandated its retention?
>
> If you have stories like that, those would, to me, constitute examples
> of technical leadership.  And, if all "stakeholders" (your client[s]
> _and_ your staff) were happy with the outcome, then they could be
> examples of _good_ technical leadership, too.
>
> > And, yes, it means if you have N people working you usually have N-1
> > pissed off people because they weren't getting to do things their way.
>
> I suspect you accurately perceived the presence of frustration.  I also
> bet you assumed its cause rather than undertaking an earnest exploration
> thereof.  A confounding factor here is that a project can have so many
> problems that the individual contributors themselves have trouble
> accurately identifying an "overall" problem or a single "worst" one that
> they have.  Further, if they are experiencing deadline pressure, whether
> imposed by themselves or by leadership and are asked to identify
> "blockers", they're likely to name the obstacles that are easiest to
> articulate[2] or that they most recently struggled with.[3]  One
> generally can't calendar the removal of as-yet-unarticulated problems.
> If the engineers have the same blocker day after day, then management is
> failing to remove them.  If the engineers have NEW blockers every day or
> every week, and you have confidence in your recruitment/hiring, then
> the staff is not sandbagging you--the project has deep problems.
>
> My personal experience is that underspecification and otherwise
> unarticulated expectations are the root causes of nearly every problem
> that cause anguish among staff.  And behind that problem is the worse
> one that managers climb into contractual beds with their counterparties
> without having done their necessary homework first.  The client never
> wants to admit that they haven't really though through what it is
> they're asking for.  They've already made promises to a director, VP, or
> someone in the C suite.  So they yell at you and you yell at your staff.
>
> The manure, as it were, rolls downhill.
>
> > Letting them do things their way means there is no overall picture you
> > are driving towards.
>
> In engineering, we do not implement an "overall picture", but to a
> detailed specification.
>
> If you lack a detailed specification to implement, what you are doing is
> not (solely) engineering.  That's not necessarily a bad thing; you are
> engaged in design and possibly in research.  Charge more.  Develop your
> staff by helping them get conference papers out of the work.
>
> > And I'm not above being overridden.  I personally hate GNU make for
> > all the similar reasons you are advocating for a smaller vi.
>
> That wasn't me, but I'll freely admit that Vim has many features I don't
> use.  I have found that time spent seeking mastery of one tool is good
> practice in judging the "right-sizing" of another.  If nothing else, it
> helps one learn which hills aren't worth dying on.  ;-)
>
> Regarding make(1), POSIX 2024 has made it _much_ better.  I still think
> the BSDs' snarling adherence to old-style suffix rules, which are
> inflexible and ambiguous, and restrictions on $< are counterproductive,
> but a lot of stuff that used to not be portable, is portable now.
>
> > But my team convinced me it was less work to move to that than
> > maintain all the scripts we were using to use a simple make.
> >
> > But yeah, when people work for me, I lead.  I set the tone.  It wasn't
> > tech bro nonsense, it was about herding people towards the same
> > picture.
>
> I have a slender hope that I can persuade you that these things are
> actually the same in every way that matters.  As implied above, this
> doesn't make you a tech bro yourself, necessarily, it might mean you're
> emphasizing the wrong elements of your experience for an audience of
> salty old engineers, contrast with venture capitalists.
>
> In martial arts training, there are "degrees" of black belt.  Only the
> first few degrees have anything to do with one's own ability or
> perfection of form.  After that, your advancement is determined by how
> many black belts you _train_.  To become a master, you must train many
> black belts.  To become a grand master, you must train many masters.
> While I'm sure there are perverse incentives in martial arts instruction
> (hello, capitalism), this approach of making your own advancement beyond
> a certain point dependent on the development of people no longer
> accountable to you strikes me as a worthwhile corrective to the
> narcissistic orientation of leadership in software development.
>
> Being a good example is a different phenomenon than being an object of
> emulation.  One phenomenon is deep, the other shallow.  Steve Jobs was
> good at producing a lot of fawning emulators with black turtlenecks and
> glib proclamations about the future of technology.  Steve Wozniak has in
> substantial measure dedicated himself to producing more good engineers.
>
> > I wasn't trying to tell Will he can't use whatever editor he wants, I
> > was trying to tell Will I wouldn't tolerate this much back and forth
> > about his personal preferences distracting us from shipping product.
>
> That's not how I read what you said, but fine.  I agree that bickering
> over tool choice can be a distraction from satisfying the contract and
> getting the final payment.  But the sword of opportunity cost cuts both
> ways.  You can't always be sure that the most readily available
> substitute good for an editor argument is a laser-focused coding
> session[4] on implementing an element of a deliverable.
>
> If your engineers are motivated, you will find that they don't distract
> themselves with nonsense _when they have a better alternative_.  A good
> engineering manager deeply understands the XKCD concept of "nerd
> sniping" and knows how to adapt it to the benefit of the individual
> contributor, their team, the client, and consequently themselves.[5]
>
> > My team had emacs people and vi people, nobody cared so long as you
> > got your job done.
>
> That's a salutary attitude.  But engineers also need time and vehicles
> for decompression, and one of the things they can use their downtime for
> is playful practice at evaluating tradeoffs between competing designs or
> systems.
>
> If you have an engineer who's going around harassing their peers for
> choosing the "wrong" editor, the problem is not their choice of editor,
> which might be "correct" in your opinion.  The problem is that they're
> interfering unjustifiably with the work of their colleagues.  Addressing
> that problem "sets the tone" much better than expressing, let alone
> mandating, your own preferences.  It's what _I_ expect of a manager, at
> any rate.
>
> > What we didn't have is editor arguments clogging up our thinking.
>
> Done well--and this might happen only in a minority of cases--editor
> arguments can _enhance_ people's thinking; see "playful practice" above.
>
> And even if they don't, if they're no more destructive than a dispute
> over whether the coach of the local sportsball team was an idiot for
> benching player X in the Big Game last weekend, or than knocking off 30
> minutes early for beers together at the end of a frustrating day, then
> good leadership can mean leaving some rough spots unsanded.
>
> Regards,
> Branden
>
> [1] _Programmers_ might so do, with vi "modelines" or Emacs "local
>     variables" in text constitutive of a comment in the program source
>     code.  Different matter.
>
> [2] another instance of our old friend the "streetlight effect"
>     https://en.wikipedia.org/wiki/Streetlight_effect
>
> [3] https://en.wikipedia.org/wiki/Recency_bias
>
> [4] or automated test construction, or documentation revision--wait, why
>     is everybody laughing?
>
> [5] https://xkcd.com/356/
>


-- 
Subscribe to my Photo-of-the-Week emails at my website mrochkind.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20250720/4c3ff935/attachment.htm>