Live data from Hacker News

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

web.mit.edu

281–290 of 446 posts

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

#281
post #86

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.

> 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. I've heard this called "institutional scarring" in a blog post somewhere. The idea is a small wound can be replaced with tough inflexible tissue. The jist of the blog post was that just because something happened, doesn't mean you have…

Same thing constantly happens in governments, too. "Oh no, something that's been done for 200 years now caused issues once! We have to restrict/regulate/bureaucratize/outlaw it immadiately!"

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

#282
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.

It's possible to phrase the value proposition to align with what you want to deliver.

You can phrase it as "I help teams deliver on time by making sure they don't get stuck." Or "I increase a team's velocity by preventing mistakes that stop work."

It's how you sell yourself and then, how you tell the story of what happened. Being able to tell a compelling story is important.

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

#283

Earlier quoted context omitted.

I should have, but it would have been obvious that I pulled a fast one on them as the fix was really quite simple. Instead of building a Hadoop cluster I replace a sql sub query with a bitmask. It really only took an hour to figure it out but they let me charge the whole day.

>but it would have been obvious that I pulled a fast one on them as the fix was really quite simple. If they were ready to have you on for 6 months, You'd still probably be one of the most honest contractors if you stretched that out to a week, or even month. It's a shame honestly isn't always rewarded proportionately to suggesting an entire rework of their infrastructure.

I really did think they’d have more work for me.

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

#284

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)

Having people thank me for being 'on top of' a problem that I already know about because I'm the one who pushed the button that broke it... It's gross. It feels gross. Much happier when I can fix something quickly because I have some tools or logic in the codebase already that lets me do something quickly by being covered with sanity checks so I can zip along without driving us off a cliff.

There's some people who break something, realize it, just leave it as is, and cannot comprehend why you would think they should maybe help fix it... So I'd guess the praise is for not being like that.

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

#285

Earlier quoted context omitted.

fair, but it's better to point out the solution: "learn how to be better at self promotion" Do you have another solution to this issue?

Find someone to champion your work. Also, if you aren't already, start praising others' work in the hopes that they will reciprocate.

The caveat to this is to make sure hope doesn't turn into expectation. Expectation can turn into sourness when the others don't reciprocate. Also, some people feel when you do something just because you expect something in exchange, and that tends to make them not reciprocate.

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

#286
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.

It's possible to phrase the value proposition to align with what you want to deliver. You can phrase it as "I help teams deliver on time by making sure they don't get stuck." Or "I increase a team's velocity by preventing mistakes that stop work." It's how you sell yourself and then, how you tell the story of what happened. Being able to tell a compelling story is important.

The issue is how do you provide the evidence for that. In other terms, how do you differentiate your effect from that of Homer Simpson's Bear Patrol and Lisa's tiger-repellant rock [0]?

[0] https://www.youtube.com/watch?v=xSVqLHghLpw

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

#287

My memory is a bit hazy but it's a good story. At one place, there was some important order processing taking place. As is fairly typical, couldn't rely on getting all the required info. Or critically, getting all the required info correctly . Some extra data, slightly missing pieces but enough to work, etc. etc. Some could be pretty gross. We built validation to massage some inputs, modify processing, what have you…

There is a simple but undeniable element of genius to the idea of, instrumenting the number of validations triggered. I would hazard a guess that 90+% of teams would focus on an "order success rate" type of metric and call it a day, instead of a "# of times bad data was handled" metric, which is exactly how you escape this trap of good work going unnoticed. Thanks for sharing! Shamelessly stealing and applying this c…

Yeah. Another way I would put it is to also look at inputs that strayed off the happy path. There may be something to learn from them as well, maybe something that adjusts the happy path.

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

#288
post #149

Earlier quoted context omitted.

> your days will be much better and the odds will be with you. In the context of one's effort valuation it seem to be a very bad advice. Unfortunately.

Intelligent people will see that you solved issues before they even happened. So in small teams where visibility is clear those things are obvious. It's in larger orgs where you want to climb the ladder that you get bonus points for the problems fixed but not those you prevented.

You can have intelligent people in the largest orgs, if they are good at hiring. You can have inexperienced people in small teams or companies, and it happens often.

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

#289
FTFY: nobody ever gets credit if they don't publicize their successes. By default, fixing problems before they happen doesn't make headlines, so you have to find clever ways to earn publicity. One politician classic: let it become a "problem" enough to earn publicity, THEN fix it. Two examples: Y2K and Healthcare.gov

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

#290

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 even need to half a$$ it, just use timebombs. https://en.wikipedia.org/wiki/Time_bomb_(software) Usually only works if you're the only dev, unless you get creative with counters like the original devs that made some nice cash fixing it all for y2k (officially: don't do this)

The AI will analyze your codebase next year and the company will sue you if you do stuff like that...
Post reply on HN