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."
Rob Pike: The Best Programming Advice I Ever Got.
21–30 of 142 posts
Re: Rob Pike: The Best Programming Advice I Ever Got.
#22A 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."
Same with the former French department store programmer who taught us Pascal in high school - punch cards have shaped that generation. That mindset still exists in industries with physical processes, but "measure twice, cut once" is wisdom lost to the desktop generation - experimenting can replace some thinking... But we certainly overestimate how much.
Re: Rob Pike: The Best Programming Advice I Ever Got.
#23That's why it's very hard to juggle multiple projects at the same time. Every time you switch projects, you have to flush the old mental models of the old project out and reload the mental models of the new project.
Same thing with interruption, it takes a while to rebuild the mental model after being interrupted.
Re: Rob Pike: The Best Programming Advice I Ever Got.
#24This is relevant: http://esr.ibiblio.org/?p=316
Also, I'm curious about something. Those of you who are good at building mentals models: are you also visual thinkers?
Re: Rob Pike: The Best Programming Advice I Ever Got.
#25You are only so smart. Once the complexity of the programming model reaches a certain point a debugger is necessary to validate and discover the true nature of a system. Often that point is quite low.
> Often that point is quite low.
I've found that liberal logging and careful error management has almost replaced the debugger entirely. In the last three months, I've only fired up the debugger twice, and that was when I was working with untyped memory and peeking at memory through the debugger was the most efficient way to get things done.
Re: Rob Pike: The Best Programming Advice I Ever Got.
#26Golden Advice.
Re: Rob Pike: The Best Programming Advice I Ever Got.
#27A 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 agree there's been an overall shift in styles, but instant-feedback aspects of programming also have a pretty long pedigree, in the form of Lisp's REPL.
Re: Rob Pike: The Best Programming Advice I Ever Got.
#28This 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 telling about this twelve years old boy "he fixes radios by thinking!".
Re: Rob Pike: The Best Programming Advice I Ever Got.
#29Earlier quoted context omitted.
Actually, I think it's a bit more subtle than that. By using stack traces and debuggers etc, I can come up with a working and correct solution. But, by thinking through the problem at a deeper level I can come up with an improved design which may simplify future programming and avoid similar bugs.
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.
Re: Rob Pike: The Best Programming Advice I Ever Got.
#30Thanks for the advice. I've always had a feeling that this was the right approach, yet I was usually too lazy to actually do it. Seeing Rob Pike coming to this conclusion is a good motivation. I've also noticed that the most persistent and hardest to solve bugs came either from logical errors in my mental model or its implementation.