Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Identifying factors contributing to "bad days" for software developers

arxiv.org

Post reply on HN
Print view View original

21–30 of 63 posts

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

#21

Post by jiggawatts »

righthand wrote: post #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 connection…

Ah yes, the “you touched it last” or the venerable “you brought us the bad news” schools of management.

I also love the “we’ll do the meta-work that improves work velocity after the work is finished. Not before! We’re too busy for that now.”

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

#22

Post by mistrial9 »

n_ary wrote: post #17
zeroonetwothree wrote: post #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.

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…

this is an interesting story.. please keep in mind that alternate possibilities can be considered about motivation, communication and results. The specific combination of "you go junior level" and "spend large amounts of time on architectural aspects" are ringing a bell. As in, a cereberal young engineer thinks deep thoughts, impactful or fatuous, and goal-oriented managers steer in a pushy way possibly including remarks of a personal nature. An observation is that much to the friction-coefficient of it all, there is no correct answer about refining architectural aspects versus "get that task done by Tuesday" . more could be said but, what really went on is now water under a bridge, so to speak...

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

#23

Post by righthand »

jiggawatts wrote: post #21
righthand wrote: post #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 connection…

Ah yes, the “you touched it last” or the venerable “you brought us the bad news” schools of management. I also love the “we’ll do the meta-work that improves work velocity after the work is finished. Not before! We’re too busy for that now.”

Yep, we’ll optimize it later infra told me. I hear it still at my current employer. Optimize it later means you’re touching on a long ignored piece of negative tech debt.

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

#24

Post by YZF »

zeroonetwothree wrote: post #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.

I agree. Bad people interactions are the worst. I can be productive with a piece of paper and a pen if I have to, thinking through some problems. People issues range from small-ish (getting interrupted) to major de-motivation dealing with inter-personal issues.

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

#25

Post by Smaug123 »

Somewhat surprised by how candid the responses are - to have multiple of your survey subjects say they are seriously considering quitting! I enjoy that there's an entire blocker for "Teams isn't working".

Personally my worst days are "I did a thing, rolled it out, found it was seriously broken, rolled it back, and now it's 6pm and that is what I did today". I couldn't see anything in their report that would cover that failure mode (it's worse than "couldn't get anything done", because I was demonstrably incompetent at what I did do).

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

#26

Post by fragmede »

Smaug123 wrote: post #25

Somewhat surprised by how candid the responses are - to have multiple of your survey subjects say they are seriously considering quitting! I enjoy that there's an entire blocker for "Teams isn't working". Personally my worst days are "I did a thing, rolled it out, found it was seriously broken, rolled it back, and now it's 6pm and that is what I did today". I couldn't see anything in their report that would cover tha…

> “I have not failed 10,000 times. I have not failed once. I have succeeded in proving that those 10,000 ways will not work. When I have eliminated the ways that will not work, I will find the way that will work.”

-Thomas Edison, on failure and inventing the light bulb.

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

#27

Post by iamthepieman »

tdeck wrote: post #20
n_ary wrote: post #17

Earlier quoted context omitted.

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.

I've had a really good scrum master. (Plenty of bad ones too). The really good one I could say something like

"I started work on this item and realized that I'm actually missing a lot of context and information in the requirements. I need your help clarifying them"

The scrum Master knew who to contact to get that information would set up a meeting, have the meeting without me if they thought they could do it or schedule it and include me so I could ask the questions I needed, Mark the ticket for me as blocked, fill out the info after the meeting and communicate the risk and reason for delay to stakeholders.

Basically I could say "There's a problem!" and the scrum Master would get it taken care of or find someone who could. Probably the most valuable person on that team.

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

#28

Post by llamaimperative »

sameoldtune wrote: post #4
unsnap_biceps wrote: post #2

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…

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.

"In the remote era"? You're both talking about people being in-office, i.e. not remote.

This is a typical mode of failure in management and it far predates remote work.

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

#30

Post by noman-land »

unsnap_biceps wrote: post #2

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…

This level of micro management sounds hellish. It suggests levels of anxiety so great they warp the fabric of spacetime.
Post reply on HN