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

401–410 of 446 posts

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

#401

Post by ozim »

UK-AL wrote: post #328
ozim wrote: post #261

Earlier quoted context omitted.

That is naive take, you really think if you work hard on improving code, pointing out flaws, there will never be any issues? In reality that I live, there is never enough time, if you have 3-4 team mates pumping features out, it is already impossible to prevent every problem and review every piece of code. I don't have to be cynical about it, it just happens that issues will crop up over time and I am there to fix th…

We have a very good test suite, I don't think there's been a bad release in years.

We also don’t have bad releases but we had a new customer that added 100 users that used specific workflow that was working for years for other customers.

Those 100 users took performance to a crawl but we never seen it earlier because it was never used that way in that capacity.

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

#402

Post by godelski »

WalterBright wrote: post #388
godelski wrote: post #322

Earlier quoted context omitted.

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

> Why should the documentation

>> someone else is going to be reading your code.

Someone else is going to {read,edit,write,maintain} your code. Which means __anything__ the code does should be explained. Before you were suggesting documentation is only for the user. Documentation is also important for the developer. Whoever takes over your code later or works on it with you.

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

#403

Post by godelski »

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 document as I code all the time. It is immensely helpful. As I write the signature I add a few lines saying what the function will do and often it results in me slightly modifying the function because I realize a better way.

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

#404

Post by grozmovoi »

watwut wrote: post #362
epolanski wrote: post #164

Earlier quoted context omitted.

There's a famous green text on 4chan, where a user tells he got a sysadmin job which was so boring he started crashing stuff left and right and blocking an entire office even for entire days. By the end of the day he would plug back something and come out the "servers room" saying he fixed that and get everybody's praise. Even got him two raises in the span of 18 months. That's how crazy it is. I know a variation of…

I do not think you can trust everything you find on 4chan. Yes, dysfunctional companies exists. No, someone writing something on 4chan does not imply it ever happened.

what about someone claiming it was written on 4chan, but it was actually made up for hn. smh can't trust anyone

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

#405

Post by indigochill »

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.

> When I work there the whole time, and nobody ever gets stuck for 3 months, my value is unclear.

Well, a problem that hasn't happened yet is a risk, right? So you can apply risk assessment math to it:

Value = Estimated risk of the problem occurring * Cost if it happens

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

#406

Post by svachalek »

IshKebab wrote: post #350
contact9879 wrote: post #89

Earlier quoted context omitted.

Now they do at least

They did then as well. I remember before 2000 people saying it wasn't going to be a big issue due to this.

"Most" programs used epoch time, like video games. The minority that didn't were the big, stable, old programs that ran on big computers. Things like payroll and flight schedules.

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

#407

Post by wolverine876 »

harimau777 wrote: post #355
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.

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.

Not everyone has that option, as you say. My career was in a similar dead-end situation at one point; there was no immediate solution - nothing was going to make tomorrow or next month better than today.

Finally, I accepted the solution was long-term. I made a long-term plan - to do what I really loved - and focused my attention on that, and slowly built up the resources, skills, etc. for that plan. One wonderful side effect was that the dead-end part diminished in my mind; sure, I still had to do it, it still sucked and there were some awful days, but it would pass. I didn't matter so much; those people didn't matter; it was like one of those movies where the kid knows that someday they will leave the depressing, dead-end town they are stuck in today.

I hope that helps a little in your situation! Good luck!

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

#408

Post by wolverine876 »

antihipocrat wrote: post #167
epolanski wrote: post #157

Earlier quoted context omitted.

Intelligent people will see that you solved issues before they even happened. So in small teams where visibility is clear those things are obvious. It's in larger orgs where you want to climb the ladder that you get bonus points for the problems fixed but not those you prevented.

Intelligent people are in larger orgs too. They learn very quickly that promotions aren't tied to effort and anticipating problems or resolving future problems. The intelligent, optimistic and genuinely good, helpful people who don't learn this (or refuse to compromise their good nature) end up burning out, getting performance managed or with PTSD

Right, don't work in that org. Find the org with more of the intelligent, optimistic and genuinely good, helpful people.

Some people don't want to give up the job at High Status High Pay Corp. That's the trade-off they are choosing. (Not every HSHP Corp. has to be a bad place to work, however.)

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

#409

Post by wbsun »

I work on a large distributed infrastructure. I always joked that my team's projects and people's careers are outage-driven: the only time we become important and people get opportunities for promotion is when where were big-enough outages that executives have to invest heavily on reliability or scalability. Other time, we are just minions who must listen to and serve feature or product teams. Nobody listen to us when we ask a product team to implement a reliability contract in their shining product.

Pre-outage improvements, reliability defense in depth, eliminated scalability bottlenecks before they are hit, are all ignored by leadership and the company: it is just human nature that even though they understand you have to prepare for possible issues, if it hasn't happen yet, you won't take it seriously. I've seen this in many internal performance reviews and promotion committees. People who haven't ever got bitten badly by an outage may call these premature optimizations.

Post reply on HN