4 ms·

OP is frustrated with flaky and constantly changing tools, silent breaking bugs, poorly documented libraries that change capriciously, and unhelpful IDEs, all c

OP is frustrated with flaky and constantly changing tools, silent breaking bugs, poorly documented libraries that change capriciously, and unhelpful IDEs, all connected to and reliant on badly behaving services. Why is game development different? My experiences with the larger or more popular publicly available engines available haven't suggested that.

actsasbuffoon 4y ago
One paragraph mentioned that, but the thrust of the argument was about burnout. For me, burnout occurs when I feel like I’m putting a lot of time and effort into something but I’m not getting enough back to justify it. Burnout is like a mechanism to get you to stop pouring energy into something that isn’t working. Unfortunately, many managers are bad at giving positive feedback. The only time you hear from them is when something isn’t working. Corporate processes slow things down and make you feel ineffective. Eventually you start to wonder if you’re actually bad at software development, or if you’re just a bad worker. Let’s say you get a ticket for a performance problem. It turns out that the app is doing something kind of silly, and it would be easy to fix the problem and you’re confident that users would be okay with it. Well, too bad. You’re not allowed to make product decisions; only management can do that. So you bring it to management, but they’re in a meeting. You don’t have enough time to do anything else, so you spend 15 minutes reading HN. They get out of the meeting, and you explain the problem. They’re okay with the change, but because it affects the UI, you need to get approval from the UX team. You explain that it’s a very minor change, but management insists that you have to follow the process. You go to UX. You explain the problem, but they don’t have time to get back to you. You figure it’s going to be a bit, so you grab another ticket. 20 minutes later, it turns out that they’ve approved your request. It was a very small change, after all. So now you have to put your ticket back, which is going to mess with the time tracking in Jira that your boss gets pissy about, but whatever. You make the change, which takes about 5 minutes. You commit, push, and open a PR. The CI tests fail. Apparently there was some kind of silly linter error, so you fix that and push again. Now you wait for the tests to pass, which takes about 40 minutes. The QA team requires a detailed set of instructions for how to test every ticket, so you start writing up those instructions in the Jira ticket. As that’s happening, you get a Slack message from the documentation team. They noticed your ticket status change, and you forgot to mark it as requiring doc review because it affected the UI. You apologize and go back to update the ticket. When you’re done updating the ticket, you notice the build has failed. Looks like a flakey test that’s been a problem for months now, but no one ever gets time to fix it. You re-run the tests and cross your fingers. Time for a sprint planning meeting. Two hours later you resume work. The build passed, but your irritatingly picky co-worker has requested a change on your PR. He always requests at least one change on every PR, no matter how small. You used this method to find an element in an array, and while there’s nothing wrong with that, he personally prefers that method for doing it, and he won’t approve your PR until you change it. So you update the branch and push again. Then you start working on filling out information for the compliance team which is needed for anything affecting this part of the application. You wrap that up and notice that the flakey test failed again. Swearing under your breath, you re-run the build. You spend some time reviewing PRs for your co-workers and see that your build passed and your picky co-worker approved the changes. You merge and move onto something new. A few minutes later you get a message from the QA team. You didn’t provide documentation for how to test the code. You remember that you were in the middle of writing it when you got interrupted, and you forgot. You apologize and finish writing it. You look at your watch and realize that it’s the end of the day. You know your boss is going to be irritated with you after standup tomorrow because you spent all day working on a ticket that was only estimated for half a day. This is the kind of stuff that makes me want to run away from software development and never return. It’s not the code; it turns out that after all these years I still love programming. It’s all of the soul crushing BS that makes me lose the will to live. And so far, the antidote for that has been to work on something with zero red tape where I have full autonomy. It reminds me that I’m actually very good at software development.
- trynewideas 4y ago
  I don't disagree with any of this, but I've read OP's comment again and again in light of the discussion in the comments here and I don't see anything in there about process. It's not just one paragraph: - "Any project I work on is connected to a million different tools, workflows and services, that all do things their own way, and everything lives in a totally different place, where it’s hard to monitor what’s going on." - "I feel like anything can break at any moment and ruin my day. I don’t understand any of the tools well enough to be confident that it’s stable, and the worst problems are the silent ones." - "All the frameworks/libs I use insist on being too flexible, to the point where I don’t know where to start and how to do things. ... Oh and every 10 minutes there is a new tool that pops up that does things differently." - "I’d rather fight with my brain than with the tools I use." - "I wish I could just use an IDE that takes care of all the crap for me" - "There is no invisible ghost that lives in a separate realm (dev environment) that can ruin your work at any time and leave no trace."
  - actsasbuffoon 4y ago
    I apologize; I may have explained poorly. I was trying to convey that burnout is (IMHO) a result of putting a lot of effort into something and not getting enough back out of it. It’s like a defense mechanism to stop wasting energy. This may be a result of processes, tools, compensation, treatment by co-workers, or any number of other factors. And my suggestion on how to resolve burnout is to find a way to feel productive and capable again. Personally, game development worked for me. But I also mentioned mobile app development as a possible avenue, but obviously this list isn’t intended to be exhaustive. Just find something that helps you remember why you loved programming in the first place. You probably haven’t stopped enjoying the act of writing code. It’s just that something at work is making you unhappy, and you’ve started to associate those negative feelings with programming in general.

