
How to work with Software Engineers - SanderMak
https://www.kennethnorton.com/essays/how-to-work-with-software-engineers.html
======
hvs
I know where this article is coming from, but I guess I've just been lucky to
work with a lot of great PMs that:

1) Are a firewall between upper management and the development team.

2) Organize the priorities of the team and help the developers to get the most
done in the limited amount of time that they have.

3) Follow up on business requirements and the thousands of other details that
need to be figured out so that the client doesn't say, "what the hell is
this?" on delivery day even though it is precisely what they asked for (but
not what they wanted).

4) Praise the team for the great work that they've been doing and make their
successes known to management.

I've worked with as many (or more) crap developers as I have PMs, so I'm
always wary of articles like this. It's way too easy to talk about how
management/sales/PMs/etc don't add any value to the process (which is patently
false) while lionizing the work of the developer as if they are all dedicated,
hardworking, and never, ever, make mistakes.

This "us vs. them" mentality that exists is ridiculous. We are all trying to
accomplish something. Some are better than others at it. But don't shit on
someone else's job, complain about how you want to be left alone, and then
wonder why your career isn't going anywhere.

~~~
bmj
This has generally been my experience, but even the best product manager I've
worked with will occasionally do something, well, dumb.

Just like engineers do sometimes.

------
edw519
Cute. Nice fake list. Nice writing. The "true" list at the end, like a
Hollywood ending, was probably not necessary.

Now my list:

1\. You don't "work with" software engineers. We don't even "work with" each
other. If you don't learn anything else from this, get this: we work alone.
Always. Even when we think we don't. Sure, we occasionally get together to
plan, analyze, discuss, white board, even "pair program" whatever that means,
but sooner or later, we all sit down alone and do what we do. With that in
mind...

2\. Leave us the fuck alone! If you see a software engineer looking at a
screen and typing, that means we're BUSY. Do not interrupt. Do not call. Do
not text. Do not IM. Do ask if we're busy (WE are!). Do not tap us on our
shoulder. And whatever you do, don't just stand there waiting for us to stop
typing (We won't; that's a test of wills you will lose). Just send an email.
That's it. When we break, we'll check email and reply. If you don't write well
enough to communicate with us, then learn how to.

(If my language seems a little strong, it's because I feel so strongly about
this. Nothing is more frustrating to us than having work to do and being kept
from doing it when we want to. We often need large blocks of time and room to
focus deeply.)

3\. Don't try to understand how we work, what makes us tick, what turns us on,
or the "secret" to making us more productive. a. All those things are
different for every one of us. b. We don't even know what they are ourselves.

4\. Don't patronize us. Sure, we all appreciate beer, donuts, chocolate, and
foosball, just like everybody else, but don't bother trying to get something
from us with a gimmick. It may work once or twice, but then never again. That
shit doesn't even work on your dog. Why do you think it would work with us?

5\. Provide us with the resources we need. This is pretty binary. Do this and
get results. Don't do this and don't get results. For the most part, we're
fairly easy. A comfortable chair. A decent machine. Good lighting. Fresh air
or HVAC. Peace and quiet. Decent facilities. Specs or requirements > 50%
accurate. (Forget about 100% accurate; none of us has ever seen that; we'll
live with 50-80%.).

6\. When we tell you we need something, believe us!.If we need clarification
on something, get it. If we need more time, give it to us. If we need access
to someone/something, make it happen.

7\. Never lie to us. We are used to our machines always telling the truth. We
insist on no less from other humans.

8\. Contrary to common belief, we do not hate the following classes of things,
we just hate idiotic instances of them: meetings, status reports, timesheets,
processes, procedures, policies, mission statements, motivational posters, HR,
reviews, interviews, reports, specs, and team-building exercises.

9\. The best thing you could possibly do for us: everything you must and not
one thing more.

10\. Top ten lists suck (except this one).

~~~
sheri
> We don't even "work with" each other. If you don't learn anything else from
> this, get this: we work alone.

I don't get this. I like working in a team, and like working with people. I
can't imagine working alone all the time. I am more productive when I am with
the team, and interacting with the team than when I am alone in a room.

I know everyone works differently, but almost no one seemingly is willing to
discuss an alternate version of this. I'm tired of the old 'meetings suck,
PM's suck' cliches. When I was working for a large internet company, we got a
lot of work done in meetings and lots of PM's were respected.

~~~
pifflesnort
> _When I was working for a large internet company, we got a lot of work done
> in meetings and lots of PM's were respected._

