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

[G. Branden Robinson]

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20250720/cd440976/attachment.sig>