actsasbuffoon 4y ago

One paragraph mentioned that, but the thrust of the argument was about burnout. For me, burnout occurs when I feel like I’m putting a lot of time and effort into something but I’m not getting enough back to justify it. Burnout is like a mechanism to get you to stop pouring energy into something that isn’t working. Unfortunately, many managers are bad at giving positive feedback. The only time you hear from them is when something isn’t working. Corporate processes slow things down and make you feel ineffective. Eventually you start to wonder if you’re actually bad at software development, or if you’re just a bad worker. Let’s say you get a ticket for a performance problem. It turns out that the app is doing something kind of silly, and it would be easy to fix the problem and you’re confident that users would be okay with it. Well, too bad. You’re not allowed to make product decisions; only management can do that. So you bring it to management, but they’re in a meeting. You don’t have enough time to do anything else, so you spend 15 minutes reading HN. They get out of the meeting, and you explain the problem. They’re okay with the change, but because it affects the UI, you need to get approval from the UX team. You explain that it’s a very minor change, but management insists that you have to follow the process. You go to UX. You explain the problem, but they don’t have time to get back to you. You figure it’s going to be a bit, so you grab another ticket. 20 minutes later, it turns out that they’ve approved your request. It was a very small change, after all. So now you have to put your ticket back, which is going to mess with the time tracking in Jira that your boss gets pissy about, but whatever. You make the change, which takes about 5 minutes. You commit, push, and open a PR. The CI tests fail. Apparently there was some kind of silly linter error, so you fix that and push again. Now you wait for the tests to pass, which takes about 40 minutes. The QA team requires a detailed set of instructions for how to test every ticket, so you start writing up those instructions in the Jira ticket. As that’s happening, you get a Slack message from the documentation team. They noticed your ticket status change, and you forgot to mark it as requiring doc review because it affected the UI. You apologize and go back to update the ticket. When you’re done updating the ticket, you notice the build has failed. Looks like a flakey test that’s been a problem for months now, but no one ever gets time to fix it. You re-run the tests and cross your fingers. Time for a sprint planning meeting. Two hours later you resume work. The build passed, but your irritatingly picky co-worker has requested a change on your PR. He always requests at least one change on every PR, no matter how small. You used this method to find an element in an array, and while there’s nothing wrong with that, he personally prefers that method for doing it, and he won’t approve your PR until you change it. So you update the branch and push again. Then you start working on filling out information for the compliance team which is needed for anything affecting this part of the application. You wrap that up and notice that the flakey test failed again. Swearing under your breath, you re-run the build. You spend some time reviewing PRs for your co-workers and see that your build passed and your picky co-worker approved the changes. You merge and move onto something new. A few minutes later you get a message from the QA team. You didn’t provide documentation for how to test the code. You remember that you were in the middle of writing it when you got interrupted, and you forgot. You apologize and finish writing it. You look at your watch and realize that it’s the end of the day. You know your boss is going to be irritated with you after standup tomorrow because you spent all day working on a ticket that was only estimated for half a day. This is the kind of stuff that makes me want to run away from software development and never return. It’s not the code; it turns out that after all these years I still love programming. It’s all of the soul crushing BS that makes me lose the will to live. And so far, the antidote for that has been to work on something with zero red tape where I have full autonomy. It reminds me that I’m actually very good at software development.

trynewideas 4y ago
I don't disagree with any of this, but I've read OP's comment again and again in light of the discussion in the comments here and I don't see anything in there about process. It's not just one paragraph: - "Any project I work on is connected to a million different tools, workflows and services, that all do things their own way, and everything lives in a totally different place, where it’s hard to monitor what’s going on." - "I feel like anything can break at any moment and ruin my day. I don’t understand any of the tools well enough to be confident that it’s stable, and the worst problems are the silent ones." - "All the frameworks/libs I use insist on being too flexible, to the point where I don’t know where to start and how to do things. ... Oh and every 10 minutes there is a new tool that pops up that does things differently." - "I’d rather fight with my brain than with the tools I use." - "I wish I could just use an IDE that takes care of all the crap for me" - "There is no invisible ghost that lives in a separate realm (dev environment) that can ruin your work at any time and leave no trace."
- actsasbuffoon 4y ago
  I apologize; I may have explained poorly. I was trying to convey that burnout is (IMHO) a result of putting a lot of effort into something and not getting enough back out of it. It’s like a defense mechanism to stop wasting energy. This may be a result of processes, tools, compensation, treatment by co-workers, or any number of other factors. And my suggestion on how to resolve burnout is to find a way to feel productive and capable again. Personally, game development worked for me. But I also mentioned mobile app development as a possible avenue, but obviously this list isn’t intended to be exhaustive. Just find something that helps you remember why you loved programming in the first place. You probably haven’t stopped enjoying the act of writing code. It’s just that something at work is making you unhappy, and you’ve started to associate those negative feelings with programming in general.