Live data from Hacker News

Rob Pike: The Best Programming Advice I Ever Got.

informit.com

31–40 of 142 posts

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

#31
post #7

Earlier quoted context omitted.

Your link is discussing the development of Unix, which was before Rob Pike came on the scene. Rob Pike is discussing an incident that happened a number of years later when Rob would have been significantly junior to Ken. There is no reason that both versions of history can't be true.

On top of that, things would have grown in complexity since the early days.

Don't kid yourself. Systems may be larger and seemingly more complex, the individual parts are as simple or complex as they ever were. Anyway, if things are more complex the necessity of thinking it through are even greater.

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

#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. =)

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

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

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

#38
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.
Post reply on HN