Live data from Hacker News

Rob Pike: The Best Programming Advice I Ever Got.

informit.com

71–80 of 142 posts

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

#71
I wonder if building these mental models has become more difficult with the rise of multi-layered/full-featured programming frameworks. I'm thinking of things like Spring or Rails. A given webapp might involve a dozen layers or so: a database language (SQL), a database wrapper (Hibernate or ActiveRecord), a server side language, templating languages, client side languages (javascript), CSS, HTML, etc... etc...

Understanding all of that seems overwhelming. IOW, being a "full stack" generalist is getting harder, imho.

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

#72
At what point in a neophyte programmer's life should he/she switch from the "immediate & non-stop coding" Khan Academy approach recently discussed here on HN to this Ken Thompson "take a moment and think first" approach? Isn't there the danger that they might not be able or motivated to make the switch?

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

#73
post #8

You 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.

One should always try to write well modularized code with lots of good abstraction barriers so that you only ever have to have a fraction of the complexity of the system in your head at a time. If you had to understand everything down to the transistor level you could never even understand a Hello World program. That's because the language you use gives you good abstractions so you don't have to worry about linking, operating systems, memory allocation, etc. When writing complex systems you should strive to create such good abstractions yourself.

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

#74
This is great advice for when you're working on something that follows logical principles and guidelines. It's also great advice to follow when you're working on a green field project where you're allowed to work out the best place for certain pieces of logic to live.

However, when you're working on legacy systems or have to refactor some horrendous code written by developers many leagues out of their depth, and nothing whatsoever is in its logical place, it's less effective than in other circumstances. This sort of critical thinking is a wonderful tool to have; but just like any other tool, there's times when its use is appropriate, and times when it isn't.

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

#75

My co-worker does the same thing. Thinks instead of opening the debugger. In fact, he never uses a debugger even though he's a hardcore low-level C/C++ guy. Another important thing is to have good logs. Don't log too much, but log the most pertinent info. Next he just looks at the code. If it's really tough, he adds a print statement or two. I've never seen him do more in 3 years of working with him.

He says he might use a debugger depending on the type of application he's working with.

Also, there's something to be said for extremely tight, minimalist, highly reusable code. It makes it easier to walk through it in one's head.

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

#76
post #72

At what point in a neophyte programmer's life should he/she switch from the "immediate & non-stop coding" Khan Academy approach recently discussed here on HN to this Ken Thompson "take a moment and think first" approach? Isn't there the danger that they might not be able or motivated to make the switch?

It's important to see that these aren't mutually exclusive, even though they sound quite contrary. On the one hand you have the hack -- the one-off prototype thrown together simply to verify what can or can't be done. On the other hand you have the design -- once you know what perspective is best, to build the system from that perspective and validate that your intuitions are building one coherent whole.

Kay's Law is that the right perspective is worth 80 points of IQ: that is, if you find the right way to look at a problem, you can do things with the ease of someone with a 180 IQ who didn't have the advantage of that perspective. How do you get a good perspective? Well, there are a couple different ways. Some are pre-made perspectives: for example, dynamic programming: "let's just build up all the solutions in order from n=0, reduce everything to some other problem we've already built up." Some are intermediate, like wishful thinking: just imagine that magically, you have functions which you don't have, so that you write an algorithm which is correct, but references a bunch of functions which don't yet exist.

Some approaches to new perspectives are more general: hacking, for example, is when you try a bunch of things which just barely work, to find one which does. Another is duck solving: explain your problem out loud to an inanimate object (like a stuffed or rubber duck), and half the time you'll accidentally create a perspective purely for explaining the problem which is useful for solving it. These are very generally phrased because "problems" are a very general topic for intellectual discourse.

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

#77

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…

Me too. I used to really get frustrated when others couldn't see what I thought were obvious answers looking at a situation. Now I've come to sincerely believe there's something strange in me that allows me to see these things because when I've tried to take the Socratic method to get others to see what I see in various situations, I realize there are a lot of people who actually can't. Some people can get it via experience, but I've been able to do the same thing in areas or situations where I have zero experience (and now I'm talking about life, not just technical stuff).

I don't want to get on a high horse and say I have superpowers or something like that. But for some reason I'm able to do something that others can't, even though I think it's simply simple logic. It's sometimes a scary thing, because when I'm wrong, I have a difficult time figuring out why I'm wrong if someone else isn't able to do the same thing and "see" ahead.

Sometimes it seems to me that "seeing" is a better word than "thinking" here, because for the simpler things, it's not like I try to use brain cycles on the issues at hand.

And I hate saying this stuff, because it makes me sound arrogant when I know that I'm really incompetent at so many things.

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

#78

I wonder if building these mental models has become more difficult with the rise of multi-layered/full-featured programming frameworks. I'm thinking of things like Spring or Rails. A given webapp might involve a dozen layers or so: a database language (SQL), a database wrapper (Hibernate or ActiveRecord), a server side language, templating languages, client side languages (javascript), CSS, HTML, etc... etc... Unders…

> I wonder if building these mental models has become more difficult with the rise of multi-layered/full-featured programming frameworks.

I very much suspect this is one of the reasons that motivated Ken and Rob to create Go.

And see also Ken's comments about C++ at the recent Turing award winners celebration. ( http://amturing.acm.org/acm_tcc_webcasts.cfm )

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

#79

I wonder if building these mental models has become more difficult with the rise of multi-layered/full-featured programming frameworks. I'm thinking of things like Spring or Rails. A given webapp might involve a dozen layers or so: a database language (SQL), a database wrapper (Hibernate or ActiveRecord), a server side language, templating languages, client side languages (javascript), CSS, HTML, etc... etc... Unders…

I think the size and complexity of the program is the reason why we need to think first before we look at the code. I'll probably look at the obvious indicators (logs, stacktrace etc) and then the "thinking" could begin. Obviously with a huge program there are more probability for the local fix to happen because there are so many moving parts

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

#80
post #37

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.

I think you missed "coauthored Go..."

Not just that, he coauthored Go together with the coauthor of C.
Post reply on HN