Live data from Hacker News

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

web.mit.edu

381–390 of 446 posts

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

#381

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.

Please at least document the 'why' of the code. Anyone can spend an eternity on a codebase and figure out 'what' it does, but its very difficult to figure out the 'why' without someone explicitly telling you.

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

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

1. Donald Rumsfeld was right when he said “A’s hire A’s, B’s hire C’s”. 2. Environments where people can’t tell the difference between 1x and 1000x engineers lead to performative work and arsonist firefighting. 3. When folks in your organization can’t recognize (and reward) high impact, it’s probably time to get out, largely due to the first two points.

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

#383
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 lean mantra "Make work visible" is not only good at an organization level but also as professional feedback level. Although if used openly for promotions it will cease to be a good metric.

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

#384
post #373

Earlier quoted context omitted.

> No, someone writing something on 4chan does not imply it ever happened. Neither does it imply that it never happened.

You cant use it as an argument, just like you cant use a fiction book as an argument.

Parent post didn't cite it in an argument.

They shared a story.

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

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

I'm going to add: in a place where they have the bandwidth to be honest and intelligent. Sometimes good people are in bad situations. It's important to recognize this.

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

#386

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.

That hasn't been my experience. I don't get to choose who I work with, my days are stressful and unfulfilling, and my career has stagnated.

Sorry to hear this! At the risk of repeating what others in your life may have told you, have you considered working for a new team/company? I find it of utmost importance to find a job/career that is intrinsically fulfilling and rewarding to you. Extrinsic rewards like money are great, but you can only slog for so long for only money before you burn out.

I've personally been fortunate to have been able to form a network of a bunch of different well-connected folks so I can always choose who I get to work with in the event that companies shut down or get acquired or such and such. I feel the value of such a network does not get touted often enough.

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

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

Go into consulting.

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

#388

Earlier quoted context omitted.

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

> 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. Actually you should mention it in the documentation. There's 2 types of documentation, so it's easier to just do the one: documentation for users, documentation for developers. Unless you work absolutely alone o…

Why should the documentation repeat that a pointer to const cannot modify what it is pointing to?

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

#389

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.

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.

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

#390
post #302

Earlier quoted context omitted.

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.

Ok, it doesn't sound that bad to me? You learned something about consulting, got paid 1600$ for one hour work, got good recommendations and now have time for another interesting opportunity. Don't waste your time and clients money on pretending to do work that you don't. Its ethically wrong (maybe even criminal) and it sounds like you would be bored to death wasting your talent. Don't blame the company for not wastin…

It took 3 months to get this first contract, I was trying to break into a new space. Shortly afterwards the government gave many millions of grants to all my potential customers in the country to spend on consulting with a brand new company that was spun out of the government so the entire potential market dried up overnight. The customers didn’t care it was free money. This spinout then tried to hire me where they correctly pointed out that there is now no alternative to working with them and gave me a low ball offer. I left the country instead.
Post reply on HN