I'm not saying this for the good of your team, even though it will be good for your team. I'm telling you this for your own sake: don't martyr yourself for your software development opinions!
Software engineering attracts a certain type of mind. Our thinking is necessarily precise -- the computer does exactly what we tell it to do, and if we tell it to do something incorrectly, that's on us. In general, this leads to strong views on how development should be done. Every programmer I've met that has two or more years of development experience has already developed strong beliefs about sustainable, maintainable development conventions, and does not hesitate to inform you about them.
This is fine in isolation -- you have your principles, you stick to them, and your code is cleaner and more maintainable as a result. You always use spaces, you use the gitflow workflow when branching in source control, you always promote through dev/stg/prd environments, you use the pytest framework for unit tests, etc etc. You are a paragon of forward-thinking development discipline.
Problems arise, though, when you must work on a project with an engineer who doesn't share your ideology. Yes, I use that word on purpose: "best practices" are ideology, not universal laws. Good software can be written in myriad ways, and so two skilled engineers can have equally valid, yet diametrically opposed, opinions about development practices.
And so we come to the hard truth of my rant: it is better to conform to the development practices accepted by the majority of your team than to try and force them to accept your convictions. Nothing tanks productivity on a team faster than arguing about development practices and tooling. It might be hard for you to accept, but your pet convention is not so superior that it is worth wasting engineer-weeks (or even engineer-days!) arguing about.
If you just can't accept the idiotic processes your team has in place, and you feel so strongly about your development conventions that you find yourself trying to convince your coworkers again and again to change their ways, it's probably best for everyone if you try and find a role on a new team that shares your convictions. You will be happier, your former team will be happier, your new team will welcome you with open arms, you will crush all your performance reviews, and society will be improved by all the code you will be shipping.
Top comments (4)
I don't really agree with this.
The problem inherent to everyone simply acquiescing to "the way things are done" is that it creates a culture of not speaking up when some process is possibly wrong, or capable of being drastically improved. This environment can stifle innovation, and lead to frustrated, extremely talented developers simply moving on.
Far better to encourage the questioning (in a mature, rational manner) of any conventional wisdom believed to be wrong. This is how progress is made.
Having been in a lot of both, I've seen that it's far better to be in a development democracy, rather than a development dictatorship.
Not entirely true.
Repeated wrongs does not make wrong right.
If the team isn't following "semantics", they should be educated on the right way to do things.
Just because you don't want to be an angel does not mean, you make a deal with the devil.
How do you balance judging between "valid, yet diametrically opposed, opinions about development practices" and situations that need to be addressed... e.g. I worked for a shop where no testing was implemented (another dev once told me, verbatim, that he was "supposed to be the QA guy but has never written a test"). I err on the side of accepting existing development practices, but I didn't see any way that current dev practices would lead to success, so became more vocal about it. Then it became a constant internal tug of war of when it would be productive/counterproductive to say something. Even if dev practices need to be improved, there's diminishing returns on being the PITA that can't keep his opinions to himself
I think if no tests are being written at all for software that has any kind of SLA it's going to be a huge problem down the road, as you mentioned.
Obviously this is massively opinionated, but in that situation I would emphasize best practices over and over for a month or two, and if the team wasn't receptive I'd get out and find another team.