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

[Larry McVoy]

As I said to Warren, that is partially on me.  I have a bad habit of letting
myself get drawn into discussions where I should just let it go.

I apologize for the noise, added Brandon to my procmailrc so I'll not see
his emails.  Not sure what I did to draw his ire but I'll not feed the 
fire in the future.

For the record, I was shaken up about this exchange as well, came pretty
close to unsubscribing so I wouldn't cause problems down the line.

I'm retired, I love going down memory lane as much as the next guy, but
having a fight?  At my age?  Please, no.

On Sun, Jul 20, 2025 at 05:40:12PM -0600, Marc Rochkind wrote:
> 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.

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat