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.
Identifying factors contributing to "bad days" for software developers
51–60 of 63 posts
Re: Identifying factors contributing to "bad days" for software developers
#52I 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…
> the QA env was not actually setup to mirror the production env
As senior QA, this alone is going to end me one day.
Re: Identifying factors contributing to "bad days" for software developers
#53Earlier quoted context omitted.
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
Sure. Right now I'm trying to port a just-started project from a pure-Deno back-end to Supabase. I'm building a back end for a mobile application. 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…
Try api-fiddle.com as a replacement for stoplight.io :)
Re: Identifying factors contributing to "bad days" for software developers
#54Earlier quoted context omitted.
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 sched…
Sounds like a good TPM, I must admit I haven't worked at a company that had a "scrum master" title and didn't realize the role had grown in scope.
I'm not sure it is a larger scope, I've always understood this to be their role - they lead scrum meetings, but outside meetings they were the one that helped get the team unblocked. Managing the board was just a side-effect of keeping an eye out for any team members who were stuck.
On top of that the one I worked with who was good at this also took on small cases because otherwise he'd regularly have nothing to do.
Re: Identifying factors contributing to "bad days" for software developers
#55Earlier quoted context omitted.
Sure. Right now I'm trying to port a just-started project from a pure-Deno back-end to Supabase. I'm building a back end for a mobile application. 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…
Try api-fiddle.com as a replacement for stoplight.io :)
Thanks for that. Took a look at it, and... it doesn't handle 3.1 documents correctly. One of the major defects in the OpenAPI document spec pre-3.1 is that you can't put descriptions on any usage of a model in your API. I mean... WTF?
So if you had a data structure called User, and you used it to represent users in different roles in your API somehow, you can't annotate the instances of User in your document to say what kind of user you're talking about. You can annotate the elements inside the User model (like strings, numbers, or whatever) but not usages of the model itself. Before version 3.1, this blunder rendered OpenAPI half-useless for one of its core purposes: documenting your API.
API-Fiddle acts as though that's still true. There is no Description button anywhere in your schema alongside any use of a model.
Re: Identifying factors contributing to "bad days" for software developers
#56Inversely 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.
I'm sorry for your experience with second level managers. For me they were all very chill and friendly, so it's definitely not a hard rule that all higher managers are bad.
Re: Identifying factors contributing to "bad days" for software developers
#57"""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...
I think the separation makes sense. Scheduled meetings spread out through the day rather than grouped together and running efficiently is definitely a bad day for me.
But small, 2-5 minutes interruptions for a quick question never bothered like it seems to do with a lot of people here on HN. I can go back to my focus pretty instantly after a “quick question interruption”.
Re: Identifying factors contributing to "bad days" for software developers
#58Earlier quoted context omitted.
Jira is AWFUL.
I _once_ worked in a place where Jira was without question "a great thing that improved productivity'. 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 setti…
Is that Jira config in a blog post somewhere? Imagine how many person-years of bureaucracy it would save.
Re: Identifying factors contributing to "bad days" for software developers
#59Somewhat 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…
"demonstrably incompetent" and "demonstrably unsuccessful" are two different things. You can be the latter at a task without necessarily being the former.
Re: Identifying factors contributing to "bad days" for software developers
#60Every day above ground is a good day.