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

321–330 of 446 posts

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

#321

Post by godelski »

WalterBright wrote: post #219
godelski wrote: post #136

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.

> 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

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

#322

Post by godelski »

WalterBright wrote: post #246
Panzer04 wrote: post #238

Earlier quoted context omitted.

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 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 on all your projects and you don't open source them, someone else is going to be reading your code.

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

#323

Post by darkwater »

hresvelgr wrote: post #240
jqcoffey wrote: post #190

Earlier quoted context omitted.

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

> 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. There's nothing wrong with elitism as long as it leads to initiation rather than gatekeeping. > My god how I’ve found that working with reasonable people is so much healthier. Could not agree more. Most people can be trained well to do any job required of them. What cannot be tr…

> What cannot be trained, and certainly at the behest of the employer is interpersonal skills.

I think that those can be trained as well. The fact is that just acknowledging the issue requires a level of self-awareness that not everyone has, and training THAT as well requires being aware of it. External input and help from a specialist or a dear friend can get the ball rolling.

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

#324

Post by scioto »

WalterBright wrote: post #133
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)

Maybe I'm the only one who notices people whose work "just works". Those people are solid gold.

Well, if it "just works," then it wasn't that hard to do anyway. No raise for you.

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

#325

Post by tempaway11722 »

IshKebab wrote: post #81
reaperducer wrote: post #79

Nobody ever gets credit for fixing problems that never happened (2001) [pdf] I'm reminded of this every time I see some YouTuber or other social media click bait claiming that the Y2K bug was no big deal. The reason it was no big deal is because thousands of graybeards, like myself, stayed up many long nights for months ahead of time making sure things would work. I still remember the tension during the countdown to…

I still don't quite buy that. Surely it's because computers mostly use epoch time for dates, not dd/mm/yy? Guess we'll find out in 2038.

It was also to do with how dates were stored in very old databases that were conceived in the 70s when storage was at a premium - a lot of them just used two digits for year.

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

#327

Post by necrotic_comp »

zmgsabst wrote: post #181
ponector wrote: post #80

Earlier quoted context omitted.

It is more easy: do your job right, but do not comment, fix or somehow improve work of your colleagues. Let them fail, aknowledge failure and only then come with fix, get all praise. Never point to the possible issues at the code reviews, retirement refinements etc.

This, but seriously: Let your junior colleagues fail on a schedule within the margin of error on your planning, but keep a close enough eye on them so you know how to bail it out if they can’t pull it together with a little extra time/guidance. Okay — still give good code reviews, but if you let them face-plant a little on design, etc, then they get experience. And you don’t look dumb when it turns out they were righ…

This is also just good practice in general. You learn through struggle, so giving juniors a safety net (when they don't know they have it), is a good way to get them up the curve.

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

#328

Post by UK-AL »

ozim wrote: post #261
ponector wrote: post #80

Earlier quoted context omitted.

It is more easy: do your job right, but do not comment, fix or somehow improve work of your colleagues. Let them fail, aknowledge failure and only then come with fix, get all praise. Never point to the possible issues at the code reviews, retirement refinements etc.

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.

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

#329

Post by euroderf »

atleastoptimal wrote: post #297
euroderf wrote: post #248

Earlier quoted context omitted.

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

Even spending 5% of your time self marketing has massive dividends on your career vs spending 0% of your time. The virtues of your skills aren't self evident.

True. But when you're a smart kid and you get auto-noticed in school with no effort on your own part (aside from the academic effort!), maybe it's time to add a course like "Creating Your Own P.R... And Believing It Too" into the curriculum.
Post reply on HN