
The care and feeding of software engineers, or why engineers are grumpy (2012) - 1900jwatson
https://humanwhocodes.com/blog/2012/06/12/the-care-and-feeding-of-software-engineers-or-why-engineers-are-grumpy/
======
ledauphin
One thing this essay doesn't weave together, despite bringing up a lot of the
threads, is that timelines for upcoming work are often estimated based on the
(unrealistic) assumption that "you're going to leave me alone for long enough
to get it done", which never happens.

Instead, days get filled with discussions about future work, rehashes of
previous discussions, identifying the bugs that junior developers have
written, trying to convince management that the latest customer complaint has
more to do with the fundamental laws of physics (e.g., network bandwidth
limitations) rather than any actual issues with the software, etc...

All of these are part of the job, but the conception of developers as
"builders" worsens the issue because management does fundamentally believe
that we spend most of our time "coding" when that couldn't be farther from the
truth. And since we also want to imagine our days as filled with productive
programming, we feed right back into the lie.

~~~
drewbug01
> identifying the bugs that junior developers have written

Bugs are written by all seniority levels of engineers. “To err is human,”
after all. Junior developers hold no monopoly on mistakes.

~~~
Kalium
If anything, it's been my experience that the bugs from the junior devs are
often more obvious and easier to fix. Any junior dev can make a minor logic
error. It takes a senior dev to mis-architect a whole system.

~~~
rurban
Normally it's the mid-level dev who mis-architects a system. It's called
overarchitecturing. Seniors rarely overarchitecture.

~~~
watwut
Seniors both over architecture and underarchitecture.

~~~
rriepe
Yeah, I've found this to be more of a personality thing. Seniors just learn
more tricks to get away with whichever way they lean.

------
pedrorijo91
> Yet, you’ll rarely find software engineers complaining about long hours or
> being woken up because of a production issue. The software is our baby, and
> we like to care for it as such. That means if it needs feeding in the middle
> of the night, we do it. If it needs extra care over the weekend, we do that
> too, all with a smile because our creation is growing.

We need to stop this! We are promoting unhealthy extra hours. We are making it
like it's ok to expect/ask developers to work overnight and weekends. Work-
life balance is not just a cliché, we need to incentivise developers to have a
real life outside of work

> I was once about to leave my place with a date when the office called
> because of a production issue. She sat and waited patiently for an hour
> while I tried frantically to fix the issue before she ultimately took off (I
> couldn’t blame her), leaving me to my work and my coworkers in IRC sharing
> my misery.

is this company really so dependent of a single developer? unless it's a
startup with 3 employees it sounds like a problem. Or maybe the developer
thinks it's the only one able to save the day?

------
UglyToad
I hadn't seen this before but my god it's bang on every problem I experienced
in my jobs and pretty much exactly what caused my burnout.

I keep saying to people who ask what I'm doing next (currently taking a break)
that my problem is I love coding but hate doing it as a job and this article
has every reason why.

Just to call attention to the first point about being a short order cook, this
is precisely why scrum sucks and makes me so unhappy. You can't just give us
work shorn of all context and use us as assembly line workers. Unless you're
giving your developers full domain knowledge and involving them at every stage
of the process you're wasting talent and money and your company probably sucks
to work at.

~~~
jlarocco
> I keep saying to people who ask what I'm doing next (currently taking a
> break) that my problem is I love coding but hate doing it as a job and this
> article has every reason why.

I used to feel this way, but then I realized it's not useful. You're not going
to change anything, and nobody's going to feel sorry for you because most
people spend their whole day at work doing things they don't want to do. And I
mean in general, not just software jobs.

Work to pay the bills, and if you want to write code for fun do it outside of
work on your own terms.

If you want to enjoy work then start your own company. If you're working for
somebody else it's always going to mean doing things you don't want to do
sometimes.

~~~
shrimp_emoji
>If you're working for somebody else it's always going to mean doing things
you don't want to do sometimes.

Horrible things, things you're ashamed of, with horrible, antique tools.

