Live data from Hacker News

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

web.mit.edu

141–150 of 446 posts

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

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

Great approach! For the past 2 years I keep experimenting with different ways to track day to day productivity. It has helped me tremendously in assessing how I should feel at the end of the day about my work day and the amount of time I put towards work. (I tend to overwork myself significantly). It is of course a lot harder to apply this approach to individual productivity tracking across my teams. But I do now believe, based on self experiments and within smaller teams, that there is generally a lack of visibility of knowledge worker productivity. Especially within larger companies. WFH and hybrid makes this more crucial to have for both management and self assessments on the IC level.

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

#143
post #113

Earlier quoted context omitted.

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 s…

How bizarre. I guess I can count myself lucky that I don't seem to live in that particular world.

Is the problem the incentive itself, eg. if they didn't reward fixed bugs would you write better (even just better communicated) code?

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

#144
Went through this exact scenario at my job recently. As the tech lead/architect of an org I reviewed a bunch of recently released projects and identified areas that needed critical improvements because they had major reliability/performance issues. One team had multiple releases at the top of the list, and their PM and eng manager (and really everyone else up the chain) simply ignored all concerns because they had to prioritize feature updates instead.

Fast forward a few months – I was on vacation and shit blew up. There was a sev 1 escalation, several customers were pissed, the CEO/CTO were involved. The team in question – the same one that wrote the shoddy code and ignored all warnings bells – worked round the clock and got the service back up. Now they are heroes for their effort and the same manager I mentioned has a great reputation at the company for being so active and communicative and showcasing his leadership during the outage.

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

#145
post #69

Reminds me of this cartoon (which I have posted on my office): https://naksecurity.medium.com/the-detriments-of-hero-cultur... This is why in many corporate cultures it pays not to proactively stop a problem that you know how to fix if the problem is not in your immediate problem area. Let it be noticed, let it become someone else's emergency, then fix it. Much better path to a reward that way. Of course, you should…

I think that over time people realize who has a fire drill every month, and who quietly just gets things done.

I wouldn't be so sure. As an employee and team member, you'll be better perceived if you do your share of performative firefighting every one in a while. I wish it wasn't true, but it usually is. (Though at remote teams, it's less and less true, with the remote teams I was on, nobody really cared).

"wow, last week we had such nasty bug, impossible to track down, also caused production reliability issues. Tom stayed up all night, and finally pushed the fix at 3 in the morning."

Now, if you then say that it wouldn't have happened if 1. Tom didn't overcomplicate the system, 2. Tom learned our tools properly, 3. Tom actually understood the requirements and at least tested his changes at least once manually, 4. Wrote good code so that it's easy to troubleshoot 5. Wouldn't have forced a rushed PR review together with the product owner.

You'll just sound like a bitter, know it all.

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

#146

I tend to prefer working with people whose stuff "just works". I take that back. I strongly prefer working with them.

As a software engineer who pays more attention on security than average, I often feel my work didn't get recognized. For example, if I successfully prevented a supply chain attack, nobody would say thanks to me for a thing that didn't happen, even when they see a competitor product gets attacked. Similarly, most C/C++ programmers do not really care about integer overflow. But I know we are no longer in the world that computer viruses are everywhere(though ransomware are still common). The, who made it better? The people who are not satisfied with stuff that "just works".

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

#147

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…

I would call it "the hellhole that corporate performance assessment is turning into". Scrum is just a tool

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

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

Unfortunately one of the best ways is to toot your own horn. If you work with good folks, it will be appreciated for you to present a tricky problem you solved, or to present a design you put forth that would save everyone time.

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

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

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

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

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

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)

I don't do this for one reason - I cannot hold others to a high bar if most of my code is half-assed.

I usually write my best code to show others it's possible to write good code and ship on time, with exceptions of course (and I usually document in code why its half assed)

Post reply on HN