Live data from Hacker News

Identifying factors contributing to "bad days" for software developers

arxiv.org

11–20 of 63 posts

Re: Identifying factors contributing to "bad days" for software developers

#11

"""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 /…

> 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

Re: Identifying factors contributing to "bad days" for software developers

#12
post #11

"""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 /…

> 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

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...

Re: Identifying factors contributing to "bad days" for software developers

#13
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.

Re: Identifying factors contributing to "bad days" for software developers

#14

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…

> 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.

Re: Identifying factors contributing to "bad days" for software developers

#15
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.

Re: Identifying factors contributing to "bad days" for software developers

#17

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.

I once got criticised by the scrum coach(master?) that she had numerous complaints about me being not well suited to the team and was probably out of league and would fit a far more junior level. This of course gave me a very bad day and left a mark for almost 6 months.

Needless to say, I later found out from my manager that, the scrum coach thought I was spending too much time on particular tickets and causing bad jira metrics for the whole team, but he later explained to the scrum coach that the tasks were large architectural changes or research duties, hence could not be comparable to regular 10LOC bug fixes or bug triage tickets and some stuff can't always be broken down into smaller tasks either, as research topics need more investigation before figuring out what needs to be done.

From then on, I have learned to safely(with caution) ignore criticism from non-technical people and improved my day quality.

Re: Identifying factors contributing to "bad days" for software developers

#19
post #5

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

Using Jira slides into tracking all minutiae in Jira. People begin to think if it ain't tracked in Jira it didn't happen. You cant just do work now, you gotta write Jira first.

I call it Jira diarrhea

Re: Identifying factors contributing to "bad days" for software developers

#20
post #17

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.

I once got criticised by the scrum coach(master?) that she had numerous complaints about me being not well suited to the team and was probably out of league and would fit a far more junior level. This of course gave me a very bad day and left a mark for almost 6 months. Needless to say, I later found out from my manager that, the scrum coach thought I was spending too much time on particular tickets and causing bad j…

It's amazing to me that someone's whole job could be running the scrum board, and that such a person would be questioning other people's contribution to the team.
Post reply on HN