Try to change what you can (it's hard not to try), but otherwise play the
detached mercenary and vote for the administration likeliest to implement UBI.

~~~
robocat
>>If you're working for somebody else it's always going to mean doing things
you don't want to do sometimes.

> Horrible things, things you're ashamed of, with horrible, antique tools.

And when you own your own company, you use horrible tools and create ugly
technical debt... But now the shame is personal because you can't easily blame
someone else.

~~~
Aeolun
I don’t see why you would ever do that. It’s not like the horrible antiquated
tools work any better than the modern ones.

------
itronitron
Years ago I heard about one of the main rules in improv which is that you can
never say 'no' because it shuts down the creative potential in the
performance. I took that to heart and applied it to work, whenever I wanted to
scream NO at someone I offered instead to try it out and see what we could
accomplish. Ninety percent of the time after further discussion it turned out
they were asking for something entirely reasonable, the other 10% of the time
there was either a compromise available or big money on the table.

Worth noting that as I stopped saying no I also stopped feeling treated like
an assembly line worker.

~~~
Z1515M8147
This approach is covered extensively in the book 'Getting to Yes And: The Art
Of Business Improv' by Bob Kulhan, which is one of the few books I would
consider a must read for anyone interested in technical leadership.

~~~
johntam
Any other recs?

------
unnouinceput
Quote 1: "You need to work somewhere that appreciates your insights into the
product as well as your ability to build it."

And that's why I love to be a freelancer - clients need solutions to problems,
they don't really care about design implementations/programming
language/database, and they love every bit of creativity that drives costs
down. I have clients that say on daily basis they love me, as they got one or
more wrong implementations initially because "my partner/rival/uncle/god from
heaven told me this is the way to do it" and when I propose something simpler
& cheaper they marvel.

Quote 2: "As ironic as it may sound, a lot of companies hire software
engineers and then don’t let them actually code. Instead, their days are
filled with useless meetings that inhibit productivity."

Oh boy, I loved my time on big companies, I learned a lot but this 2nd quote
hits me in the gut. Requirement meetings, regression test meetings, project
status meetings, fill this standard Word document with details, fill that
Excel document with metrics etc etc etc - I freaking hated them all. Sure, I
learned about importance of this and that but dudes: let. me. code!!

Siemens was the worse of them all, I suspect only 10% of the time I worked
there was coding, rest was everything of the above.

~~~
growlist
> Requirement meetings, regression test meetings, project status meetings,
> fill this standard Word document with details, fill that Excel document with
> metrics etc etc etc

...most of which never gets used for anything that contributes to the bottom
line, and exists merely to enable bureaucrats to maintain a facade of doing
Really Important Work

~~~
unnouinceput
It's not like that, they get used, and in most important way when you get
involved with others: CYA (cover your ass). You see, when you are that time
called annual performance review, these are the most important thing for your
team leader/project manager/group leader, you know those who will decide to
give you a Xmas bonus or bump your pay with 1%, to use to prove you don't
deserve any of bonus/bump because you are full of mistakes on said documents.
And if you do get any bonus/bump is shown like they make you a huge favor with
the promise that you need in the future to become even more of a spineless
monkey. Which is why currently we have this situation where coders jump ship
at slightest increase from rival, because any loyalty that was embedded in us
by our parents went out the window when we dealt with above situations.

------
bonoboTP
Many problems with this attitude.

First, just let go. You're building something for someone else, and making
money for them. Treating it as your own "child" and being so psychologically
invested will do you no good. In the grand scheme of things you're not
"changing the world" with that new photo app or enterprise CRUD plug-in.

Which ties in to the next point. Have a life outside work. Don't let work
define you and be your only claim to personal value. It's insane that American
programmers put up with so little free time. They want you on call? Then pay
for every on call night and weekend. Anything less than 20-25 days off per
year seems madness from Europe.

And that leads to the next point. As the TFA says, naive, enthusiastic devs
are often not motivated by money, but the joy of creating and they like to
feel valued and thanked. TFA suggests giving awards and thanks and bullshit
like that. No! The only appreciation a boss can give towards their employee is
money (bonuses and salary increases). Everything else is manipulation. I don't
care that you are super non-greedy good-person who doesn't care about money
etc. It doesn't matter. What matters is your boss _does_ care about it. You
see, talk is cheap. I can print you all the award you want and will laugh
behind your back what a loser you are. If you don't want the money then spend
it for charity or frame the Benjamins and hang them above your bed. Or give it
to your local homeless guy or your grandma. I don't care, but in business (not
in personal relations), respect is money and money is respect. The earlier you
learn it, the better. Nobody will take you seriously otherwise and you'll be
seen as childishly naive until you understand money beyond it being the thing
for the douche-y suit types.