How did you get work done _in_ meetings? By definition, meetings are stopping
work to communicate; the most work-efficient approach is to optimize away the
need for meetings as much as possible.

~~~
jmilloy
> By definition, meetings are stopping work to communicate

You have implicitly and uselessly defined "work" as "everything you do that's
not communicating".

I can write code and solve problems all day long by myself. So can my
coworkers and housemates. When we have meetings at work, we figure out _which_
problems to solve and _why_. Why is it that the coding part is considered
"work" and the meetings is considered "not-work"? I would just be a lone
programmer working on subsets of the wrong problem without the meetings.
Lately, I feel like the "work" gets done in the meetings, and I just tidy up
afterwards (for a few days) by myself. That's because the answers are easy,
but the right questions are hard.

Let's try this: _meetings are stopping implementing to communicate._ Or, from
another perspective, _coding is postponing meetings until new issues/questions
have been solved._

~~~
pifflesnort
> _Why is it that the coding part is considered "work" and the meetings is
> considered "not-work"?_

In kernel terms, meetings and PMs are the scheduler, and you are the
threads/processes being scheduled.

Is the scheduler doing work? Yes. Is that work simply overhead required to
keep the pipeline full and fair scheduling of work occuring? Yes.

> _Let's try this: meetings are stopping implementing to communicate or from
> another perspective coding is postponing meetings until new issues/questions
> have been solved_

Or to put this another way, meetings are a page fault interrupt that is taken
because the necessary backing store (the solution to issues/questions) is not
available.

They're almost pure cost. Spending any more time there than you absolutely
need to is a waste.

~~~
jmilloy
> Spending any more time there than you absolutely need to is a waste.

This is a tautology. Spending any more time _anywhere_ on _anything_ is a
waste. The point that you're missing is that just because some meetings add no
value doesn't mean that no meetings add value.

~~~
pifflesnort
> _The point that you're missing is that just because some meetings add no
> value doesn't mean that no meetings add value._

The fact that _some_ meetings add value doesn't mean _all_ or even _most_
meetings add value.

My analogy holds; page fault handlers add value. They also incur a heavy cost
and you want to avoid faulting if it at all possible.

~~~
jmilloy
I agree. You asked "How do you get work done in meetings" and implied it was
impossible. I argue that just because there is no work accomplished in _your_
meetings or _most_ meetings doesn't mean that no work can be done in meetings.
No one _anywhere_ is suggesting that valuable work is accomplished in all
meetings. But when you suggest that _no_ work is accomplished in any meeting,
you're wrong.

