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.
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.
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.
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.
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.
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.
"""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.
> 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.
> 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.
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”.
Yeah, sounds right. I think they're separated because an abundance of meetings, or just poorly scheduled meetings, can contribute to lack of focus time.
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.
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 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.
We got rid of scrum masters. They were useless. We just run it all ourselves now. Ditched the entire scrum process, and just have a task kanban board now run by all engineers. This works SO MUCH BETTER. Our daily "scrum" meetings dropped from 1-2 hours per day to 10-15 min.
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.
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.
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...
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.
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.
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 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.
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.
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).
> “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.
"demonstrably incompetent" and "demonstrably unsuccessful" are two different things. You can be the latter at a task without necessarily being the former.
Well for us this could be internal job boards. When companies have 10k+ engineers our internal job boards are huge with people switching teams all the time.
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 _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 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.
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
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.
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.
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 ...
"I took down prod and accidentally dropped the entire db table of real customer transaction data. But I've got a date tonight with that new hottie from the gym." = Good day.
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.
Try cutting down your caffeine really slowly. I did it by gradually cutting caffeinated coffee with slightly more decaff, over months. Eventually I was 100% decaff. Never had any withdrawal (the headaches, and energy slumps you mention).
And now I no longer have any of the bad symptoms caffeine was giving me: nervous tick, wildly fluctuating energy levels, random extreme emotions.
Back when I was younger, caffeine had none of those bad effects on me. But as I grew older, they started to ramp up. Because coffee was such a constant in my life, it took me many years to realise the cause.
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.
> the QA env was not actually setup to mirror the production env
As senior QA, this alone is going to end me one day.
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.
"There is no later." is my new mantra.
“I’ll just use a different provider that isn’t our inhouse over-engineered AWS yaml config platform.” Is mine.
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.
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.
"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.
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.
> 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.
This level of micro management sounds hellish. It suggests levels of anxiety so great they warp the fabric of spacetime.
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.
"""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.
> 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
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...
> 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”.
Yeah, sounds right. I think they're separated because an abundance of meetings, or just poorly scheduled meetings, can contribute to lack of focus time.
Scheduled and unscheduled interruptions?
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.
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 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.
We got rid of scrum masters. They were useless. We just run it all ourselves now. Ditched the entire scrum process, and just have a task kanban board now run by all engineers. This works SO MUCH BETTER. Our daily "scrum" meetings dropped from 1-2 hours per day to 10-15 min.
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.
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.
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...
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.
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.
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 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.
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.
Update on that: I contacted the developer and he fixed that problem in a matter of minutes. Pretty cool!
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).
> “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.
"demonstrably incompetent" and "demonstrably unsuccessful" are two different things. You can be the latter at a task without necessarily being the former.
> "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".
"Poor productivity" ranked 3rd in figure 4.
Well for us this could be internal job boards. When companies have 10k+ engineers our internal job boards are huge with people switching teams all the time.
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
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
Jirarrhea
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 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.
Is that Jira config in a blog post somewhere? Imagine how many person-years of bureaucracy it would save.
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
Meetings in the morning. Let me get my sleep first!
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.
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.
That's my "secret weapon" when flying.
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.
Bose noise cancelling headphones. Just leave them switched on without music playing. It will actively reduce the noise level.
We could, as a society, ban the use of gas powered leaf blowers.
California has already banned the sale, but not the use of a gas-powered engines with under 25 horsepower.
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 ...
"I took down prod and accidentally dropped the entire db table of real customer transaction data. But I've got a date tonight with that new hottie from the gym." = Good day.
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.
Try cutting down your caffeine really slowly. I did it by gradually cutting caffeinated coffee with slightly more decaff, over months. Eventually I was 100% decaff. Never had any withdrawal (the headaches, and energy slumps you mention).
And now I no longer have any of the bad symptoms caffeine was giving me: nervous tick, wildly fluctuating energy levels, random extreme emotions.
Back when I was younger, caffeine had none of those bad effects on me. But as I grew older, they started to ramp up. Because coffee was such a constant in my life, it took me many years to realise the cause.
Every day above ground is a good day.
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.