------
amenod
> This flaw presents itself in a number of ways. The most frequent is in time
> estimates. Almost every engineer I know chronically underestimates how long
> it will take to complete a task or series of tasks. Only the very best are
> able to give and meet accurate time estimates while the rest are sometimes
> off by a factor of two or more.

What is interesting is that we seem to be _much_ more accurate when estimating
how much time a colleague will need to finish the task. So the solution is
simple: when deciding on an estimate for yourself, try picturing someone else
(less skilled preferably) doing the job. The result is surprisingly accurate,
at least in my experience. :)

~~~
Aeolun
Depending on who is doing it, I think I could estimate it will never be
finished.

~~~
amenod
Sometimes this is a very accurate estimate.

------
mattwad
It goes both ways. I've met engineers that want to be told what to do. I think
they just looked at their role as "a job" which is fine. There's also people
that are really interested in their work and should be included in the design
process.

~~~
cpitman
In consulting, I run into this type of engineer pretty often. And these
engineers often work at companies that are scared of being disrupted.

So my work in "Digital Transformation" is a two part challenge of teaching
management to think of their IT department as a source of creative energy and
not bricklayers, while trying to get the engineers out of the mindset of
bricklayers themselves after many years of being shoehorned. It is _not_ easy.

~~~
to11mtm
> So my work in "Digital Transformation" is a two part challenge of teaching
> management to think of their IT department as a source of creative energy
> and not bricklayers, while trying to get the engineers out of the mindset of
> bricklayers themselves after many years of being shoehorned.

You're doing the work of a higher order function there. You have my thanks.

I've worked in environments where this type of change has been attempted. It's
not easy and does run the risk of running VERY awry.

~~~
braindouche
how did that change go for you? because I'm living through that transition
right now at my company and it's not been smooth.

~~~
to11mtm
In one case I've observed, the effort was _honest_. There was a real attempt
to make IT have the same seat at the table as the rest of the business. That
doesn't mean it was easy, and I wouldn't call it SMOOTH, but the transition
itself wasn't that bad. Ironically I think if they had just 1 or 2 different
people in the right places during the transition they would have done well
enough for themselves I'd wish I was still working there.

In another observed case, well, the process did seem to shine a light on
people who's primary duties at work were to make sure they still had a job...
In that scenario it can get really ugly because the optics make it look like
"We empowered IT and things got worse!" Of course ignoring how the gatekeepers
would rather quietly ruin projects before giving another division a 'win'.
Leads to a huge fear culture because you start to ask who's going to be the
next sacrifice for the lack of real progress on anything.

------
awinter-py
> They also have a tendency to believe that their ideas are fully-formed when,
> in fact, there are holes so large that trains could fit through

Really important thing to be aware of, not specifically for PMs but for
everyone. Have interviewed 20+ managers this year on exactly this topic.

My favorite answer: product owners should collaboratively identify broad goals
for a feature or product, make sure everyone is on the same page (sometimes by
compromising on goals), and not solidify any plans until the goal phase is
done, lest SMEs mutiny.

------
tracer4201
> This is one of the top things that make engineers grumpy: constantly
> shifting priorities.

Author hits the nail on the head. I was on a team that shifted priorities just
about every week - and not really the team but really management. Every
decision was "reactive" to something someone said - that "someone" who doesn't
really know _that_ much, doesn't have that much power, etc., but management is
convinced they'll look good if they can satisfy this one person or group of
people, regardless of whether the outcome provides any true value.

The manager was a great guy, but he over-indexed in the wrong things and spent
too much effort optimizing purely for "optics".

I realized I didn't see value in my output (nor my team's). I wasn't enjoying
my work, and I really wasn't learning anything I really care for. The things I
_was_ learning had more to do with work politics and optics.

So I left.

And I took a vacation.

:D

Life is short. If you're going to work 60+ hours a week, at least find
something that helps you grow in some way and/or that you find fulfilling.
Unfortunately not everyone has that luxury, but if you do, only you can
improve your situation.

------
d23
“Product managers are interesting people. Their ideas and capacity for
understanding markets are impressive.”

Citation needed.

~~~
nickthemagicman
Agreed. This absolutely needs multiple citations.

