While true usually there is no time to properly educate the others. Bug fixed? Move along. Next.
We'll document it later. No we won't, tomorrow there will be another fire.
One common behavior seen in “mature” software engineers
51–60 of 123 posts
Re: One common behavior seen in “mature” software engineers
#52> They take the extra step to make sure the next person won't have to spend the same level of energy fixing the same issue, or eliminate the problem class altogether for their team. Conversely, I find it frustrating when engineers do the absolute minimum, avoid refactors, and put the next person at a disadvantage ... all while their velocity is recognized by management as good.
> I find it frustrating when engineers do the absolute minimum, avoid refactors, and put the next person at a disadvantage
If such engineers don't care about other or future engineers who will have to touch their work, they should at least care about themselves. Perhaps they've never heard the maxim: work to make the life of the next engineer to touch the code easier, because the "next engineer" will probably be you.
Re: One common behavior seen in “mature” software engineers
#53> They take the extra step to make sure the next person won't have to spend the same level of energy fixing the same issue, or eliminate the problem class altogether for their team. Conversely, I find it frustrating when engineers do the absolute minimum, avoid refactors, and put the next person at a disadvantage ... all while their velocity is recognized by management as good.
> I find it frustrating when ... recognized by management as good. ... but you're not the one writing the checks, remember? Management is. They don't care about quality. They can't even define it, much less recognize it. They care about delivery dates. Delivery dates are easy to measure. So that's what matters. > put the next person at a disadvantage The first guy was at the same disadvantage - which was that he was…
You're describing dysfunctional or bad management. Not all companies are like that.
Re: One common behavior seen in “mature” software engineers
#54> They take the extra step to make sure the next person won't have to spend the same level of energy fixing the same issue, or eliminate the problem class altogether for their team. Conversely, I find it frustrating when engineers do the absolute minimum, avoid refactors, and put the next person at a disadvantage ... all while their velocity is recognized by management as good.
I'm conflicted about this. Definitely am a fan of "leave it better than you found it", refactor as you go, etc. But when it comes to bug fixes, the "absolute minimum" is often the best approach -- it can be explained to demonstrate that we know precisely the root cause of the problem, it can be reviewed for correctness readily, and we can feel good that we are not adding a lot of new behavior that can have downstream…
It's a judgement call. If you're maintaining software, it's true that every time you touch the code -- even to fix a bug -- you're taking a risk that you're introducing a new bug. Refactoring software is an even greater risk.
So, in general, the instinct is (and should be) to touch the code as little as possible. However, that's not always the right answer. The right answer is to do a risk/benefit calculation and choose the approach that is most likely to lead to an overall improvement.
Sometimes, that means change as little as possible to fix a bug. Sometimes, that means refactoring a major piece. It all depends.
Re: One common behavior seen in “mature” software engineers
#55The idea of fixing a whole class of problems is common in safety critical software. When you find the cause of a bug its not just about fixing the bug but looking for this pattern of failure everywhere and fixing that and then understanding the aspects that led to this class of bugs to begin with and eliminating those. Its just good engineering to solve the class of problems not just the bug in front of you. But I ha…
Yeah the only way to get rewarded for working on resiliency like this is if you do it very loudly. If you spend an extra day or two refactoring a feature so that it is more robust you will be looked at poorly versus the engineer who slaps a few more conditionals onto it to keep it working. Raise the issue with higher ups, maybe create some fancy charts about lost engineering time in the future, spin up specific ticke…
If they dont like that you took more time to refactor instead of bandaid, they arent going to respond well to you boasting about it for weeks.
Re: One common behavior seen in “mature” software engineers
#56So the young soldier moved the stone, marked the area, and warned everybody about this to spare them.
He was mocked and bullied by everybody.
ps: don't forget about herd psychology and politics, not all peers want to see your good deeds, no matter how generous or useful they are.
Re: One common behavior seen in “mature” software engineers
#57Earlier quoted context omitted.
I saw this often. The heroes who are up late, solving a page or mitigating an outage are often the ones remembered and rewarded. Meanwhile, a dependable, resourceful, and independent IC who “picks up trash on the floor”, promotes good work habits, and is dead reliable - no praise, they are just “doing their job” Managers and leaders like drama, most staff and senior engineers gravitate to drama and love talking about…
Everyone is selling something, and stories are how you do it. Can’t have a story without some drama
This is why I need a different job. This pattern sucks energy out of me. I need military minded coders.
Re: One common behavior seen in “mature” software engineers
#58I'll take forced parables that don't make any sense in the metaphorical context in which they're framed for $500.
Here is an easy example.
You have a project that has both typescript and javascript. Someone makes a change in a JS file. They try to access a property of an object but there is a typo.
You could fix the typo and be done.
Or you could fix the typo, and convert the file to TS and make sure its typed.
Re: One common behavior seen in “mature” software engineers
#59So the young soldier moved the stone, marked the area, and warned everybody about this to spare them. He was mocked and bullied by everybody. ps: don't forget about herd psychology and politics, not all peers want to see your good deeds, no matter how generous or useful they are.
He was only mocked because he wasn't wearing his PT belt.
Re: One common behavior seen in “mature” software engineers
#60Earlier quoted context omitted.
Everyone is selling something, and stories are how you do it. Can’t have a story without some drama
This is why I need a different job. This pattern sucks energy out of me. I need military minded coders.
I’m interested in understanding what it means to be a military minded coder.