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.
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.
True, but there's no award for how obvious the average bug is. I've also found we often reach huge problems after being distracted by a bunch of minor sloppiness. Submit a PR that has a serious flaw in it, but is otherwise top-quality, and people may find that flaw. Submit the same PR, but name every variable "data" or "value", change every constant to an uncommented magic number, and cram in some jQuery functions even though it's deprecated in your project, and reviewers will happily point out all those things while completely missing the serious flaw.
Of course! But I'm addressing how senior developers spend their _time_. They don't often spend lots of time helping with bugs written by other senior developers.
You can solve that problem honestly or not so honestly. I've worked in places where everyone knew to pad their time without telling the non-dev in the room. I've been happier with also estimating the ratio of time you spend doing tasks. Someone more senior should intend to spend less than 100% of their time on those tasks.
Both of those work better than ignoring overhead or refusal to estimate, imho.
I don't think there's anything dishonest about estimating a task discounted for all the random org noise.
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.
I thought the article broke down those things rather well. It talks about how detrimental context shifting is, shifting priorities. In the part about how poor time estimates are, "No time is put in for meetings to go over requirements and make changes," not time is accounted for bugs, or the learning part about solving a problem.
Measuring and optimizing bottlenecks is a core agile idea.
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.
It just depends on where and how you want to spend your time. I've "micro-managed" myself to prove the point. I gave them that estimate up front--told them this was assuming I had dedicated time to work. After a week or two I went back at them with how much time I had spent, how far along, and if I was above/below my estimate. Only then did they push to clear my schedule so I could get the hours in.
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.
Yes. And the problem of giving more realistic planning is that management will say: "but [insert name of random coworker] can do it in half of that time!" Of course that coworker is dealing with the same problems as you do.
It may not be so much assumption that about being left alone but instead requirement to quote the time that will be used for billing. You can't pad that, it will be 20 days of work that client should pay for but that 20 days may be spread over next 3 months. Problem is that neither management or client hears that part even when they are repeatedly told multiple times.
I'm always explicit when asked for an estimate. It's not the most political or business savvy answer, but I say things like "this will take 2 hours. On average I'll have two hours of focused time per day, so 10 days."
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.
> 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.
Holup. I run my own company and there's loads of shit I have to do and I hate it. There is not a perfect job out there. Really I don't know if it's anymore/less enjoyable than other things - just different.
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%
Yeah. Your not wrong. But you do have a choice. I'm not going to put up with it. Software dev has driven me to the edge of suicide because it has reduced me to a coder. And I'm a terrible coder, I'm a very good big thinker, but thinking in the small scale, logic problems of coding? Terrible and yet this is my job as a coder. I can't take it anymore and I am out. I've quit my job and am trying my hardest to get a business analyst role. No luck within the first 2 weeks of looking. I'm not sure I'm going to get anything. But I'm never going back, doing so would probably kill me sooner or later. 14 years into a career :( but I'd rather work construction than this shit.
I am sorry to hear that you bear resentment agains coding, and I wish you all the luck in business analyst (or any other actually) role! The thing is... people do lots of stuff to get by. I'm sure you will find something that you will enjoy in.
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.
Ah, well said, that will teach me to give unsolicited advice to strangers! :)
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!
>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.
>>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.
Is the administration most like to implement UBI also the administration most likely to reduce regulations that dictate how you must conduct your business?
Scrum is a way for managers to think they are doing a good job managing, but in fact are micromanaging. For every project, my manager wants a daily scrum. No really efficient
I never dictate process to my teams, but then when i see them floundering around. "Maybe you should have a daily?" Then 2 weeks later "We had this great idea! We are going to meet daily!". If a manager is involved in Scrum its not really scrum...
Same. I've never seen a daily that didn't devolve into busyness reports. Sure, with proper scrum master I'm sure it works well but that's not my average experience.
i really hate scrum. Makes me feel like a shoe production line worker. With many fallacies... like any team member can/should be able to work on any ticket. And dont get me started on all the meetings !
- 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.
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.
So the rule is actually "yes, and..". The "and" is actually the crucial bit because if you just say "yes" without adding information the scene stalls (you always want to be filling in more and more details). "No, but.." tends to be frowned on because it reboots the scene and invalidates your partners scene painting... but in a corporate context I think "no, but instead.." might be the better answer (if you have an "instead", of course). Then youre still addressing the concern by adding new info, but youre not committing prematurely
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.
My first real programming job I had was working for a guy who hired lots of contractors. And he was frequently angry with the programmer that loved to say "no I can't do that" only to have the same programmer come back a week later with a possible solution.
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.
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.
I can relate to this a lot. Probably the reason of saying NO most often is the fear of bad things that could happen. On the other hand, if people spent less time discussing things and rather iterated on working (!) software, it would be less of a problem.
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.
I today agree, that devs being part of the creative process and not being drones leads to more happiness and has a lot of upside: they bring new ideas to the table, are more invested in the solution and feel owner ship -> quality of outcome is better.
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.
About (a) and (b), in my first 2 jobs this was a non-issue since my boss always had the last word. I guess today's Agile/Scrum situation is a big improvement over that, where people work data driven and not by personal taste of one person.
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
One thing I try to do is to never say something is impossible or to refuse to do as instructed outright. Of course everything is possible, it's just a matter of how much effort is reasonable to put in.
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.
I also try to do this at work, with the exception of ethical/moral and interpersonal stuff. Don't "yes and" into harassing someone, or into your drunk boss's passenger seat.
yeah, the converse of what the article talks about is that software engineers tend to be pretty arrogant and dismiss suggestions and requests from users and designers, and just treating them like people and seriously trying to find common ground gets you very far.
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.
If anything the article really undersells it by calling the meetings "useless". I'm a programmer, but most of my experience over the past 12 years has been client-facing, and these things often go beyond simply wasting time to actively harming your project. Much like the idle engineers who they invent work for in the article, idle meeting minutes get filled with planning that completely ignores actual business needs.
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.
> 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
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.
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.
> 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. :)
Most engineers who have been doing it for more than 5 years generally can give estimates that are bang on.
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.
Ugh, this drives me absolutely mad. My work has some very defined timelines because I have 3rd parties making stuff for me. Yet the conversation about schedule is exactly the same every project like they don't believe me that an injection molding tool takes 6 weeks and that I need the schedule for two rounds of modifications because something unforeseen will come up.
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.
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.
I'd argue that it's acting like an engineer not a craftsman.
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.
I agree, I think it’s an alternative to answering your SVP with:
“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.”
The problem is that statement is completely ignorant of the audience. An engineer might understand "jquery" as an explanation for slow delivery speed, but it is not the right explanation for the standard exec (notice that you inferred a lot of information from that statement that someone unfamiliar with front-end technology would not).
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.
I deliberately became the just a job guy. Why should I bother my arse coming up with “insights into the product” - a product which I don’t own, in a company which I don’t own? They’re still only gonna pay me as a developer. I might as well run my own business if I have to deal with all that. Now I’ll be a short-order cook for 8 hours and forget about work once I’ve left it... at least it’s relaxing.
Yes, I had massive problems with it and it was making me really stressed. I changed jobs to somewhere with more capable leadership, so I could trust the work I was given to not be outright stupid.
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.
> 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.
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.
> 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.
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.
> 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?
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.
I'm sorry, but if one meeting ruins the productivity of your entire day, I think something is very wrong. If you truly find that you can't be productive given a 3 hour window, you might need to reevaluate your approach to work and come up with a better system.
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.
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
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.
> 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.
> 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.
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.
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.
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.
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.
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. :)
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.
That is due I in part, perhaps largely, on the nature of software developers. We are problem solvers, analyzers, focused on finding more efficient/elegant/faster/etc solutions. We pick things apart, to understand them, so we can build systems that do those things and or do them better.
Its inevitable that we apply these qualities to ourselves and our industry.
I see similar in other technical creative industries. Some engineering and sciences.
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?
My understanding, although maybe this is just rumor, was that architecture had one of the highest suicide rates of any profession. My theory was that it was because it is a demanding job (comparable to engineering or medicine) but most buildings aren't really architectured. I mean how many sky-scrapers, museums, and city halls are there in the world compared to the number of mcmansions and nondescript office buildings.
> 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'm paid a lot and I work remotely from a beach. If I don't like my job, I can easily find another that I do like.
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.
I wish those people who find they can easily find another job without any effort or worry would realise they are not normal.
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.
> I'm paid a lot and I work remotely from a beach. If I don't like my job, I can easily find another that I do like.
> 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?
Good software engineers in the United States absolutely can say that. Remote work typically pays less than work in high CoL areas but it still pays well. Additionally there are a lot of jobs out there. Personally I know that if I quit tomorrow I could easily have a job in less than a month.
This isn’t going to be true in every area but it is absolutely true in the Bay Area currently.
> 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.
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.
> 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.
A while back I quizzed a doctor friend about working conditions in a hospital and found the relationship between doctors and hospital managers to be highly analogous to software. Interestingly the most successful hospital managers tended to be ex-doctors but it was hard to convince doctors to move into management.
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.
You misunderstand: The only hospital managers are former doctors. As in, they pretty prevent any non-doctor from managing them and that's what we need to do, too.
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.
I’d imagine the writer doesn’t have experience working any other white collar job, they are writing from their own experience. Maybe a bunch of my own gripes with the software industry might apply to paralegals or accountants but I’d never know.
Software engineer is the most common job requiring significant amounts of technical creativity. That makes it different from most white collar professions, and means you can't manage them in the same way you manage for example a group of accountants. Note I am not saying that accounting doesn't requires significant skill, just that for example it is a lot easier to get an accountant what he needs to do his job than to get a software engineer what he needs to do his job.
> 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.
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.
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.
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.
Without wading too deeply into the topic, I can say that I have only really seen it as a trend among developer documentation and writing, as a means of fostering I gender inclusiveness.
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.
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.
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.