------
NikolaeVarius
I dont understand why this article is specific to software engineers. This
could be applied to a majority of white collar professions

~~~
Discombulator
The easiest answer is that HN is frequented by many people whose main (and
often only) job activity is software development, so they/we think that our
plight is special.

I wonder if there is some hidden irony, because it appears to me that we
sometimes assume that everyone else has a simple and straightforward job that
we could probably automate.

~~~
balfirevic
> The easiest answer is that HN is frequented by many people whose main (and
> often only) job activity is software development, so they/we think that our
> plight is special.

That's unfair (and untrue generally). The article is about software developers
because it is written by someone who knows about software development. Does it
also apply to civil engineers? Maybe, but I wouldn't know.

------
progman32
This rings true, and will be useful to introspect and more clearly explain
concerns to colleagues. Apart from the short article[1] linked from the
submission, are there similar pieces written from the POV of a manager or
designer?

Aside: Pretty sure most managers at my job already understand most of what
this article is saying. I count my lucky stars, and I'll be sure to remind
them that this is a huge reason why a lot of us stick around. Just as the
article reminds us to recognize the engineers, we must also recognize when
i.e. managers do something positive for their team.

Also, on thanking engineers: If you see an engineer do something to help other
engineers, _recognize them_ or, better, _help them_. It really stings when,
say, you spend a frustrating afternoon debugging obtuse test scaffolding code
that's been affecting multiple teams, only to get nothing beyond a quick
"looks good" review.

[1] The link is broken but there appears to be a copy at
[https://library.gv.com/how-designers-and-engineers-can-
play-...](https://library.gv.com/how-designers-and-engineers-can-play-nice-
and-still-run-with-scissors-8df20e65c2c1)

------
ncmncm
To me the key line in the whole essay was:

 _It’s difficult to get into a good flow while coding if you know you have a
meeting coming up in an hour or two_

One meeting in the day is enough to ruin a whole day for coding. All you can
do for the rest of that day is putter. Projects do need a certain amount of
puttering, but when they need it is not the day of the meeting.

~~~
geewee
I find that putting the daily standup right after or before lunch, pretty
easily fixes this problem (assuming the team eats lunch together) - there's no
extra time wasted, as you would have been interrupted anyways.

~~~
sojournerc
It's not just the time interruption though, it's the mental interruption of
thinking about other parts of the project, business, etc, etc, that a stand up
creates.

If I'm in the zone and go to lunch, I'll keep churning on the problem in my
head, and might even have a solution when I'm back at keyboard.

If I have a meeting before or after lunch, that context is gone

~~~
ncmncm
Exactly: sometimes, when it gets particularly intense, I go take a nap (which
I can) and come back with new clarity and a better approach.

------
CM30
Amen to this article. The way software engineers (and coders in general) are
treated like assembly line workers is ridiculous.

That said, I think one additional issue the field has is that there's a
reluctance in companies to tell the customer/client that they're wrong/they
can't have what they want if it's unrealistic to deliver that. Issues like the
whole design changing because of constantly shifting requirements, massive
levels of feature creep/scope creep, etc could in many ways be fixed if
management said no. If they said that the customer/client couldn't get
everything redone from scratch without extending the deadline or paying more.
Etc.

~~~
odiroot
> Amen to this article. The way software engineers (and coders in general) are
> treated like assembly line workers is ridiculous.

And it's still not so bad in the anglophone world. In some European countries
engineers are considered a necessary evil that cuts into the bottom line.

In many Asian countries (AFAIK) engineers are only treated as a cost centre,
regularly overworked and underpaid. None of this SV or London splendour or
special benefits.

~~~
walshemj
Unusual to hear engineers in the UK has having a splendid life :-)

~~~
odiroot
From what my friends tell me it's still better than continental EU.

------
thayne
> We have a tragic flaw and that flaw is that we overestimate our knowledge
> and abilities... The most frequent is in time estimates.

I won't dispute that engineers overestimate knowledge and abilities sometimes,
or that estimates are wrong more often than not. However, most engineers I
know are well aware that _any_ estimate they give will be wrong, but do the
best with the knowledge they have because the PM needs some kind of estimate
in order to plan. Estimates aren't low because we don't take into account our
lack of knowledge, they are low (or sometimes actually high) because we don't
even know how much we don't know.

~~~
Vinnl
I don't really get that. Why would someone _need_ an estimate if the estimate
is wrong anyway - what use it is.

