Identifying factors contributing to "bad days" for software developers
1–10 of 63 posts
Re: Identifying factors contributing to "bad days" for software developers
#2Inversely 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.
Re: Identifying factors contributing to "bad days" for software developers
#322 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 ...
Re: Identifying factors contributing to "bad days" for software developers
#4Inversely 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…
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.
Re: Identifying factors contributing to "bad days" for software developers
#5These 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
Re: Identifying factors contributing to "bad days" for software developers
#6"""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.
Re: Identifying factors contributing to "bad days" for software developers
#7The 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.
Re: Identifying factors contributing to "bad days" for software developers
#8Inversely 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…
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.
Re: Identifying factors contributing to "bad days" for software developers
#9Inversely 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…
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.
Re: Identifying factors contributing to "bad days" for software developers
#10I 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.