[HN Gopher] Identifying factors contributing to "bad days" for s...
___________________________________________________________________
Identifying factors contributing to "bad days" for software
developers
Author : andrewdutton
Score : 50 points
Date : 2024-10-26 16:01 UTC (7 hours ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| unsnap_biceps wrote:
| 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.
| sameoldtune wrote:
| 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 wrote:
| 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.
| neilv wrote:
| 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.
| musicale wrote:
| > 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.
| readthenotes1 wrote:
| 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 ...
| jmclnx wrote:
| 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
| 2OEH8eoCRo0 wrote:
| 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
| kevindamm wrote:
| """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 wrote:
| > 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 wrote:
| 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...
| austinchainy wrote:
| 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 wrote:
| 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.
| zeroonetwothree wrote:
| 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.
| n_ary wrote:
| 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.
| tdeck wrote:
| 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.
| mistrial9 wrote:
| 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...
| YZF wrote:
| 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.
| righthand wrote:
| 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.
| jiggawatts wrote:
| 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."
| righthand wrote:
| 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.
| ldjkfkdsjnv wrote:
| Big one is whether someone higher up decides to take a look at
| code being pushed, and nit picks every little thing to prove they
| are maintaining quality software
| siva7 wrote:
| Meetings in the morning. Let me get my sleep first!
| Smaug123 wrote:
| 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).
___________________________________________________________________
(page generated 2024-10-26 23:02 UTC)