Earlier quoted context omitted.
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.
"There is no later." is my new mantra.
Identifying factors contributing to "bad days" for software developers
41–50 of 63 posts
Re: Identifying factors contributing to "bad days" for software developers
#42I 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…
Re: Identifying factors contributing to "bad days" for software developers
#43"""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 /…
I notice that if you add the "lack of focus time" responses to that, you'd get the 3rd most significant factor, which feels closer to right to me...
Re: Identifying factors contributing to "bad days" for software developers
#44Somewhat 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…
"Poor productivity" ranked 3rd in figure 4.
Re: Identifying factors contributing to "bad days" for software developers
#45"""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 /…
> Interestingly, "interruptions / randomness" was only the sixth most significant, while the most significant cause was "engineering system friction." I notice that if you add the "lack of focus time" responses to that, you'd get the 3rd most significant factor, which feels closer to right to me...
Scheduled and unscheduled interruptions?
Re: Identifying factors contributing to "bad days" for software developers
#46These 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
Jira is AWFUL.
They had a person who'd been trained by Atlassian and worked full time on configuring Jira (and Confluence) - in a workforce of maybe 25 developers 5 designers and 4 QA/testers. (out of around 100 people, the rest heavily top loaded on project management and $1000 haircut account managers)
She was _so_ good at setting up Jira so that it worked super well for the developers, and enforced decent requirements and requirement change management on account managers and project managers. The dev and QA all loved her.
Senior management flew that company into the ground about 8 months after she started, leaving 100+ people unpaid for their final month, and stiffed everybody on outstanding leave and 3 months of superannuation (retirement).
She did get 3 of my best devs work at Atlassian within days. She is very very near the top of the list of "people I'd go and poach from whatever they're doing if I landed the right project that needed and was prepared to pay highly for their skillset.
Re: Identifying factors contributing to "bad days" for software developers
#47Working from home I can report that leaf blowers ruin my day pretty quickly. Some days it will be 4 hours of lawn equipment running.
I solve that the blunt force way. Heavy duty over the ear hearing protection, like shooters eeesr at a gym range. I find it works better than noise canceling. If things are really intolerably bad you can double up with foam earplugs under.
Foam earplugs inside noise cancelling headphones.
Even on short 1hr flights, it's amazing how much less stressed and more relaxed I find myself after disembarking. I can get 8 or more hours sleep on a 14 hour flight that way.
Re: Identifying factors contributing to "bad days" for software developers
#4822 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
#49Working from home I can report that leaf blowers ruin my day pretty quickly. Some days it will be 4 hours of lawn equipment running.
We could, as a society, ban the use of gas powered leaf blowers.
Re: Identifying factors contributing to "bad days" for software developers
#50I 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…
Can you share an example? I rarely have this problem, likely because I bias towards building it myself and only bring in outside tools when there's significant time savings
But if you're not building another Web SPA, it's as if you don't exist for a lot of these frameworks. And doing simple stuff like deploying your own certificates is undocumented. Also they have a users table whose columns are undocumented and behave in unexpected ways. For example, they have columns to record whether and when a user has been validated (confirmed via E-mail), and for some reason these are set upon new-user creation... when they certainly have not been validated. Why? Who knows.
Another example: I was tasked with defining a REST-style API for a line of products. After learning about OpenAPI, I thought great, I'll design it in an OpenAPI tool and that'll be the source of truth for both front- and back-end code generation.
Fat chance. The OpenAPI ecosystem turned out to be a dysfunctional shitshow. First, the current version (as of years ago) is 3.1. But to this day, almost no tools support it. Version 3.0 was profoundly flawed in several ways. And even tolerating that, the 3.0 code-gen tools just straight-up don't work. Plus, the design tool I was using (Stoplight Studio) has been pulled off the market, and nothing has emerged to replace it. The whole thing was a huge time-suck. I talked to some developers about it after the fact and they said yeah, the whole thing is so bad that even mentioning you were using it is a professional liability.
Defect example: iOS 18 broke trusted certificates (still not fixed in 18.1), so currently you can't develop a network-dependent app on iOS on your own system. When I tried to work around that by targeting my Mac and using HTTP to localhost, another Apple bug caused the app to crash on launch before even getting to my code. So... dead halt to development for a week, despite my opening a paid support incident with Apple. They did finally get back to me and gave me a workaround to the crash-on-launch bug (no charge because confirmed bug), but damn.
More days lost. I had stretches like this before, and then the logjam breaks and I really start making headway. But this shit has been a slog for months.