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

241–250 of 446 posts

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

#241

Post by cced »

cjbgkagh wrote: post #218
damianh wrote: post #156

Earlier quoted context omitted.

The trick is to do these sort of engagements as a fixed price contract. You could have probably done an assessment in a hour or two. Then you charge on what you estimate is the value to the company.

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.

How much was it costing them?

Also, can you describe the problem? It sounds interesting.

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

#242

Post by jmchuster »

gumby wrote: post #8
ghaff wrote: post #3

In about that same timeframe, Y2K is also really good example. Nothing of note really happened. But if people had just ignored it a lot of things probably would have.

This is a very important case. There was an enormous investment in fixing Y2K, starting long before the day in question (e.g. financial instruments with expiration dates after Y2K had to be fixed before they became due), so on the day there was only a smattering of minor residual bugs. There were a few jokes about it in the newspapers but by and large the public just ignored it. I work on climate and hope / hoped tha…

On climate change, it already did work once with the hole in the ozone layer.

People ask why they don't hear about it anymore -- oh, it's because we listened and banned CFCs and fixed the hole.

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

#243

Post by johnnyanmac »

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.

Security/insurance paradox: when you do some jobs perfectly, it feels like you're doing nothing. Sadly, the only (ethical) way to counter such narrative is to spend a good amount of your time making reports showing how well everything is working and how it's not something you can just operate autonomously without disaster (to answer the inevitable "well the job is done, what are we paying you for?)

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

#244

Post by johnnyanmac »

cjbgkagh wrote: post #218
damianh wrote: post #156

Earlier quoted context omitted.

The trick is to do these sort of engagements as a fixed price contract. You could have probably done an assessment in a hour or two. Then you charge on what you estimate is the value to the company.

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]

#245

Post by johnnyanmac »

s-lambert wrote: post #177
epolanski wrote: post #166

Earlier quoted context omitted.

I always laughed about those X points targets. In the end people ended up simply inflating the value of stories. In my previous team I had to argue with a person that 2 story points to add translation keys were ridiculous. To which the EM argued that 2 was okay because he also needed to write few accompanying tests. I have nightmares thinking about this stuff. It was literally quicker to add the translation keys and…

Company has a goal for 5% increased velocity, what they want: teams get more efficient at pushing stories through to completion, what they get: teams just estimate 5% higher.

Goodheart strikes again.

And large companies will probably never learn, because at some critical mass it becomes less important to ship than it does to tell people how cool the product you want to ship is. Devs don't get paid for shipping outside of a short surge of stocks (which they proceed to not be able to take advantadge of because potential insider trading). Heck, some industries just let you go after you ship.

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

#246

Post by WalterBright »

Panzer04 wrote: post #238
WalterBright wrote: post #219

Earlier quoted context omitted.

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.

Some functions are doing jobs well-defined enough that this is sufficient, but there's plenty that aren't and do deserve additional explanation. I don't want to read the code of your function to figure out what its doing. I want to read the function signature, and if that's not clear enough a comment explaining its purpose and parameters. Code explains how it does something, but often does not clearly explain what th…

I don't expect to attain it, which is why I remarked on it as a goal. I've discovered that a lot can be done to eliminate the need for some forms of documentation. Also a lot can be done with the language to make it more expressive, and thus eliminating the need to document something.

For example, having the parameter to a function declared `const` means the function cannot alter it, and this is checked by the compiler. It won't be necessary to mention that in the function documentation.

P.S. This doesn't work in C and C++, despite them having a `const` type qualifier. This is because the `const` is not transitive, and can be legitimately cast away. Therefore, it's useless as a guarantee. D's `const` is transitive, and although you can cast it away in @system code, you're on your own with that.

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

#247

Post by dr_kiszonka »

marviel wrote: post #224
thret wrote: post #194

Earlier quoted context omitted.

Self-promotion is incredibly difficult for some people.

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]

#248

Post by euroderf »

atleastoptimal wrote: post #75
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.

The solution is to be a shameless self-marketer of all the work you do.

This does seem like the antithesis of useful, productive engineering work.

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

#249

Post by euroderf »

mixmastamyk wrote: post #151
paxys wrote: post #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…

Well, you could dust off the old email and 'mistakenly' send it again. Though it will seem petty, a small fraction might rethink the past few months.

It might be better to keep it low-profile. Go to a superior with the story of "told ya so".

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

#250

Post by puchatek »

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.

An adjacent problem is how to know that you've really prevented issues/others from getting stuck with whatever you were working on. No system is perfect and engineering is also an art of knowing when to skip which corners. If nobody sees value in your preventive work then maybe there isn't any?
Post reply on HN