Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rob Pike: The Best Programming Advice I Ever Got.

informit.com

Post reply on HN
Print view View original

41–50 of 142 posts

Re: Rob Pike: The Best Programming Advice I Ever Got.

#41

Post by djtriptych »

rimantas wrote: post #28

This reminds me an episode in "Surely You're Joking, Mr. Feynman!" where he fixes a noisy radio just by trying to understand how can the problem happen and comes to conclusion that the most likely cause is that amp's vacuum tubes heat first and generate a lot of noise before the rest of the circuit is ready. He swaps tubes, problem is gone and the owner of the radio (which was very sceptical at first) goes around tel…

Thank you for re-re-re-reminding me to read that.

link for anyone else who's been meaning to read this: http://amzn.com/0393316041

Re: Rob Pike: The Best Programming Advice I Ever Got.

#42

Post by tluyben2 »

goblin89 wrote: post #32

I'd say beware the opposite as well. If you're ‘just a’ developer in a larger company, you may rarely get to actually fix these high-level problems you discover. You kind of have to live with it, which is frustrating. And if you're working alone, too ‘high-level’ thinking may well slow down getting things done. If you don't have around someone with more pragmatic attitude, be sure to have a bit of it yourself. =)

That's why most people 'here' are probably not 'just a dev' at a larger company. There is a lot frustrating about that position.

I agree with your second remark; you need pragmatism, but yes, as I get older I notice that I solve bugs in my head instead of debugging in the usual fashion. I strive to type as little as possible and to do that you need to do a lot of head work; 20 years ago, I was the opposite.

Re: Rob Pike: The Best Programming Advice I Ever Got.

#44

Post by guelo »

simonh wrote: post #29
guelo wrote: post #18

Earlier quoted context omitted.

But one must also be careful not to fall into the trap of premature optimizations and building unnecessary complexity.

You've just hit a real actual problem in the code. Factoring that out isn't premature, it's responding to reality.

I was reacting to the idea that instead of fixing the immediate bug you just found you're going to redesign the whole thing to prevent that type of bug from occurring ever again in the future.

Re: Rob Pike: The Best Programming Advice I Ever Got.

#45

Post by djtriptych »

philhippus wrote: post #35

Used to code in C...moved to work at Google Labs...now raves about Go being the most productive language EVARR and has replaced C...Hmmm.

After the ....Hmmmm should have been a thoughtful comparison of the two languages.

....Unless maybe you understand implicitly that you're probably not as smart as Rob Pike.

Re: Rob Pike: The Best Programming Advice I Ever Got.

#46

Post by sreyaNotfilc »

rimantas wrote: post #28

This reminds me an episode in "Surely You're Joking, Mr. Feynman!" where he fixes a noisy radio just by trying to understand how can the problem happen and comes to conclusion that the most likely cause is that amp's vacuum tubes heat first and generate a lot of noise before the rest of the circuit is ready. He swaps tubes, problem is gone and the owner of the radio (which was very sceptical at first) goes around tel…

The power of thought is strange. I happen to have this ability as well. That's mainly why I'm still employed.

A couple of years ago, we originally had a 4 man team. 3 of those guys left, leaving me (the junior dev) to deal with the whole platform.

I didn't have any time for error, but I didn't know a darn thing. I did, however, had the ability of the "hunch". Basically, when a problem happened, instead of opening the text editor and looking for the problem, I just stood back and thought about it. I'm not sure what I'm thinking about. Its strange. Its like my brain just traverses through the infrastructure and comes up with the LOGICAL solution. Once I get that answer, I then go look at the code base. 99% of the time, its my hunch that finds the problem.

I amaze myself all the times with this. To me its just logic, but I'm sure its something more. I'll probably never figure it out, but that's not to my detriment.

This also helps with writing new applications, because you already know what will work and what won't before you get there. Its, craziness!!

Re: Rob Pike: The Best Programming Advice I Ever Got.

#47

Post by krenoten »

leke wrote: post #33
gklitt wrote: post #21

A professor of mine who worked at Bell Labs once made the same point. "In the old days we had to think a lot about how our punch card program worked because we'd only find out if it worked the next day. Nowadays you guys just throw crap at the wall and see what sticks. Find the middle ground."

I thought thinking in code was how every programmer worked. So people usually write code like they write words?

Well, it's not uncommon for code to be blurted out without first thinking about the implications - to similarly embarrassing effect.

Re: Rob Pike: The Best Programming Advice I Ever Got.

#48

Post by nekopa »

This reminds of of two things:

Toyota's '5 Whys' root cause analysis, don't just fix the manifestation of the problem, but keep asking why it happened until you get to the real cause.

The NASA space shuttle programmers

http://www.fastcompany.com/28121/they-write-right-stuff

When they find a bug, they go to great lengths to find how and where in their process of programming this was able to happen, sometimes finding other bugs before they surface.

Re: Rob Pike: The Best Programming Advice I Ever Got.

#50

Post by bguthrie »

mseebach wrote: post #38
gklitt wrote: post #21

A professor of mine who worked at Bell Labs once made the same point. "In the old days we had to think a lot about how our punch card program worked because we'd only find out if it worked the next day. Nowadays you guys just throw crap at the wall and see what sticks. Find the middle ground."

That's one of the less obvious (to me, at least) benefits of test driven development: When you're writing out your unit test, you're forced to think about how the implementation is going to work.

I had the opposite reaction: I wonder if tests make it easier for you to fix code without forcing you to develop a mental model of it, assuming you're working in an unfamiliar codebase. That seems like something of a hidden drawback.
Post reply on HN