Live data from Hacker News

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

web.mit.edu

251–260 of 446 posts

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

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

Other problem on similar spectrum, when you have a good performance and your boss notice you, their expectations can increase and increase until you unable to deliver, then suddenly you're bad.

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

#252

I thought this was going to be about Y2K, since it was written just after. I worked for years in the late 90's on Y2K projects, helping to stop the UK's critical infrastructure from just stopping at midnight. Wales would not have water or gas without our efforts, for example. But I've heard people since say things like "why did we spend all that money on Y2K, when it clearly wasn't a problem since nothing happened?"…

I know of several other issues like that. I myself made sure the highscore in a video game I was working on would work :-)

The thing that annoys me is that this is best case scenario when it comes to climate change. If we do in fact manage to avoid the apocalypse, all the "climate deniers" are going to feel vindicated.

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

#253
post #32

I always get cynical when I see awards for software releases. Someone always gets an award for staying up late to fix a last minute problem. Normally the person that should have written good code in the first place so they wouldn't have had to come in late. The award should go to the person (likely people) who never got called in at all in the first place because we didn't find a bug in their code.

You guys get awards?

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

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

Having a carefree life of no technical debt is not its own reward? Firefighting is stressful :)

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

#255
post #230

Earlier quoted context omitted.

Award everybody with a bonus that can be deducted with every bug report

Oh, maybe adversarial salaries. You each, meticulously, go through the others code, trying to find as many bugs as possible, in your spare time. Each bug you find transfers a percentage of their salary into yours. End result: everyone's code is perfect, and everyone hates each other. :D

Potential dual Ph.D in game theory / management.

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

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

This kind jaded, reductive answer reeks of sour grapes. I've seen so many adopt a transactional mentality as a sort of defense mechanism against the indifference of the universe, and in the process they unintentionally blind themselves to numerous daily examples of people just trying to do the right thing. Sure the world has problems, but if we can't see both the good and the bad then we become embittered and small,…

The key is learning to identify the situations where a transactional mentality is the rational thing to do to protect yourself.

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

#258

Earlier quoted context omitted.

And people who comment their code. Even if it is just a little. I swear, 90% of my time in coding is just fiddling around with functions to see what they do so that I can actually pull them together in the right way. If there was just a little documentation this would greatly reduce my time. It should also be in every team's and company's best interest because people hours are expensive. It should also be in the best…

Documentation exists in one of these states: 1. incomplete 2. wrong 3. missing My goal is to write code that is so clear it doesn't need documentation.

In your opinion/experience, does (or: would) a docs-as-code approach help ?

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

#259

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)

In high school I actually had a friend teach me this in a humorous way. In football we did sprints (the kind where you physically run) at the end. He said -- half ass the sprints. Then on the last sprint, run as fast as you can, you'll have more energy left, and when they see you running fastest you'll get all the credit. He was doing it as a joke, but lo and behold he out runs everyone on the last sprint by a lot, a…

Nice example for the (common?) inability of many managers to assess performance realistically.

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

#260

The opposite. Department heads get fired for allowing blow-ups in their area, that should have been avoided. "Getting credit" means keeping the job managing the department via preventing problems.

But then you need upper management that appreciates the "risk potential" of every area, and what is required to keep that risk at bay.
Post reply on HN