11–20 of 653 posts
For me, I put my mistakes in perspective. Did anyone die? No? Then on the scale of important consequences the mistake was statistically inconsequential. My day is ok.
For me, I put my mistakes in perspective. Did anyone die? No? Then on the scale of important consequences the mistake was statistically inconsequential. My day is ok.
This is a double edge sword because this perspective makes me not try hard at my job or take it less seriously. Especially when my boss is griping at me about some mundane task or detail.
If so, you may find it helpful to remember that the code you are working on does not belong to you, it belongs to the company/shareholders, and your job is to make it do what they want, more or less how they want.
That doesn't mean you have to do anything that is dumb, or not in the best interests of the company, but if someone asks you to do something that is dumb or not in the bests interests of the company, you may have to explain (very clearly, and often repeatedly) why it is not in the best interests of the company, and in doing so you may find that you had imperfect information about all of the relevant stakeholders and requirements.
Failure to remember this may result in being reminded the hard way, by being terminated / laid off, managed out.
Conversely, if you have great ideas and want to control everything, feel free to start your _own_ company, find your own clients, etc.
I used to get a lot of negative feedback from my boss, every week it was something else. Turns out he was going through a bad period. I switched bosses and everything was fine. It sucks when it's your boss, but it's still only a personal opinion of one person.
For me, I put my mistakes in perspective. Did anyone die? No? Then on the scale of important consequences the mistake was statistically inconsequential. My day is ok.
This is a double edge sword because this perspective makes me not try hard at my job or take it less seriously. Especially when my boss is griping at me about some mundane task or detail.
For example, if there seem to be two interpretations of a comment on a PR, one that is genuine and one that is snarky, assume they were genuinely trying to help and reject the snarky version. This is easier said than done, but it's a useful skill to practice.
I think the second sentence is true for everyone's code and that's what makes the job interesting.
Also jobs rarely aim for perfection, they aim to create value efficiently for the business. If the best way of getting there is producing code with a few mistakes that are when later picked up in a code review then that's fine too.
If this resonates with you at all, then when something annoys you repeating to yourself "It's just code" might help. Best of luck!