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…
Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
281–290 of 446 posts
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#282I'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.
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]
#283Earlier 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.
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#284Earlier 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.
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#285Earlier 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.
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#286I'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]
#287My 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…
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#288Earlier 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.
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#289Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#290Earlier 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)