Identifying Factors Contributing to "Bad Days" for Software Developers
14 comments
·October 26, 2024unsnap_biceps
Inversely I can tell you what factors contribute to my good days.
Primary factor is when my manager and his manager are out of the office.
We do an hour long project update every morning and afternoon so that both managers can poke at our progress and make sure it's "meeting the bar". And my direct manager isn't trusted by his manager, so my skip is in there and they squabble around task prioritization and tasks get re-assigned randomly half done between developers when they don't feel enough was done on the task in the last 3 hours.
There's plenty of good stuff at this job, but that part drives me insane.
musicale
> We do an hour long project update every morning and afternoon so that both managers can poke at our progress and make sure it's "meeting the bar".
I always assume that one meeting eliminates 4 hours of productivity, so it looks like you are all set.
neilv
Sounds crazy. With little info, I would guess one of:
* Management has lost faith in the manager and/or their team. (e.g., handholding to try to fix the manager/team, or to mitigate temporarily whatever turns out can't be fixed)
* The company, product, or some management role is in crisis, enough for management to be firefighting in desperation mode. (e.g., task re-triage up to once or twice a day can be a legitimate tactic, and I've seen a company saved that way; but two hour-long meetings of the entire team a day consumes huge time&energy, so that would need additional justification)
* Management is operating out of their experience, or overextended, and not adjusting fast enough.
If you trust your manager or the skip, you could go talk to them. But, if they are crazy or cruddy, you should be prepared to be leave, and not necessarily on your schedule.
sameoldtune
In the remote era this is the only way that 2nd level managers can exert authority. In the office they have a nicer desk and eat lunch with a different crowd so you know they hold power.
If it makes you feel any better the director is doing exactly the same thing to them.
AtlasBarfed
Meeting the bar? That's amazon bullshit isn't it? Actually they constantly raise the bar for a recursive bullshit.
Companies stack ranking an inherently team activity will never learn. You can't be a team and have the core incentive to fuck someone over for when the musical chairs end.
zeroonetwothree
For me bad days are entirely about the people side vs the infra side. If some infra is down that hurt productivity but I don’t feel that negative about it. I’ll just do something else.
Meanwhile if I have too many meetings or have to deal with dumb people or get criticised by someone that doesn’t understand what I’m doing that’s actually a bad day and has big negative effects beyond just that one interaction.
kevindamm
"""Three major themes that cause “bad days” for developers: tooling and infrastructure issues, process inefficiencies, and issues around team dynamics. Within those issues, deeper concerns were identified and are shared in the following sections."""
The causes will sound familiar to most developers here. The most significant causes are usually outside the person's control, as expected. Interestingly, "interruptions / randomness" was only the sixth most significant, while the most significant cause was "engineering system friction."
The average number of "bad days" per month is 3-5. Accounting for weekends and vacation days, that's nearly 20% of the time! And some report 9+ bad days per month.
So, if you happen to work on corp-infra or other tooling/support role, and you occasionally lament that your work is not in the critical path, you actually have a rather large impact if you think of it in terms of helping reduce the number of bad developer days.
pards
> if you happen to work on corp-infra or other tooling/support role [...] you actually have a rather large impact [...] in terms of helping reduce the number of bad developer days.
This, 1,000x.
- CI/CD pipeline needs attention: Bad day
- Dev env down: Bad day
- Infrastructure via ServiceNow: Bad day
- Change review board: Kill me now
thih9
For people unfamiliar with “change review board”:
> It’s a group of people from the project team that meets regularly to consider changes to the project. Through this process of detailed examination (…) decides on the viability of the change request or makes recommendations accordingly.
https://www.projectmanager.com/blog/change-control-board-rol...
jmclnx
These are the factors to me:
* formal meetings, where I was, 30 hours of meetings a week.
* Users wanting us to read their minds
* bureaucracy, need to ask permissions to do one little thing
* Jira
austinchainy
The number one thing contributing to Bad Days is bloodsucking managers that don't understand anything about technology and would rather watch your entire life and its meaning turned to ash than fix the obvious things. I learned this after programming in JavaScript for several years. I'll never do it again. Ever since I stopped writing code and started work at a nail salon, my life is so much more relaxed.
DidYaWipe
I don't work in an office or on a team. Top bad-day causes I find in self-employed dev situations:
1. Bad or no documentation on tools or technology being used
2. Defects in tools being used
These are so bad now that I just don't even want to be in the field anymore much of the time. For either of them, you're often reduced to spraying all the usual forums with a question (and it takes ages to prepare a reproducible case that you can actually share, if that's even possible) and then waiting and hoping. Oh, and in the meantime doing the same searches over and over to see if some previously hidden nugget will turn up and reveal a solution.
readthenotes1
22 developers given reasons a through h to identify a reason for a bad day.
The whole thing is suspicious since it admits up front that they go off the perception of a good day being good for productivity. Based on my experience, a lot of software developers should have a lot more bad days where they are told that they work there doing this substandard ...
I worked for a company and implemented testing suites into our infrastructure. My team and I spent time meeting with all the various stakeholders, FE, BE, Auth, Infra, etc. Put the solution in place and built out the dev tools needed, held constant training with teams, answered questions when called out in org meetings. Since we were building two docker images (1 the actual image and 1 for proxying network connections for tests) During development I asked 100 times that this would not increase cost. Everyone assured me we did not have to worry because that is all negotiated yearly.
At the end of the day we had this weird error where the test suites would randomly fail. Always a different test, different time of day, different engineer running into the issue. This caused “bad days” for all the feature developers.
I kept investigating and pushing back that it wasn’t my implementation. Lo and behold months later it was revealed that any subsequent PR would cancel the docker image built for the active PR. The tests would fail because the image was getting trashed. The reason this kept happening is that the QA env was not actually setup to mirror the production env, as a cost saving measure done much much much before my time.
However since engineering and infrastructure refused to address the issue months ago, the dev org had built up ill will against me. Everyone blamed me and instead of sitting down and still fixing the issue to have a parallel environment to our production env, they laid me off, and removed all my work.
I still have friends that work there and they still fight daily about testing deployments and rolling back because they removed the testing in place.