There are many things that can potentially go wrong in a project. I’m sure you also have your own unique horror story, or stories. But you’re too busy writing code. There’s no time to take a step back to try to figure out why you’re feeling this way.
Is this the nature of being a developer? Do all developers feel this way? Are you going to be feeling like this forever, as long as you are writing code for a living?
Is this really all your fault? Are you the one to blame?
You can try to deflect the blame. You can say this is not your fault. The idea isn’t as good as you thought it was. The design is too complex. The requirements are too stringent. The edge cases are too encompassing. There’s not enough time and budget planned for this large app. Or this team just doesn’t work well together. Maybe there are communication issues that need to be dealt with first.
You can also choose to take all the blame. Yes. This is your fault. You didn’t architect your app properly. You didn’t design and decouple your classes correctly. You didn’t refactor enough. The unit tests have holes in their coverage.
Or somewhere in between. A popular, feel-good, folk tale version. We work as a team. We fail as a team. We take the fall together as a team. So it’s everybody’s fault. No finger pointing.
From Rethinking work:-
To start with, I don’t think most people recognize themselves in Adam Smith’s description of wage-driven idlers. Of course, we care about our wages, and we wouldn’t work without them. But we care about more than money. We want work that is challenging and engaging, that enables us to exercise some discretion and control over what we do, and that provides us opportunities to learn and grow. We want to work with colleagues we respect and with supervisors who respect us. Most of all, we want work that is meaningful — that makes a difference to other people and thus ennobles us in at least some small way.