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

391–400 of 446 posts

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

#391

Post by AlbertCory »

dhruvkb wrote: post #345
AlbertCory wrote: post #160

Suppose on Sept.10, 2001, you were an airline executive who successfully forced installation of jimmy-proof, secure steel doors between the cockpit and the cabin? The only "credit" you'd get is "This guy cost the airlines god-know-how-much money, and for what? An imaginary threat!"

The book "The Black Swan" by Nassim Nicholas Taleb contains this very example. It is a great read on why the improbable events have the biggest impact.

which is where I got it (forget the attribution, though, but the name "Taleb" seems to trigger some people).

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

#392

Post by WalterBright »

godelski wrote: post #321
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.

> My goal is to write code that is so clear it doesn't need documentation. I hear this so often but I think it is an excuse. Those 3 points are also true about your code. > There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors

> Those 3 points are also true about your code.

The difference is there are things the compiler can verify to be correct.

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

#393

Post by euroderf »

WalterBright wrote: post #389
euroderf wrote: post #258

Earlier quoted context omitted.

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

Docs-as-code will never work, as human languages are way too mushy and imprecise. That's why we have programming languages.

I think you miss the point. Docs-as-code says keep the docs where the code is, and manage the docs like you manage code, using tools like git. Mostly(?) to reduce friction for software developers to actually contribute useful documentation.

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

#394

Post by toss1 »

jqcoffey wrote: post #190
wolverine876 wrote: post #45

Earlier quoted context omitted.

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.

> Work with honest, intelligent people This is good advice that’s well intentioned, but (sorry), it can be interpreted as elitist, and in a way that’s detrimental to the reader. I am no way suggesting that this is the intention or belief of the parent, but while I’ve got more miles on my odometer than I’d prefer, they’ve informed me that “reasonable” is better than “intelligent.” My god how I’ve found that working wi…

I think [reasonable] falls under the heading of [honest].

Both honesty/reasonableness and intelligence are required. A family memebr is tearing her hair out about having to work with some assistants who are honest, well-intentioned, and pleasant, but who are just mentally incapable of keeping things straight — they literally screw things up and make more disorganization than they fix (fortunately, better help is supposedly on the way).

Overall, in hiring and working with people, most of the time, a warm body is definitely NOT better than nobody.

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

#395

Post by mixmastamyk »

Xcelerate wrote: post #331
mixmastamyk wrote: post #151

Earlier quoted context omitted.

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.

I’ve started doing something like this more frequently, but it is in the interest of job security / cover-my-butt rather than pettiness. I build something that depends on many systems that others have created and that uses data from probably about every dataset we have. What I build also has very high customer visibility. So whenever something breaks upstream, the first place customers notice the problem is in the sy…

Not petty at all... pretty smart imho. Does the metaphorical front-end catch back-end errors with a warning and link to the issue? That would light fires under asses. :-D

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

#398

Post by phone8675309 »

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.

Even with this I would argue that fixed cost would have been the way to go. They were losing $X every day for that six months that it wasn't working. They hired you to fix it, and even if you charge them way more than your day rate you're not solely charging them for the change - you're charging them for "knowing which screw to turn".

The hardest part of getting into contracting was the guilt of feeling "I'm charging too much for a simple fix!". If the fix was so simple and the client didn't find it in those six months then maybe your assumption that the fix was simple and obvious was incorrect. Regardless, your fix provided value, and you should be compensated for the value that you provided, not just the number of hours worked.

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

#399

Post by begueradj »

fifilura wrote: post #356
begueradj wrote: post #347

Earlier quoted context omitted.

But most of the time you can not chose with whom to work

Then you just have to refer to the Karma bucket. "In my/their next life..."

haha :) you are funny :)

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

#400

Post by ajmurmann »

vasco wrote: post #337
guappa wrote: post #334

Earlier quoted context omitted.

I've seen management let bad engineers re-do projects from scratch 2 or 3 times. Because they blame bad requirements, poor choice of programming language, and whatever on all the issues that the project has. They eventually acquire enough experience to be able to produce something that sort-of works around the 3rd attempt. But thanks to how good they are at communicating, are considered by management to be good engin…

I mean at some point we just get generic enough that we have to agree on the ultimate fact that at least somewhere in the management chain someone has to actually know enough engineering to recognize good work from just running around in circles. I agree what you say happens but if good work isn't consistently recognized and you think you've worked on your comms, there's not much else to do really.

> at least somewhere in the management chain someone has to actually know enough engineering to recognize good work from just running around in circles

Unfortunately, this can cut the other way as well where you can have someone incompetent override competence or not even involved people further down which is common during large layoffs

Post reply on HN