Then _if_ I'm forced to give an estimate, I usually add an order of magnitude
precisely because I know there's a lot I don't know yet, and the worst and
best cases of underpromising and over-delivering are better than vice versa.
Yet many people's intuitions (also engineers') appear to disagree with that.

~~~
Tempest1981
For years, I felt guilty (or was made to feel guilty) for giving an
accurate/realistic estimate. Mostly at startups, where you feel, everyday,
that the company is at risk of failing.

It's better to give a range of estimates - best case to worst case. Although
managers may only hear the best case.

~~~
Vinnl
Sure, but especially when I'm made to feel guilty, my answer is always: the
estimate I give does not influence how quickly the work is going to get done,
so feel free to tell yourself that it will take half the time if that makes
you feel better. I want to make it as explicit as possible that, if a manager
only hears the best case, that's of their own volition.

------
alexfromapex
This is so dead accurate. I would’ve lead with the second section or maybe
reduced the first section to just the last paragraph but I have had these
exact thoughts so many times.

------
viburnum
Grumpiness is good, actually. There are worse moods.

------
winrid
Taking advantage of developer's creative side is one thing I know my company
needs to do better. Luckily I'm in a position to fix this. Good reminder. :)

------
sysbin
Sometimes I wonder if I picked the wrong career from just viewing how analyzed
this field happens to be. Every year a blog post I see about how to make
things better or what's wrong and needing to change things up. I've never seen
these constant blog posts on management & burn out for other high paying
professions. I'm starting to wonder if programmers are just being
psychologically manipulated every year to decrease the value of the skill and
so companies can get more out of their money.

~~~
AnimalMuppet
HN is a software-heavy site, so you read a lot about software burnout here. If
it were a medical-heavy site, I suspect you'd read a lot about doctor burnout
(I still see that here sometimes, even though it's not really a medical site).

But doctors are the one counterexample that came to mind. Do architects burn
out? Do civil engineers? Electrical engineers?

~~~
intrepidhero
EE here. You could replace every instance of software engineer in the article
with electrical engineer and it would absolutely ring true.

I think the most important point was that engineering is an essentially
creative profession but many of us are not valued for our creativity.

------
feikname
> Every single software engineer fell in love with coding because _she_ made a
> small, useful program early on and was hooked.

Totally off-topic to this article: I've seen more and more the use of _she_ as
a demonsrative pronoum rather than a personal one (e.g. moon as her) and as
actually a gender-neutral personal pronoum for people and animals, specially
for generalized cases.

Is this "valid" formal english or is it a trend?

Also, if anyone knows the name of using "her" like this please tell me, I'd
like to know more about this.

~~~
trobertson
It's a response to the use of "he" as the default pronoun. "he" is gendered
and basically everywhere, which means that many people consider its use
sexist. Their response is to use "she" in an effort to swing the gendered-
pronoun usage towards 50/50\. Other people choose to use the gender-neutral
"they", which gives grammar-focused people an mild aneurysm.

~~~
_s
Is that because “they” refers generally to a plural? I’ve started using it to
refer to singular people as a neutral reference but haven’t had anyone attempt
to correct it.

~~~
linuxftw
It is acceptable to use 'they' as singular when referring to 'a person.'

Works: "When a person reads, they learn"

Doesn't work: "When Jim reads, they learn"

It also works for other non-proper nouns like

"When a knight enters the room, they kneel". I think this is mostly an
artifact of implying "When knights enter the room, they kneel."

I feel like this also works: "When the author wrote x, they were really saying
y".

I'm sure there's some explanation for it, but it's generally okay to use
'they' in the singular and anyone that disagrees is some snobbish weirdo. It
clearly conveys what one means which makes it suitable for use, IMO.

------
paranoiac
[deleted]

~~~
helij
Exactly the same here. I just quit my job because if this actually + commute.

It just so happens that this time I didn't allow myself to become burnout.
Which is progess I guess.

Hope you solve your issue quickly. I know we tell ourselves this and that
reason not to quit but sometimes there are two paths - either work against
yourself or quit. Not sure if I know the answer here, sadly.

~~~
paranoiac
[deleted]

~~~
WrtCdEvrydy
Just don't care. Next time someone asks for something that is a fire ask them
to tell the next person in line they're not that important.