I'm sorry you've had such a bad experience with meetings; it must be common or
the stereotype wouldn't exist. My workplace is different. Since my most
valuable work is accomplished in meetings, I wish I could be in meetings all
of the time. The only reason I can't is because we frequently need long breaks
to _implement_ the work we did in the meetings. In fact, coding is a much
heavier cost than meetings; unnecessary coding is much worse than unnecessary
meetings and you want to avoid unnecessary coding at all costs (even though
it's usually still quite fun). Just because you develop software doesn't mean
you should spend as much time as possible writing code. Just because you
produce code at work doesn't mean you're only working when you're coding.

~~~
pifflesnort
> _But when you suggest that no work is accomplished in any meeting, you're
> wrong._

This is where we disagree. Talking about work isn't tangible work. Talking
unblocks work, to a point.

> _I'm sorry you've had such a bad experience with meetings; it must be common
> or the stereotype wouldn't exist._

Given that my experience spans roughly 15 years, major corporations, small and
large startups, in both management (director, VP, and C-level roles) and
engineering (software, systems) I'm inclined to trust my experience that
meetings are generally a work-substitution mechanism and a means of furthering
political/social career advancement, and bad PMs (which is, sadly, most of
them) are the worst offenders of them all.

~~~
bennyg
Man, no offense, but you seem extremely short-sighted here. So when you and a
couple coworkers are architecting a system, deciding what the pipeline of
information flow is going to be, where the security holes may be, stopping any
latency or unnecessary operations, and making sure the user knows how to use
the damn thing on top of that - and you aren't writing code, but instead
communicating with your coworkers - you don't think that's work? How could it
not be?

------
fotbr
The sad part is that my current boss follows his "do not" list to the letter.

Yes, I'm working on leaving. Eight hours of that crap in the office, then
usually 2-3 hours of job hunting in the evening after working in the yard or
otherwise getting the house ready to sell.

~~~
krmmalik
The even sadder part is that the "do not" way of working is the norm and the
"do" is the exception in majority of the workplaces. And what these people in
leadership positions don't realise is that it's good management that creates
great results which directly affects the bottom line.

This is why the good start-ups do well because they manage better which
results in better output.

~~~
p0wl
have in mind that this will only work if you have great workers, that are able
and willing to help theirselves. This attitude will be destroyed by continous
bad leadership and will not come back very fast.

~~~
krmmalik
Tell me about it. Been there, done that. But to be fair, if you have good
management, they'll do a good job of hiring in the right type of people as
well. So it works both ways.

------
Kurtz79
Honestly, I didn't find the article particularly funny or original, but I
can't really blame the author for it.

It's probably one of the cases where reality exceeds the worst exaggerations
one can come up with.

------
seivan
Start the morning with some coffee and sarcasm. Fun read. Though it might be
problematic that some managers might take it serious. Usually the dumb ones.

~~~
michaelochurch
I think that's why he said (paraphrased) "I troll U" at the end. Most software
engineers would get the joke immediately, but many managers wouldn't.

The problem is that executives never read to the end of anything. They still
have to call their kids (or interns, same thing really) in to show them how to
work a "scrollie bar".

There was a very large company that required every employee to submit a
63-word summary of accomplishments per quarter (do they still do this?) I
pointed out, rather publicly, that this was precisely the low-end of adult
reading speed (3.5-8.0 words per second being the typical range) times the
short-term memory loop (18 seconds). That didn't go over well.

Ah, managers. They sure love sunbathing in the Yucatan, but that bright point
just above them isn't the sun...

~~~
mwfunk
I can't tell if this is parody, or a parody of a parody, or a parody of a
parody of a parody. The tone is very much like the original article, but as if
written by a hypothetical Scumbag Steve software engineer rather than an
imaginary Scumbag Steve management type.

------
rian
Is it just me or is this article a bit condescending? This makes it seem like
software engineers are exotic creatures that normal people require a guide
like this to work with. What if someone made "How to work with PMs" or better
yet "How to work with women"? I feel like one of the core problems between
PM<->Eng is that both sides stereotype each other, this just perpetuates that.

The rules in the afterward make sense but if you need a guide on the internet
to get you to do those things, I'm not sure I want you to become a great PM in
the first place. The problems here seem to be more fundamental, like: _Don't
be a psychopath_. I think the rest of the rules should follow naturally.

Has the profession of PM become so bad that we need "don't be a psychopath"
posts?

~~~
lotyrin
I think that's intentional. Imagine the impact of your "How to work with
women" list with similar satirical pseudo-rationalization of bad behaviors.

The existence of the list seems as much an example of what not to do as are
its contents.

~~~
rian
Sorry, I knew it was intentional but I mean, despite the sarcasm, it still
feels condescending. Just the pure existence of an article with the title "How
to work with women," no matter how accurate, would still be condescending and
bigoted. It's because all women are different, just as all software engineers
are different.

------
krmmalik
Grrr. I was going to do a presentation on exactly this next week, and have
just put a presentation together on management that pretty much says all these
things but Kenneth has done a far better job. I guess I'll go in the corner
and sulk. Just kidding :)

------
goyalpulkit
All I was thinking was how wrong could this be until I reached the 17th slide.

~~~
michaelochurch
I loved it because I actually believed it (with vehement disagreement) until
about a third of the way through.

~~~
bluehex
I hated it for the same reason. I find this kind of sarcasm manipulative. The
piece had me pissed off by the end until the reveal, which made me even more
angry. Maybe as a talk it might be slightly more tolerable since you can
presumably hear the sarcasm in the speaker's voice.

~~~
goyalpulkit
I pity the engineers whose managers read this list but don't go all the way to
the end.

------
dsdjung
A good guide, but not an answer to all. Software Engineers are humans, and
everyone of them are different. So, if you want to work with Software
Engineers well, get to know them first.

~~~
krmmalik
This is the point I agree with the most. When I first started working with
developers, a person I highly respect said to me that the most important thing
you can do when working with anyone in a technical field is to win their
respect. You don't have to be an ace at development or engineering yourself.
You don't have to know the craft as well as they do, but there are many things
you can do to earn your delegate's or colleague's trust and respect.

------
mvkel
This is a great list of what _you're_ receptive to, but it's silly to use a
person's position as a replacement for their personality.

The reality is, not all developers want to be "left alone," just like not all
developers want to talk to people.

