TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Identifying factors contributing to "bad days" for software developers

85 pointsby andrewdutton7 months ago

15 comments

righthand7 months ago
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.<p>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.<p>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.<p>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.<p>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.
评论 #41960076 未加载
评论 #41958081 未加载
unsnap_biceps7 months ago
Inversely I can tell you what factors contribute to my good days.<p>Primary factor is when my manager and his manager are out of the office.<p>We do an hour long project update every morning and afternoon so that both managers can poke at our progress and make sure it&#x27;s &quot;meeting the bar&quot;. And my direct manager isn&#x27;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&#x27;t feel enough was done on the task in the last 3 hours.<p>There&#x27;s plenty of good stuff at this job, but that part drives me insane.
评论 #41957270 未加载
评论 #41957420 未加载
评论 #41957655 未加载
评论 #41958663 未加载
评论 #41957382 未加载
kevindamm7 months ago
&quot;&quot;&quot;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.&quot;&quot;&quot;<p>The causes will sound familiar to most developers here. The most significant causes are usually outside the person&#x27;s control, as expected. Interestingly, &quot;interruptions &#x2F; randomness&quot; was only the sixth most significant, while the most significant cause was &quot;engineering system friction.&quot;<p>The average number of &quot;bad days&quot; per month is 3-5. Accounting for weekends and vacation days, that&#x27;s nearly 20% of the time! And some report 9+ bad days per month.<p>So, if you happen to work on corp-infra or other tooling&#x2F;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.
评论 #41957500 未加载
评论 #41959026 未加载
austinchainy7 months ago
The number one thing contributing to Bad Days is bloodsucking managers that don&#x27;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&#x27;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.
zeroonetwothree7 months ago
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.<p>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.
评论 #41957868 未加载
评论 #41958313 未加载
DidYaWipe7 months ago
I don&#x27;t work in an office or on a team. Top bad-day causes I find in self-employed dev situations:<p>1. Bad or no documentation on tools or technology being used<p>2. Defects in tools being used<p>These are so bad now that I just don&#x27;t even want to be in the field anymore much of the time. For either of them, you&#x27;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&#x27;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.
评论 #41958991 未加载
Smaug1237 months ago
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&#x27;s an entire blocker for &quot;Teams isn&#x27;t working&quot;.<p>Personally my worst days are &quot;I did a thing, rolled it out, found it was seriously broken, rolled it back, and now it&#x27;s 6pm and that is what I did today&quot;. I couldn&#x27;t see anything in their report that would cover that failure mode (it&#x27;s worse than &quot;couldn&#x27;t get anything done&quot;, because I was demonstrably incompetent at what I did do).
评论 #41958372 未加载
评论 #41963265 未加载
评论 #41959061 未加载
评论 #41958856 未加载
jmclnx7 months ago
These are the factors to me:<p>* formal meetings, where I was, 30 hours of meetings a week.<p>* Users wanting us to read their minds<p>* bureaucracy, need to ask permissions to do one little thing<p>* Jira
评论 #41957998 未加载
评论 #41958867 未加载
ldjkfkdsjnv7 months ago
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
siva77 months ago
Meetings in the morning. Let me get my sleep first!
sixothree7 months ago
Working from home I can report that leaf blowers ruin my day pretty quickly. Some days it will be 4 hours of lawn equipment running.
评论 #41958720 未加载
评论 #41958770 未加载
评论 #41958842 未加载
readthenotes17 months ago
22 developers given reasons a through h to identify a reason for a bad day.<p>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 ...
评论 #41959146 未加载
Yenrabbit7 months ago
I found an extra one not mentioned in the article when I tried abstaining from caffeine last week. Energy slumps mid day, a few headaches, and overall a major reduction in productivity and fun! Maybe unsurprising to most.
评论 #41969053 未加载
yobid207 months ago
This study is so spot on i had to go back to the top to see if it was written by people from our own company. (It wasnt). Mind blown.
jart7 months ago
Every day above ground is a good day.