> Comments going out of date is a shit excuse for not writing comments as far as I’m concerned.
I agree.
> Comments go out of date because of bad developers
I disagree.
Comments can also go out of date because
- developer is having a really shit time atm and their head is not in the game (bad looking after people management)
- developer is on a one day a week contract and doesn’t have the time in their contract to write big header comments explaining nuances (bad strategy)
- developer thought it looked obvious to them but it’s not obvious at review time (developer is being classic human)
- developer is getting pushed to deliver the thing now now now (bad workload management)
Most of those are the result of some decision made by someone who was not the developer (they’re all real cases). And they are the “non-code blockers” that good managers solve for us, so we can focus on getting good stuff done.
I’ve been where it seems like you are at. Blaming others for being bad didn’t help me. I had to lower my expectations of others, keeping my expectations for myself. Then get on about teaching willing people how they could be better. Might be making a few assumptions/projecting a bit there, but that’s my experience with “bad developers”.
Being any type of “leader” is lonely. Whether that’s an official role assigned to you or not. Or if it’s just a skill level thing. No one can quite match up to the expectations or understand what we see and why. But explaining it goes a long way with the right ones.
I agree.
> Comments go out of date because of bad developers
I disagree.
Comments can also go out of date because
- developer is having a really shit time atm and their head is not in the game (bad looking after people management)
- developer is on a one day a week contract and doesn’t have the time in their contract to write big header comments explaining nuances (bad strategy)
- developer thought it looked obvious to them but it’s not obvious at review time (developer is being classic human)
- developer is getting pushed to deliver the thing now now now (bad workload management)
Most of those are the result of some decision made by someone who was not the developer (they’re all real cases). And they are the “non-code blockers” that good managers solve for us, so we can focus on getting good stuff done.
I’ve been where it seems like you are at. Blaming others for being bad didn’t help me. I had to lower my expectations of others, keeping my expectations for myself. Then get on about teaching willing people how they could be better. Might be making a few assumptions/projecting a bit there, but that’s my experience with “bad developers”.
Being any type of “leader” is lonely. Whether that’s an official role assigned to you or not. Or if it’s just a skill level thing. No one can quite match up to the expectations or understand what we see and why. But explaining it goes a long way with the right ones.