The care and feeding of software engineers, or why engineers are grumpy (2012)
humanwhocodes.com
humanwhocodes.com
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.
The problem is that is a huge time-suck and they don't really care about the minutiae either. For me the whole goal is to keep the responsibilities clear and unnecessary communication to a minimum and I feel like that's done by building trust and being clear.
Bugs are written by all seniority levels of engineers. “To err is human,” after all. Junior developers hold no monopoly on mistakes.
Sure but the Senior devs are too arrogant to ask for help ;)
IME Seniors aren't afraid to ask for help when it makes sense to.
Both of those work better than ignoring overhead or refusal to estimate, imho.
It is annoying when your boss balks at your estimates using productivity when everything goes smoothly and there are no interruptions as the benchmark, though.
My team's process is to estimate and track dev non-dev time with our other sprint metrics at dev-day granularity. ie last sprint I estimated 2 non-dev days for product / design discussions, factoring in the meetings/doc writing/cost of mental randomization/etc. Planning and retrospective provide opportunities to reflect on reducing communication overhead within the team, and the metric is valuable for pushing back on top-down management-mandated overhead.
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.
Agile development doesn't work without context anyway.
- Stories in the backlog are unassigned and should be executable by anyone.
- If you finish your assigned stories early, you’re expected to pick off the top of the team’s stack rank, not your own agenda.
There are project management approaches that involve making individuals responsible for large, coherent wholes. I’m fortunate to be on this kind of team now. But despite daily standup and biweekly sprint planning, it is not Scrum. Scrum explicitly trades off context and domain expertise for fungibility and cross-pollination.
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.
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.
> 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.
As a cog in a big machine some idiots tell me what to do.
As the owner of a small business 100s of folks tell me what to do. And I get the added joy of paperwork, legal crap, buying healthcare for my employees, all stuff that takes away from the fun of creating cool stuff.
Maybe it's a bad idea to have work be fun? Work is work 100% - then my fun can be fun 100%
For me it didn't go that far, and I managed to bounce back to the point where I actively seek jobs that will keep me in development (coding!) instead of steering me towards just management. What helped me was to get some vacation time, then switch the jobs. But most importantly, I started carefully looking for signs of burnout ("Do I enjoy waking up in the morning? Do I look forward to going to work? Am I getting there later and later?"). When you notice the problem in time, it is much easier finding the cause and dealing with it, even if it means changing the job.
Also, having a side project where I can get really creative helps. :)
Although I would like to say that everyone I have spoken to about this, throughout my career, has assumed that I'm just going through a period of burn out. I've been unhappy with my career for 10 years and the resentment and discontent has only grown.
In fact it was people telling me that I just needed to regroup and watch for burnout that kept me in the job. I listened to people when they assumed the problem was manageable and would go away.
But you see, when there is a fundamental disconnect between you and your career, you cant just wish it away. It grows and grows and eats away at you.
For me coding is an irritating, depressing, meaningless activity. The only thing that makes it worthwhile is the thing that is being created. But when you are employed as a coder making something worthwhile is not an everyday occurrence. And tbh even if I was building the most meaningful product I could imagine, it's not enough to keep me engaged. Writing code it just too unpleasant.
I would have been much better to quit when I first realised that this wasn't for me, rather than wasting a decade of my life trying to convince myself that I could make it work.
You give very good reasons for quitting and if there is such a basic disconnect between you and the activity of coding, it absolutely makes sense to pursue other career options.
I wish you best of luck on your future endeavours, wherever the future might take you!
Worth noting that as I stopped saying no I also stopped feeling treated like an assembly line worker.
In any case, I think engineers should in general do more creators work and product people should focus on keeping the business alive. Indeed there must be people that know the market, the business implications and the competition.
However, in my experience working on a big product with multiple teams, the main problems with devs getting creative is
(a) the consistency of the user experience suffers badly
(b) the overall architecture erodes as everybody builds particular solutions fitting their specific problem
I am not sure what the best way is to reconcile Dev happiness and (a,b) in this context.
Anyway, one could solve it by maintaining a ratio of people with a lot of experience.
(a) A Designer needs to be on the team that can do a Corporate Identitiy (CI) => this way it's possible that Engineers create their own Bootstrap
(b) Either solve it top-down by having an engineer with enough architecture experience; or have architecture guidelines in place / develop them consensus-based
At most places there are very concrete guidelines about codestyle, usually ensured by linters. One can also put more emphasis on architecture style
https://letterstoanewdeveloper.com/2019/09/02/the-art-to-and...
Since this experience I almost always answer "yes" to all client requests but with a list of compromises required to get something built. It keeps everyone involved happy, even me.
Its in the same spirit because you're not invalidating the problem or concern that created the request, but youre adding new information and context that way. I like your attitude but I think saying Yes to everything can be harmful if you have info they dont have that might factor into decisions. I think no, but with an alternative, can be really productive.
If my boss comes up to me with "can we do unreasonable thing X" it's not my job to change his mind. It's my job to provide him all the relevant data and then let him decide on the course. If the request would take a large amount of effort I let him know. If the request would cause bugs or problems elsewhere I let him know. If the request would (in my opinion) upset users I let him know. What I don't do is tell him no.
If when given all the pertinent information my boss still decides it's a good idea to spend a month straight implementing a bug then I'm happy to oblige but only after all the information is on the table.
He's captain Picard and I'm chief engineer La Forge. The captain decides, and the crew executes.
Of course there's a couple catches to this approach where it doesn't work. If my boss would ask me to do something unethical I'd first try to tell him why it's a bad idea, before firmly refusing. I do this knowing full well that this might injure our working relationship.
The other assumption this method makes is that your boss is actually good at his job. A boss that makes unilateral decisions without consulting the experts that work under him is bad at his job. A boss that takes it personally when you tell him his ideas aren't good is bad at his job. A boss that isn't open to discussing approaches is bad at his job. A boss that tries to dictate how exactly you do your job is bad at his job.
Now of course all the above doesn't mean I'm acting weak-willed or indecisive. If I disagree with a course of action I let it be known. I'm not hiding my opinion. But I do respect that my job is to implement business demands and my boss' job is to gather, distill, and communicate business demands.
Anyways that's my approach and it has served me well so far.
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.
...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
You make a meeting 20 minutes, everyone shares their progress and can plan their week. You make that meeting an hour, and 20 more minutes are spent investigating someone's "concern" over an imaginary problem, and the next 20 finding solutions to this imaginary problem. Because that's the end of the meeting, mentally this becomes everyone's priority afterwards, and the day that would've been spent continuing on a healthy project is now wasted solving something that doesn't need a solution.
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.
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. :)
The problem is that management NEVER accepts that estimate. Ever.
They want to "negotiate". The problem is that they don't want to adjust features or scope--they don't really want to negotiate. What they want is a better number without changing anything--they're playing "schedule chicken" instead or negotiating.
Sadly, most engineers will feed into "schedule chicken" because they can almost always identify a group that will take longer than they will and so will get the blame for the schedule. And allowing another group to take the blame for the schedule is easier than arguing with your direct manager. The only engineers who won't play "schedule chicken" are the ones in the group that is going to take the longest. Those engineers know that they're going to get the blame and they're going to fight like crazy up front.
(Side note: Nothing is more satisfying than being in the group that is supposed to take the blame and instead delivers on time. It causes complete political pandemonium. You still want to have your resume already being circulated outside the company, but it is incredibly satisfying to watch all the people who have been hassling you for months all turn on each other to shift blame.)
I have only had one manager who listened because his job was on the line, too. When he said: "Look, the deadline isn't negotiable. We have something completed by date X or we're ALL basically fired." he actually listened when I said "This is the list of features and how I prioritize them. Here is the line for what we can get done by date X. You can have a feature below that line by swapping it for one above that line--but you have to make that swap TODAY. If you want that swap in 3 months, it costs you two features above that line."
We delivered a week ahead of time. Funny how schedules work out just fine when management is actually on the hook, too.
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.
If you have some content or thinking you'd like to share, it would be appreciated!
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.
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.
I work in a product role at a mid-size enterprise. I'm happy to involve anyone and everybody in high-level product discussions. But in order to do that you actually need some kind of insight into the business you're actually working for.
How will the customers buy the product? Is this kind of signup suitable for our demographic? How will component Y delivered by ASP vendor X in the value chain be impacted if we do Z? How much money will we (roughly) make for each customer? What will be the total profit potential given N percent of our target customers sign up? Is this initiative significant or insignificant for our business? Is it regulatory compliance or a major new business?
The developer response is (unfortunately) very often a major discussion along the lines of "this should be a lambda function", "no, this should run in our k8 cluster" or "we should migrate the app we just built last year to some fancy new technology I just read about on Hacker News, then we can build this in no time".
Sorry, but that's acting like a craftsman. Acting like a craftsman gets you treated like a craftsman. Management (or I) don't care about serverless or Azure or AWS. And when you don't understand basic business priorities I won't trust the "agile developer" using a three hours fixing a pixel alignment issue on a non-standard Android Phone on the least visited "compliance only" webpage.
I vividly remind a session where one of our SVPs talked about the main business problems and plans for almost one hour in an all-department meeting. One front-end developer raised his hand and excused the slow rate of change of change at a certain (and important) application with "it was built with jquery and no one has touched it since 2014".
The exceptions are (we are not Google) rare and very valuable - which is why they often are promoted. In my experience business intelligence, backend developers and database people are most "business aligned" or "business focused". Front-end developers at the other end.
Either way, I'd be thrilled to be treated like an engineer/craftsman. That would be a big step up from "interchangeable cog".
Also, I'm not clear on what's wrong with "it was built with jquery and no one has touched it since 2014". The fact that the system is built using an archaic technology, that technology is inferior to current technology, and the engineers are not familiar with the code base is completely relevant to how long it will take to make changes.
“You remember how our entire team left last year because they were fed up? Those were all the people with knowledge of the system.
You also remember how you gave us a budget of 50k to hire replacements? Well, we used it on one developer, and he’s left university this year, so doesn’t even know what jQuery is, much less how to work on that system.
That’s why changes are slow.”
Much preferable to not shame him like that and just summarize it as “It was built 4 years ago with jQuery.”
What the exec needs to hear is "this is built on out-of-date technology that is slowing us down and to fix that we need to be given time to migrate the application to a modern technology".
Problem + proposed solution + no irrelevant details like the name of the technology.
However, my experience has been that management generally just doesn't care no matter which version of the explanation they are given.
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.
Citation needed.
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-...
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?
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.
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
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.
It's a trick to keep salaries from raising.
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.
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.
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.
It's better to give a range of estimates - best case to worst case. Although managers may only hear the best case.
Not too many other professions can say that. None of the doctors in my family can. Though at least they are saving lives, something else most professions can't say they do. :)
We are lucky this field is so lucrative, especially in the US. Let's enjoy it while it lasts.
> Not too many other professions can say that.
Software engineers can't say that, if that's what you are implying. I don't know who can actually, which profession is so lucrative and with so little supply of professionals, that finding a well payed remote job that you like is even a possibility?
This isn’t going to be true in every area but it is absolutely true in the Bay Area currently.
Living on $50/h remotely in Vietnam is much more luxurious than $120/h butt-in-seat in San Francisco although it’s a lot less money in absolute terms.
For the majority of people finding a half-decent job takes a stupid amount of time (the number of jobs advertised which simply list a set of "technology words" and end in a black hole is not insignificant), and even if you do find a reasonable position being advertised then it's perfectly normal to never get any sort of response back.
Its inevitable that we apply these qualities to ourselves and our industry.
I see similar in other technical creative industries. Some engineering and sciences.
But doctors are the one counterexample that came to mind. Do architects burn out? Do civil engineers? Electrical engineers?
In all of those fields projects eventually get finished and involve a lot of bureaucracy and waiting. There is much more breathing room, than in software and more time to recover.
I think the most important point was that engineering is an essentially creative profession but many of us are not valued for our creativity.
You don't get to iterate much on a building design once construction has begun.
If you haven't, you haven't looked. There are plenty of postings and articles on burnout in the legal, medical/dental, and other professions.
Allow me to demonstrate. Here are some threads currently on the first page of the medical residency subreddit:
https://www.reddit.com/r/Residency/
> [stickied] The Official Burnout or 'Call for Help' Support Thread
> How do you deal with demanding family members?
> [Rant] Tired of the bullshit
> When you’re an intern and the attending doesn’t even bother to learn your name.
> Residents of Reddit: did you regret your specialty choice, and if so, what specialty and why?
> Chiefs, why so much intern hate?
> Propaganda in our hospital. “Let everyone know you’re unavailable because you’re passionate”
> Here’s reason why I don’t like going to work
> Depression in Medical Internship
> HCA, the for-profit residency experience.
> How to quit the rat race
> Depressed from recruiting
> Finance sucks compared to tech if youre (sic) smart
And so forth
Medicine does not have multiple schools of project management controlling them. Agile, waterfall, V-Shaped, Iterative, Spiral, and the list goes on.
Medicine is not a shit show by default because peoples lives are on the line.
Software is extremely disposable so it's super easy to turn into a shit show and treat devs like commodities.
I'd like to see the threads where senior oncologists are complaining.
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.
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.
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.
The heart of the issue is probably something surrounding trying to "manage" things according to some management principles when you don't understand the domain/skills of the people you are trying to manage.
The more different it is to your career experience, the harder it probably is.
We could use a cartel at this point, the job has gotten pretty lame and demeaning and as the only person who knows how to actually row the damn boat, I'm getting pretty sick and tired of it.
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.
I have yet to really see this in other writing amongst stereotypically gendered professional writing. As for non-people, it is a bit more common; the most obvious one in English I can think of is both boats and open waters.
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.
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.