The article describes how it should be. But in experience, it's sadly the one who churns out most features that wins. It doesn't' matter if the leaves the codebase in ruins. That someone's else's problem.
One common behavior seen in “mature” software engineers
61–70 of 123 posts
Re: One common behavior seen in “mature” software engineers
#62The 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…
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…
Yes, this is my problem. I'm seen as slow, because I take my time to deliver my stuff. And I'm rarely the hero of fixing some outage or some critical bug. Because my stuff works, quietly. The heros are always busy; fixing that bug and extinguishing that fire and delivers the new feature in a day (as soon as they clean up the latest incident). What people see is that I take three days to deliver the same feature. What they don't see is that I don't have to spend in total two weeks (spread over some time), fixing bugs and cleaning up corrupt data for the same feature.
Re: One common behavior seen in “mature” software engineers
#63Promotions are a function of the person(s) awarding the promotion and the person receiving them. Article is about the ideal behavior of the person receiving them. Unfortunately, often the people awarding promotions are looking for some other quality or are completely incapable of distinguishing level N+1 behaviours from the rest.
Re: One common behavior seen in “mature” software engineers
#64The article speaks about a generic behaviour for good managers wherever they are managing.
Re: One common behavior seen in “mature” software engineers
#65Earlier quoted context omitted.
Young soldier, aren't you taking the story a bit too literally?
I guess. But as a millennial who's been in the place of that young soldier a bit too many times, it's difficult to see it from the general's point of view. The message of subordination stands out more to me.
There's no message of subordination. The message is fix the problem, don't just plan to avoid it.
Re: One common behavior seen in “mature” software engineers
#66One common sign our industry is a sea of wasters...
Re: One common behavior seen in “mature” software engineers
#67This is great. I have a person at my company who doesn't even "learn the stone" for his own stuff. This person isn't even a baseline engineer - he's a negative for the whole team. And the management who doesn't recognize this is dragging us down as well.
Re: One common behavior seen in “mature” software engineers
#68> 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…
"Absolute minimum" in practice usually means hard-coding a special case/workaround directly into a live prod instance. That is the quickest and 99% of the time won't cause any operational issues in the short-term. It happens all the time and contributes enormously to technical debt.
Re: One common behavior seen in “mature” software engineers
#69The article describes how it should be. But in experience, it's sadly the one who churns out most features that wins. It doesn't' matter if the leaves the codebase in ruins. That someone's else's problem.
> The article describes how it should be.
Posts like this hit HN pretty regularly and are always popular, but they're essentially the equivalent of the perennial LinkedIn "I was already late for a job interview, but I stopped to help a stranded motorist change a flat tire, and then when I showed up for the interview, it turned out I was interviewing with the stranded motorist". For whatever reason, a lot of people seem to believe that if you post something often enough on the internet, you'll make it come true.
Re: One common behavior seen in “mature” software engineers
#70So 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 mocked and bullied by everybody.
He was also demoted for wasting time moving stones around when he was supposed to be peeling potatoes.