Live data from Hacker News

Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

web.mit.edu

111–120 of 446 posts

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#111

Earlier quoted context omitted.

Easy - half a$$ your code and when it breaks - swoop in, "fix things" (actually do it right) and play the role of hero! (I've seen so-called "Rock Stars" at places I worked do this over and over)

Don't do it right, double down on the flaws. You had a 3k SLOC single function (all in main) C program to do something that could be expressed cleanly and clearly in 200 SLOC. Some specific sequence of inputs leads to an error. Instead of tidying it up, removing the repetition that led to the mistake, you copy/paste everything again and add another 100 cases to your various switch/case statements (actually you use if…

Ah, I see, the legacy RDBMS developer approach!

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#112

Another variation on the problem is the over-allocation of resources to preventing problems which actually happened once, versus those that are more severe but haven't happened yet. This is a management problem, because no-one wants to be accountable for a repeat incident even if it was rational to be working on something else more important.

This is basically how all bureaucracy comes about. In startups everything is so new that problems haven't had time to happen. In big tech, because they have a tremendous knowledge base of previous incidents and the resulting safeguards, every single step seems mired in bureaucracy.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#113

Earlier quoted context omitted.

Easy - half a$$ your code and when it breaks - swoop in, "fix things" (actually do it right) and play the role of hero! (I've seen so-called "Rock Stars" at places I worked do this over and over)

Would you feel good about being that kind of engineer, if the external validation was great enough?

We review each other's code before it goes in. If the team says they're happy to work with it, then I've fulfilled my obligation. I am literally not paid to write the best code in the world. In fact, the company gives bonuses for fixing things, so they are in fact paying me to sneak bugs in.

What you do though is, you leave a very obscure edge case unhandled, make note of it, then just don't tell anyone. Invariably someone will hit it exactly one day before you're scheduled to go live. Then just apply the fix (make sure to procrastinate long enough to simulate working on it) and voila! The longest I've seen an edge case go unfixed in this manner has been three years.

Though truth be told I'm not smart enough to add bugs on purpose, I just sometimes notice I've failed to address an edge case and ... leave it. If it turns out to be important - I can fix it when the fix's value is maximum. Half my day is spent fixing others' unhandled edge cases, so it's nice to have one tucked away for a rainy day that you know you can fix easily.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#114
Take a leaf from the OH&S book, as OH&S is all about stopping things from happening. Many work places have a huge "Days Since Last Lost Time Accident" sign hanging out the front. It increments every day and the aim is to get it as high as possible.

The same metric could be applied to "Days Since Last Stuff Up That Cost Us". It would be easy thing to apply to an office door or cubicle wall.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#115
post #27

I've been contemplating the issue in the headline, as pertains to my value. When I help somebody in 40 mins with something they've been stuck on for 3 months, my value is clear to everyone. When I work there the whole time, and nobody ever gets stuck for 3 months, my value is unclear. Don't know how to deal with this paradox.

Life and its rewards aren't perfect. Work with honest, intelligent people; genuinely do your best; your days will be much better and the odds will be with you.

reality feels like there is a mix of people with different motivations. I think the paradox exist because the odds are not clear

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#116
post #27

I've been contemplating the issue in the headline, as pertains to my value. When I help somebody in 40 mins with something they've been stuck on for 3 months, my value is clear to everyone. When I work there the whole time, and nobody ever gets stuck for 3 months, my value is unclear. Don't know how to deal with this paradox.

Life and its rewards aren't perfect. Work with honest, intelligent people; genuinely do your best; your days will be much better and the odds will be with you.

This is a great answer. The only thing I would add is that you can take mental note when you accomplish something that anticipates and preempts future needs and challenges. It is ok to make brief mention of these things from time to time when appropriate. If nothing more it helps coworkers and bosses realize that you are putting in some thought and effort for the needs of others and to make things go more smoothly behind the scenes.

Doing this effectively requires tact. Try to mostly bring up your silent efforts casually, and be judicious about how often and in what situation you mention it. If it gets interpreted as an "I told you so," an excuse, self-importance, etc, then it will probably do more harm than good in terms of your standing with others.

Might be helpful to some degree. But won't save you if your organization's culture simply doesn't value your work or more generally doesn't care about proactive, methodical improvements that have no flash or immediate payoff.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#117
This is wonderful description of the kind of hellhole corporate Scrum is turning into.

Agile was literally about doing things quickly and quick cycles of capability improvement. But Scrum is a worse version of the planning processes it meant to replace!

If anything, the way scrum lays out the work into immediate problems exacerbates the cycle. In the long run it just turns into a ticketing system where fires get pushed up and technical debt gets pushed down.

It even spits out a super easy-to-track, meaningless set of efficiency numbers for consultants/executives to min-max!

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#118
This is something that really annoyed me at a company I worked at for a while. And it was far worse - it wasn't a case of not being rewarded, people who planned properly and got the job done were punished for their efforts. If a project got behind they would take people from a project that was on track or better to put them on to it. I pleaded for a super green status for the best projects on the basis that the team would finish sooner and then the entire team could work on something else nnd get it done well too. They could take people from the next tier but that would be an incentive to do well. Not a hope.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#119
post #27

I've been contemplating the issue in the headline, as pertains to my value. When I help somebody in 40 mins with something they've been stuck on for 3 months, my value is clear to everyone. When I work there the whole time, and nobody ever gets stuck for 3 months, my value is unclear. Don't know how to deal with this paradox.

The problem with doing something right the first time is nobody appreciates how hard it was.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#120

This is wonderful description of the kind of hellhole corporate Scrum is turning into. Agile was literally about doing things quickly and quick cycles of capability improvement. But Scrum is a worse version of the planning processes it meant to replace! If anything, the way scrum lays out the work into immediate problems exacerbates the cycle. In the long run it just turns into a ticketing system where fires get push…

> Scrum

I always thought this just meant to scrumble every week to get things done with a weekly standup?

Post reply on HN