Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

web.mit.edu

Post reply on HN
Print view View original

121–130 of 446 posts

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

#121

Post by hinkley »

runamuck wrote: post #29
hakunin wrote: 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)

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]

#122

Post by cloverich »

runamuck wrote: post #29
hakunin wrote: 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)

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, and the coach specifically pulls him aside as an example of how everyone else should carry themselves.

He's one of my favorite pranksters. But needless to say, the football team was not very good.

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

#124

Post by somethoughts »

cutemonster wrote: post #70
somethoughts wrote: post #52

Earlier quoted context omitted.

One approach to showing value is as follows: 1.) Create a spreadsheet with all of the features of your group's/company's products(s) listed in rows. 2.) Create a column for every team member in the group and highlight the lead developers for each feature. 3.) Then ask each team member to add a checkmark in their column for every feature for which they would be willing to be on hook for 24x7 triage pager duty. Over th…

Couldn't there then be a risk that now some people want to avoid higher risk projects, and just build the simpler features, and get more checkmarks What if the table in fact shows which people are best at dodging the hard work Combined with showing who has the most friends in the office (giving checkmarks to features built by one's friends)

Agree that there is probably room for improvement to such a process and still a great amount of subjectivity required and a presumption of good faith participants who aren't actively gaming the numbers.

In general though even if some developers are gravitating to only projects that are simple/trivial, those wouldn't necessarily be differentiators because such projects would have checkmarks by other developers as well.

Also it can help to have the Product Management team rank the features in terms of strategic importance and criticality to the functioning of the company.

I'd say the biggest benefit of such a spreadsheet is to provide visibility to leadership about the bus factor of the team. Too often the critical projects are really only maintained by a few team members. There's no incentive for new team members to learn the "legacy" projects versus creating their own pet projec. Then the inevitable RIF or transition happens and the lack of long term support becomes an issue.

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

#126

Post by [deleted] »

tomrod wrote: post #111
Jtsummers wrote: post #36

Earlier quoted context omitted.

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!

[deleted]

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

#128

Post by legitster »

dheera wrote: post #120
legitster wrote: post #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 push…

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

I believe it's actually a rugby term, and the idea is to wrestle things across the line at a regular cadence as a team.

The unit of work is even called a sprint because the idea is specifically to commit to very intense units of work.

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

#129

Post by hinkley »

godelski wrote: post #83
runamuck wrote: post #29

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)

I don't think you're wrong, but god what a waste of time. Can't we just fix the actual problem?

One middle ground I've found is to write tools or processes for myself or a mentee, with the intention to avoid avoidable problems. And then use the next time someone breaks things as an opportunity to advertise the preventative measure.

Frequently I end up having to do one more PR to get the tool to correct the exact problem the team experienced, so in practical terms is much less of a 'witholding' and more of a 'burning in' situation. But the final product does end up getting written in hours instead of days so while I don't get the credit I feel entitled to for foresight, I get mis-attributed with being able to solve difficult problems quickly.

Which is kinda true. I hate being caught flat footed so I'm always squirreling away fragments of a Plan C.

Post reply on HN