Why not invest in the person and tease out _how_ they want to be interacted
with instead of making assumptions one way or the other?

------
rcavezza
It wasn't until I read the hn comments here that I noticed the "No, don't do
any of these things" part of the post.

I think he should make the bold NO in the slideshow much more noticeable in
the blogpost.

The sad part is that most PMs I know skim too and will have all the wrong
takeaways from this post.

~~~
ricardobeat
If someone goes past the 1.000.000 estimate in the third paragraph without
feeling uncomfortable, he deserves it.

------
hcarvalhoalves
Oh my god, this is priceless. Sadly, this is like a manual of what happened in
my past job.

------
GhotiFish
He has slides. Did he do a talk? Was there a video?

because that would be a great video.

~~~
kennethn
It wasn't officially recorded, although audience members might have captured
some of it. I wish it had been: I can only really give this talk once.

As an aside, if you're not familiar with the Ignite format it's great. You
have 20 slides, and each slide auto-advances after 15 sec. So I really had to
practice the timing.

------
jschuur
I wish this post were written in a less sarcastic tone and more directly. It's
an important topic and deserves to be less off putting than it otherwise seems
at first.

~~~
ojbyrne
It's a long standing rhetorical device known as "humor."

~~~
cllns
The OP seems to be aware of this. He's stating it would have been better to
just state his 10 points rather than hide behind sarcasm. (I agree.)

------
wallunit
I was surprised how many thing the management of the company I'm currently
working for is doing right, until I reached the afterword. ;)

------
_pmf_
I actually looked up the cited book in vague hope and was moderately
disappointed; I'd read it.

------
grigio
Yeah, let's build a baby in a month using 9 moms.. I'm sure You can do it!

------
antonwinter
a while back there was a post here about quadrant methodology. it fits nicely
in with it <http://quadrant.tumblr.com/>

------
asah
nice one, Ken!

All-- having worked with Ken, he's indeed awesome.

------
michaelochurch
That's brilliant.

However, I don't think it's only PMs who indulge in that behavior. I've seen
managers and engineers (yes, indeed) do the same shit. Internal competition
within companies is pure corrosion and it's _always_ detrimental. I'm
convinced that there are no exceptions to that.

The rare good manager is K-selective insofar as she intends to reproduce
(scale) processes with _quality_ and moral decency. If she runs a company, she
won't hire before she trusts, and she'll make sure everyone gets credit and
autonomy. Most managers are r-selectors, though; they over-hire, don't trust,
and throw shit at the wall until something sticks.

The egoistic bad-guy PMs being described here are the ones who thrive in the
typical r-strategist corporation.

~~~
GFischer
Had to look up R and K selection:

<http://en.wikipedia.org/wiki/R/K_selection_theory>

~~~
michaelochurch
It's what I'm focusing on as I study organizational decline. It turns out that
the metaphor (reproduction of processes, skill sets, and values) applies to
corporate life. The reason most jobs suck balls is that most companies are
r-strategists.

The r-selective alpha male was the harem owner who treated his "wives" like
chattel and invested nothing in his (hundreds of) children, most of whom would
fail. It was "spray and pray". The K-strategist was the monogamist who treated
his one wife well (often, as an equal) and invested heavily in the health of
mother and children.

The r-strategist boss doesn't mentor employees, creates a sink-or-swim
environment, and over-hires, generating internal competition, which is always
toxic. The K-strategist hires more slowly but invests trust and interest in
the people brought in. Of course, r-strategist companies grow a lot faster
and, in many spaces, are much more "fit", but I believe that's going to change
amid the convexity of post-technological work.

~~~
aswanson
Could you expound on what you mean by post technological work?

~~~
michaelochurch
Essentially, I mean that technology is taking the boring, commodity work away
from humans and the stuff that remains can't really be managed into existence.

~~~
aswanson
oh, okay. I thought you meant that we were entering a phase of economic
development where technology had obsoleted itself as a business advantage.

~~~
michaelochurch
Oh, no. If anything, it's the opposite.

"Post-technological" was terrible word choice on my part. I meant "post-
technological _transition_ " but there is no way anyone could have known that
based on what I actually said.

The last transitions were 10000 BC (into agrarian) and about 1750 (into the
industrial era). The technological transition is underway. We're probably
10-20% technological at this point.

------
ttrreeww
I've seen people do this at my last startup, needless to say, they are now
tanking. Close to a 100 million VC dollar going down the toilet... Those
people got promoted really high too...

------
hawleyal
I see what you did there.

