It’s funny, this comment went in a totally different direction from what I expected based on the start.
When you wrote ‘don’t take things personally at work’, I was expecting you to say things things about various kinds of humility – trying to make requested changes in code review instead of pushing back, not feeling wronged if someone rewrites something you wrote, etc – and seeing the bigger picture – the code exists to serve business purposes and sometimes priorities there don’t align with your more narrowly focused desires for the direction the code should be changed in.
I would say that the rest of you comment gives examples of taking things quite personally – feeling such strong ownership over the code that you’ll quit when you can’t control it as well as you’d like. To be clear, I’m arguing that the beginning does not match the rest of the comment, but not really about the overall message, which to me feels to be more something like ‘you are not required to be loyal’ than ‘don’t take it personally’.
I explain more in other comments, but in this situation I was dealing with people who fundamentally could not program .
It wasn't a matter of, oh I would have done this differently, it was more like this company is full of people who have no idea what they're doing and I'd rather not be here .
I will say you should absolutely never talk about code issues at a current employer when interviewing. Who's ever interviewing you is going to interpret this as you being some weirdo who argues over tabs and spaces. There's not enough nuance communicated.
Maybe I'm trying to say you shouldn't take it personally when a company isn't a good fit.
There's a huge difference between "I don't like your variable name" and "this code is so messed up that any change will have to be manually checked against 20 major features under 20 different cases".
A lot of my progression as a software engineer has come from decoupling my ego from the things I produce. That’s hard to do because the code you produce is a very strong reflection of your mental models and it’s justified to feel some connection to it.
Tactfully navigating this kind of thing in code review takes practice.
In my experience, the best teams of programmers work through problems with their egos held to the side.
100% agree with you. The best teams I've been on have had complete harmony whether things were running smoothy or not. Everybody just banded together and got it done. Every once and awhile we'd encounter some bad code someone wrote and have a good laugh with each other and fix it up. Each and every person had one another's backs.
When you wrote ‘don’t take things personally at work’, I was expecting you to say things things about various kinds of humility – trying to make requested changes in code review instead of pushing back, not feeling wronged if someone rewrites something you wrote, etc – and seeing the bigger picture – the code exists to serve business purposes and sometimes priorities there don’t align with your more narrowly focused desires for the direction the code should be changed in.
I would say that the rest of you comment gives examples of taking things quite personally – feeling such strong ownership over the code that you’ll quit when you can’t control it as well as you’d like. To be clear, I’m arguing that the beginning does not match the rest of the comment, but not really about the overall message, which to me feels to be more something like ‘you are not required to be loyal’ than ‘don’t take it personally’.