12 ms·

Rob Pike: The Best Programming Advice I Ever Got.

427 points by chanux 14y ago

BruceIV 14y ago
Good advice - after I noticed that I solved most of my tough debugging problems on the walk home from work, I started going outside to take a walk around the building whenever I got stuck. Removing yourself from immediate access to the code lets you think at a higher level how it's organized and what could go wrong.
SonicSoul 14y ago
i've recently had to deal with similar situation, accept the person that refactored my code didn't make such a big improvement. instead he went on vacation and a lot of things broke when we released the code. even though i've looked at all his check-ins, and they looked harmless, i was not able to foresee the problems we experienced when this code run in prod.. i'm conflicted because on one hand i don't want to be the code police that simply refuses any changes from others, but at the same time its hard to be responsible for a system when so many core updates are done by other team mates w/out proper testing. i think the happy middle ground is: no such changes in common trunk. Do those in a branch, and only merge them in when benefits are clear, team is on board with all changes, you're ready to release to production, and will be around during the release.
nsxwolf 14y ago
But you're not supposed to use debuggers. You're supposed to use Test Driven Development.
sageikosa 14y ago
Always something to be said for running the code through the compiler in your head. Nowadays you need a virtual distributed environment in your head to emulate the design.
manaskarekar 14y ago
Here's a link to the (incomplete) sample chapter on their website for 'The Practice of Programming' on Debugging. http://cm.bell-labs.com/cm/cs/tpop/debugging.html http://cm.bell-labs.com/cm/cs/tpop/debugging.html I had this in my wishlist for a while. This just made me buy it. Wonder how different it will be from Code Complete 2.
- kragen 14y ago
  It's very similar to Code Complete, but much, much shorter. Also, Code Complete has a fair bit of dumb stuff mixed in with the gems of wisdom that comprise most of it; TPOP doesn't.
  - manaskarekar 14y ago
    Thanks for that quick overview. :)
sblanton 14y ago
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.
- sblanton 14y ago
  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.
elmindreda 14y ago
Very good advice. Even when I use a debugger or print statements to locate and fix the bug, I sit down afterwards and make sure I understand why the bug occurred and why the fix is correct.
ten_fingers 14y ago
The lesson is very old: "Typing is no substitute for thinking." from Kemeny and Kurtz in their book on Basic.
hkarthik 14y ago
This is a really relevant article. These days there are legions of programmers who don't think about underlying issues and just throw clever hacks in to get things working and move on. Worse yet, some of these types end up in managerial roles where they expect others to work as quickly and sloppily as they used to.
- thebigshane 14y ago
  It's worth noting that the "clever hacks in to get things working and move on" has proved to be a fairly decent business model for smaller projects or smaller companies. Creates ugly code, sure...
  - hkarthik 14y ago
    agreed. But there is a difference between knowingly doing something sloppy to get things done in the short term versus working like that on a regular basis and thinking it's just how programs are written.
theorique 14y ago
Mental models. They underlie everything.
msluyter 14y ago
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.
- luriel 14y ago
  > 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 http://amturing.acm.org/acm_tcc_webcasts.cfm )
- vandershraaf 14y ago
  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
- adestefan 14y ago
  One of the things it has led me to do is assume that the everything else is correct and I must be doing something wrong. We do that with compilers, interpreters, the OS, hardware, etc., too. It's usually a decent starting assumption, but it can lead to wasted hours when the problem really is outside of what you've done.
  - duaneb 14y ago
    Yes - there was once a bug that took me three weeks to track down, and it ended up being in the compiler.
malingo 14y ago
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?
- drostie 14y ago
  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.
- tomrod 14y ago
  As a recent neophyte, I will use my anecdotal data of size 1 to hazard an answer. I believe once syntax has become relatively understood is when a programmer should start mapping (mentally or on paper) the steps they need to successfully complete a program.
- msg 14y ago
joe_fishfish 14y ago
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.
keeptrying 14y ago
This is only true for man made systems which you have written yourself or have been working with for long periods of time. When you try to "think up" a business then bad things start happening. I think this is a huge trap for us programmers who want to become entrepreneurs. Nature doesn't "think or do research" it "creates and tests aggressively".
ajays 14y ago
One of the best programmers I have known was a CS theory guy. We were working on these tightly-coupled multiprocessor machine which was quite unstable, and would hard lockup if something went wrong in the program (requiring a walk over to the machine room, hitting the reset button, etc.). We would start hacking at our assignments quickly, and make innumerable trips to the machine room. This guy, on the other hand, would just sit and stare into space for a while; then jot down the entire program on paper. Then he would enter it into the editor, fix a couple of typos that the compiler caught, and run it. His program always worked on the first or second attempt. Funny part? he hated to program, and was a theoretician.
- myle 14y ago
  The best advice I had (from a theoretician) was that I should not try to randomly fix my code but I should understand why it does not work. How to do that? Can you prove (in the mathematical sense) that it always does what you want?
  - grn 14y ago
    Giving a full proof that takes language semantics into account is very difficult. I think it isn't a practical way to verify programmes but maybe it'll be in future.
    - flogic 14y ago
      I don' think the advice is to do a proof, but rather to design and think about it in such a way that you could given enough time.
      - dllthomas 14y ago
        One of my CS theory profs had the policy, "A proof is anything that convinces me you could write a proof."
    - wikwocket 14y ago
      The advice isn't to mathematically prove anything, which as you mentioned is hard and may even be unsolvable. The advice is to look at the issue as you would a mathematical problem, critically and analytically. Don't use shotgun debugging or quick fixes, but instead try to understand the code thoroughly, what its goal is and how it accomplishes it. Instead of testing with random data, mentally walk through all the possibilities and branches. This is akin to making a mental model of what you are trying to do, and then verifying that the model is correct, and that your code matches the model.
Almaviva 14y ago
Then again, how many times have you found a bug caused by a single line or function call or bit of syntax that didn't do exactly what you thought, that was easily overlooked? Particularly in someone else's code in a language that isn't your main one. I think line level interactive debugging is valuable precisely because it tells you what you really know for certain at the local level, and so lets you reason more effectively about the big picture.
- sukuriant 14y ago
  You can discern those through thinking, too. "Well, it got to this point and broke... hm... well, what do I know about this environment at this point. What assumptions am I making? Since this assumption isn't being fulfilled, it must be this issue... and that was caused here" Also, this was pair-programming, both people are making sure that what's written is what's intended to be written and so those issues should be (mostly) gone.
bonch 14y ago
This must be why my best bugfixes happen when I'm taking a shower. The number of times I'm showering and suddenly realize what is causing a particular programming problem is pretty surprising. Because of this phenomena, I've taken to going for a walk when something is stumping me.
cr4zy 14y ago
I think this works because you're devoting more energy to the problem than to the sensory and mechanical parts of your brain that will be used to enact the fix. But it's not natural because socially it can look as if you're not 'working'.
philhippus 14y ago
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.
- jrajav 14y ago
  I think you missed "coauthored Go..."
  - luriel 14y ago
    Not just that, he coauthored Go together with the coauthor of C.
    - philhippus 14y ago
      Didn't realise either of those points. I guess that adequately explains my wondering. What's amusing now are the insecure defensive posts and the downvoting.
      - enneff 14y ago
        You're getting down voted because cynicism is cheap, and that's all you brought to the discussion.
- zedzedzed 14y ago
  I find myself productive in go too... and So do many people..
- djtriptych 14y ago
  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.
davidw 14y ago
The advice is to be Ken Thompson?
Evbn 14y ago
Ken Thompson said that never happpend; they didn't need to look at each others code, because they were all "pretty god coders": http://www.informationweek.com/software/operating-systems/qa-ken-thompson-creator-of-unix/231000037?nomobile=1 http://www.informationweek.com/software/operating-systems/qa...
- enneff 14y ago
  That quote (and you misquoted, btw) is from an interview discussing his working relationship with Dennis Ritchie. The particular quote is from a section of the article titled "On Collaborating With Dennis Ritchie" "Dr. Dobb's: Was there any concept of looking at each other's code or doing code reviews? Thompson: [Shaking head] We were all pretty good coders." Nothing to do with Rob Pike, who has worked with Ken for decades since.
- ehsanu1 14y ago
  Ken Thompson was replying to a question about code reviews there. Code reviewing is not quite the same as pair programming (and they probably didn't even call it pair programming then).
- btilly 14y ago
  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.
  - sausagefeet 14y ago
    On top of that, things would have grown in complexity since the early days.
    - luriel 14y ago
      In many ways Plan 9 is simpler than Unix, and Go is simpler than C. Unix was also much simpler than Multics. Software doesn't need to always grow in complexity, but it takes lots of determination to accomplish this.
ardillamorris 14y ago
I think if you are just pushing through (brute force) to fix a bug "without thinking" then you will never figure it out. Also, "thinking before" as the article claims, without actually looking at the code or stack traces, that's just mental brute force. Pretty much it's a combination of both: you look at the code, you think about what's happening and what could go wrong, you look at the code again, you think some more, you look at stacks, variables, output.. and then you think again and BOOM: you figure it out. The best debugging tool is you. Use all you have.
- amouat 14y ago
  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.
  - guelo 14y ago
    But one must also be careful not to fall into the trap of premature optimizations and building unnecessary complexity.
    - simonh 14y ago
      You've just hit a real actual problem in the code. Factoring that out isn't premature, it's responding to reality.
      - guelo 14y ago
        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.
        amouat 14y ago
        And simonh was pointing out that it's not really premature if it's already occurred :) Don't get me wrong, you have a point - there is certainly a balance to be struck.
INTPenis 14y ago
Ken was watching Rob soften the lid on the jar only to swoop in at the right time and deal the decisive blow. ;D
jon6 14y ago
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.
- Symmetry 14y ago
  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.
- pnathan 14y ago
  Yuck, a debugger exposes so little of the world that it's only appropriate in highly targeted approaches.
- duaneb 14y ago
  > 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.
  - gabriel 14y ago
    I'm also one to use logging and error management to help my way through a program. I don't understand how anyone else does it any other way. But surely the debugger helps a lot when no other way to reason about your code exists. I have a lot of problems explaining this to the people I work with. Most of the errors we make are in some way related to having imperfect information through the debugger. At some point complexity gets so high the debugger isn't even capable of handling the system under inspection. What are the tools we use in these cases?
mquander 14y ago
Does the order of the two terminal conditions matter? / Think about it. Does the order of the two terminal conditions matter? / Try it out! Does the order of the two previous answers matter? / Yes. Think first, then try. - The Little Schemer
dinkumthinkum 14y ago
This is my method of debugging. I tend to think through code for a long time away from a keyboard before writing it, trying to understand corner cases, implications, and so on -- developing a mental model. Well, I wouldn't do this for everything, more for core aspects of a complex/somewhat-complex system.
gns24 14y ago
I think this might be an advantage of pair programming that isn't generally talked about. The time to find a bug with a debugger has a much tighter distribution than the time to find one by thinking about the code. There are some problems that you just can't get to the bottom of by thinking. By having one person take each path, you get the advantages of both. It might seem that a single programmer should be able to achieve the same by switching between the two approaches, but the cost of context switching is so great that it will be more like starting again each time. So it's really hard to know when to stop thinking about it and to get the debugger out. The advice that once you find the bug you should work out what the problem really is definitely holds solid, though.
yresnob 14y ago
read. "pragmatic thinking and learning" l mode and r mode people...
gklitt 14y ago
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."
- alan-crowe 14y ago
  How do you find the middle ground? My hypothesis is that one can write the tests first and use them as a compass. If debugging proceeds monotonically, you have thought enough. If you fix the bug revealed by test r, but later when you fix the bug revealed by test s, test r starts failing again, that is a clue that you didn't think enough. What the clue means will depend on the order of the tests. If the tests were written in order of increasing code coverage it is probably a clue that the algorithm needs more thought, but it could be a clue that one hasn't thought enough about test coverage and has ones tests in an unhelpful order.
- liotier 14y ago
  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.
- _delirium 14y ago
  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.
- leke 14y ago
  I thought thinking in code was how every programmer worked. So people usually write code like they write words?
  - adestefan 14y ago
    I don't think in code. My mental model is the process, not the series of functions and objects that make up the process. When the process breaks, I'll dig around to see what code makes up that step of the process.
ww520 14y ago
That'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.
- DamagedProperty 14y ago
  Ah, Yes. I use to have a strong mental model of our security infrastructure and could troubleshoot problems by just hearing the description of the issues and a couple of variables. I would literally see visual gaps where my knowledge of the system stopped if I was drawn there. I would then fill in those gaps. Now as a developer I haven't worked on a model long enough (my excuse) to be able to do that. But now I realize I already have a process for identifying gaps that I don't use. I work with a guy who can do this and recently he has amazed me with how he can do it. Contrary to this though, sometimes I think he works in outdated models that limit his creativity.
- aangjie 14y ago
  I am beginning to realize this recently at my new job. Due to a couple of people leaving and stuff like that, i got handed a reportedly(half-written) code base with no test cases. And a knowledge transfer document, that was mainly written by a poor guy who had gotten the code(before me) and left the project in 3 weeks. In any case, couple of months into the project i got handed a different requirement. Guess what, a total of 10 months after i took the job the second tool is done and is in testing while i am still working on the first one. But the main problem so far has been, lack of clear visualisation of the requirements beforehand. Documenting a project specifications (functional or technical) is unheard of here it seems. I swear taking the time to gather all the requirements would have halved the time i spent developing,demoing, getting feedback,correcting/fixing suggestions etc.. sigh
itmag 14y ago
This is relevant: http://esr.ibiblio.org/?p=316 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?
- lhnz 14y ago
  Some are visual thinkers but I am not. I am a logical thinker and good at creating sensible (that is high-level or very granular dependent on importance) abstractions in my head. Once this is done, it's easy to think "this abstract data gets computed by this function which passes its output to this function, etc." The actual solution will then appear from (0) the association of an (erroneous) result with a particular piece of data/behaviour, (1) strictly following through this model in my head, (2) a holistic understanding of the flow of data and the computational roles inside the system (or external to it in the case of end-users), or (3) a whim to subvert and reframe the question/problem in interesting ways. As Carl Jacob's said: "Invert, always invert." Generally you progress from (0) to (2) before taking out a debugger. Most easy problems are solved at (0). (3) is unusual but intellectually gratifying if you find a way of solving a problem in a way that could not be understood simply through using a debugger and hacking a couple of lines of code.
- svdad 14y ago
  Very. It's just how my mind puts things together, not something I can try to do or not do. I tend to see programs in blocks and patterns interacting rather than sequences of logical operations, probably why I tend to prefer the object-oriented paradigm over others. I get bogged down when I can't visualize the interactions. It isn't just programming, either -- working with derivative products in finance I formed very detailed visual mental models of how they operated.
- sp332 14y ago
  Sometimes visual but more often I imagine the code physically. It has weight, or friction, or rigidity, depending on what aspects of the code I'm trying to think about.
  - itmag 14y ago
chj 14y ago
Golden Advice.
rimantas 14y ago
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 telling about this twelve years old boy "he fixes radios by thinking!".
- djtriptych 14y ago
  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 http://amzn.com/0393316041
  - rje 14y ago
    I recommend: http://www.amazon.com/Classic-Feynman-Adventures-Curious-Character/dp/0393061329/ http://www.amazon.com/Classic-Feynman-Adventures-Curious-Cha... It has both "Surely You're Joking, Mr. Feynman!" and "What Do You Care What Other People Think?" in a nice hardcover.
- sreyaNotfilc 14y ago
  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!!
jcfrei 14y ago
Thanks 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.
goblin89 14y ago
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. =)
- brazzy 14y ago
  I don't understand the lesson to be about "high-level problems", but about not seeing the forest for all the trees. A debugger can give an invaluably direct view of what is happening, but it can allow be a very narrow view. But the debugger is not the problem - in fact, when you don't know the code perfectly, a debugger can be very useful in enabling you to form a sufficiently complete model of the code in the first place. It only becomes a problem if, at that point, you keep looking at details rather than stopping to think about what you've learned.
- aangjie 14y ago
  Can't agree more. Infact at my current company working alone has led me to slow down on getting stuff done. my solution? Write obsessively, i.e to the extent of opening up 750words.com and putting down whatever thoughts interrupt work even if it is at 30 minute intervals.
- tluyben2 14y ago
  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.
p9idf 14y ago
The little interactive graphics language they were writing the compiler for is Pico: http://spinroot.com/pico/index.html http://spinroot.com/pico/index.html http://cm.bell-labs.com/cm/cs/who/gerard/cnn.mpg http://cm.bell-labs.com/cm/cs/who/gerard/cnn.mpg http://cm.bell-labs.com/cm/cs/who/gerard/pixelface.mpg http://cm.bell-labs.com/cm/cs/who/gerard/pixelface.mpg
SeanDav 14y ago
Interesting to note that he has now replaced C with Go (GoLang)
- thebluesky 14y ago
  I also found that interesting, but not a big surprise since he is one of the co-authors of go...
  - zedzedzed 14y ago
    Go is very productive and efficient for me too...
  - BruceIV 14y ago
    Agreed - we'd probably all be most productive working in a language we'd designed ourselves, irrespective of the merits or demerits of that language for other programmers.
    - zedzedzed 14y ago
      Yeah, but not everybody designs a language. Right? [1]The usage of a language directly depends on comfort, productivity and efficiency. Maybe ''Pike's language'' was a factor, but all the above relations[1] come true in wider light.
      - BruceIV 14y ago
        I'm not bashing Go here, just to clarify - I'm just saying that given Rob Pike's deep knowledge of the language and its libraries, and his heavy design input to it, it doesn't mean much that he's productive in it (well, besides the implied statement that he thinks it's not a toy language any more).
    - deleted 14y ago
      [deleted]
    - kragen 14y ago
      I find that I'm much more productive working in languages designed by other people, because they have much larger standard libraries. :)
nekopa 14y ago
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 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.
arturadib 14y ago
As he says it's indeed a matter of style/preference. I've personally spent 10 years in academia deeply understanding many things that more often than not were good for nothing. Now I'm OK with just getting things to work quickly and not looking back. PS: I'm a really fast typer.
zedzedzed 14y ago
Thanks, I learnt a lot today.

427 points by chanux 14y ago

Good advice - after I noticed that I solved most of my tough debugging problems on the walk home from work, I started going outside to take a walk around the building whenever I got stuck. Removing yourself from immediate access to the code lets you think at a higher level how it's organized and what could go wrong.

SonicSoul 14y ago

i've recently had to deal with similar situation, accept the person that refactored my code didn't make such a big improvement. instead he went on vacation and a lot of things broke when we released the code. even though i've looked at all his check-ins, and they looked harmless, i was not able to foresee the problems we experienced when this code run in prod.. i'm conflicted because on one hand i don't want to be the code police that simply refuses any changes from others, but at the same time its hard to be responsible for a system when so many core updates are done by other team mates w/out proper testing. i think the happy middle ground is: no such changes in common trunk. Do those in a branch, and only merge them in when benefits are clear, team is on board with all changes, you're ready to release to production, and will be around during the release.

nsxwolf 14y ago

But you're not supposed to use debuggers. You're supposed to use Test Driven Development.

sageikosa 14y ago

Always something to be said for running the code through the compiler in your head. Nowadays you need a virtual distributed environment in your head to emulate the design.

manaskarekar 14y ago

Here's a link to the (incomplete) sample chapter on their website for 'The Practice of Programming' on Debugging. http://cm.bell-labs.com/cm/cs/tpop/debugging.html http://cm.bell-labs.com/cm/cs/tpop/debugging.html I had this in my wishlist for a while. This just made me buy it. Wonder how different it will be from Code Complete 2.

kragen 14y ago
It's very similar to Code Complete, but much, much shorter. Also, Code Complete has a fair bit of dumb stuff mixed in with the gems of wisdom that comprise most of it; TPOP doesn't.
- manaskarekar 14y ago
  Thanks for that quick overview. :)

sblanton 14y ago

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.

sblanton 14y ago
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.

elmindreda 14y ago

Very good advice. Even when I use a debugger or print statements to locate and fix the bug, I sit down afterwards and make sure I understand why the bug occurred and why the fix is correct.

ten_fingers 14y ago

The lesson is very old: "Typing is no substitute for thinking." from Kemeny and Kurtz in their book on Basic.

hkarthik 14y ago

This is a really relevant article. These days there are legions of programmers who don't think about underlying issues and just throw clever hacks in to get things working and move on. Worse yet, some of these types end up in managerial roles where they expect others to work as quickly and sloppily as they used to.

thebigshane 14y ago
It's worth noting that the "clever hacks in to get things working and move on" has proved to be a fairly decent business model for smaller projects or smaller companies. Creates ugly code, sure...
- hkarthik 14y ago
  agreed. But there is a difference between knowingly doing something sloppy to get things done in the short term versus working like that on a regular basis and thinking it's just how programs are written.

theorique 14y ago

Mental models. They underlie everything.

msluyter 14y ago

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.

luriel 14y ago
> 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 http://amturing.acm.org/acm_tcc_webcasts.cfm )
vandershraaf 14y ago
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
adestefan 14y ago
One of the things it has led me to do is assume that the everything else is correct and I must be doing something wrong. We do that with compilers, interpreters, the OS, hardware, etc., too. It's usually a decent starting assumption, but it can lead to wasted hours when the problem really is outside of what you've done.
- duaneb 14y ago
  Yes - there was once a bug that took me three weeks to track down, and it ended up being in the compiler.

malingo 14y ago

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?

drostie 14y ago
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.
tomrod 14y ago
As a recent neophyte, I will use my anecdotal data of size 1 to hazard an answer. I believe once syntax has become relatively understood is when a programmer should start mapping (mentally or on paper) the steps they need to successfully complete a program.
msg 14y ago

joe_fishfish 14y ago

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.

keeptrying 14y ago

This is only true for man made systems which you have written yourself or have been working with for long periods of time. When you try to "think up" a business then bad things start happening. I think this is a huge trap for us programmers who want to become entrepreneurs. Nature doesn't "think or do research" it "creates and tests aggressively".

ajays 14y ago

One of the best programmers I have known was a CS theory guy. We were working on these tightly-coupled multiprocessor machine which was quite unstable, and would hard lockup if something went wrong in the program (requiring a walk over to the machine room, hitting the reset button, etc.). We would start hacking at our assignments quickly, and make innumerable trips to the machine room. This guy, on the other hand, would just sit and stare into space for a while; then jot down the entire program on paper. Then he would enter it into the editor, fix a couple of typos that the compiler caught, and run it. His program always worked on the first or second attempt. Funny part? he hated to program, and was a theoretician.

myle 14y ago
The best advice I had (from a theoretician) was that I should not try to randomly fix my code but I should understand why it does not work. How to do that? Can you prove (in the mathematical sense) that it always does what you want?
- grn 14y ago
  Giving a full proof that takes language semantics into account is very difficult. I think it isn't a practical way to verify programmes but maybe it'll be in future.
  - flogic 14y ago
    I don' think the advice is to do a proof, but rather to design and think about it in such a way that you could given enough time.
    - dllthomas 14y ago
      One of my CS theory profs had the policy, "A proof is anything that convinces me you could write a proof."
  - wikwocket 14y ago
    The advice isn't to mathematically prove anything, which as you mentioned is hard and may even be unsolvable. The advice is to look at the issue as you would a mathematical problem, critically and analytically. Don't use shotgun debugging or quick fixes, but instead try to understand the code thoroughly, what its goal is and how it accomplishes it. Instead of testing with random data, mentally walk through all the possibilities and branches. This is akin to making a mental model of what you are trying to do, and then verifying that the model is correct, and that your code matches the model.

Almaviva 14y ago

Then again, how many times have you found a bug caused by a single line or function call or bit of syntax that didn't do exactly what you thought, that was easily overlooked? Particularly in someone else's code in a language that isn't your main one. I think line level interactive debugging is valuable precisely because it tells you what you really know for certain at the local level, and so lets you reason more effectively about the big picture.

sukuriant 14y ago
You can discern those through thinking, too. "Well, it got to this point and broke... hm... well, what do I know about this environment at this point. What assumptions am I making? Since this assumption isn't being fulfilled, it must be this issue... and that was caused here" Also, this was pair-programming, both people are making sure that what's written is what's intended to be written and so those issues should be (mostly) gone.

bonch 14y ago

This must be why my best bugfixes happen when I'm taking a shower. The number of times I'm showering and suddenly realize what is causing a particular programming problem is pretty surprising. Because of this phenomena, I've taken to going for a walk when something is stumping me.

cr4zy 14y ago

I think this works because you're devoting more energy to the problem than to the sensory and mechanical parts of your brain that will be used to enact the fix. But it's not natural because socially it can look as if you're not 'working'.

philhippus 14y ago

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.

jrajav 14y ago
I think you missed "coauthored Go..."
- luriel 14y ago
  Not just that, he coauthored Go together with the coauthor of C.
  - philhippus 14y ago
    Didn't realise either of those points. I guess that adequately explains my wondering. What's amusing now are the insecure defensive posts and the downvoting.
    - enneff 14y ago
      You're getting down voted because cynicism is cheap, and that's all you brought to the discussion.
zedzedzed 14y ago
I find myself productive in go too... and So do many people..
djtriptych 14y ago
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.

davidw 14y ago

The advice is to be Ken Thompson?

Evbn 14y ago

Ken Thompson said that never happpend; they didn't need to look at each others code, because they were all "pretty god coders": http://www.informationweek.com/software/operating-systems/qa-ken-thompson-creator-of-unix/231000037?nomobile=1 http://www.informationweek.com/software/operating-systems/qa...

enneff 14y ago
That quote (and you misquoted, btw) is from an interview discussing his working relationship with Dennis Ritchie. The particular quote is from a section of the article titled "On Collaborating With Dennis Ritchie" "Dr. Dobb's: Was there any concept of looking at each other's code or doing code reviews? Thompson: [Shaking head] We were all pretty good coders." Nothing to do with Rob Pike, who has worked with Ken for decades since.
ehsanu1 14y ago
Ken Thompson was replying to a question about code reviews there. Code reviewing is not quite the same as pair programming (and they probably didn't even call it pair programming then).
btilly 14y ago
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.
- sausagefeet 14y ago
  On top of that, things would have grown in complexity since the early days.
  - luriel 14y ago
    In many ways Plan 9 is simpler than Unix, and Go is simpler than C. Unix was also much simpler than Multics. Software doesn't need to always grow in complexity, but it takes lots of determination to accomplish this.

ardillamorris 14y ago

I think if you are just pushing through (brute force) to fix a bug "without thinking" then you will never figure it out. Also, "thinking before" as the article claims, without actually looking at the code or stack traces, that's just mental brute force. Pretty much it's a combination of both: you look at the code, you think about what's happening and what could go wrong, you look at the code again, you think some more, you look at stacks, variables, output.. and then you think again and BOOM: you figure it out. The best debugging tool is you. Use all you have.

amouat 14y ago
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.
- guelo 14y ago
  But one must also be careful not to fall into the trap of premature optimizations and building unnecessary complexity.
  - simonh 14y ago
    You've just hit a real actual problem in the code. Factoring that out isn't premature, it's responding to reality.
    - guelo 14y ago
      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.
      - amouat 14y ago
        And simonh was pointing out that it's not really premature if it's already occurred :) Don't get me wrong, you have a point - there is certainly a balance to be struck.

INTPenis 14y ago

Ken was watching Rob soften the lid on the jar only to swoop in at the right time and deal the decisive blow. ;D

jon6 14y ago

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.

Symmetry 14y ago
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.
pnathan 14y ago
Yuck, a debugger exposes so little of the world that it's only appropriate in highly targeted approaches.
duaneb 14y ago
> 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.
- gabriel 14y ago
  I'm also one to use logging and error management to help my way through a program. I don't understand how anyone else does it any other way. But surely the debugger helps a lot when no other way to reason about your code exists. I have a lot of problems explaining this to the people I work with. Most of the errors we make are in some way related to having imperfect information through the debugger. At some point complexity gets so high the debugger isn't even capable of handling the system under inspection. What are the tools we use in these cases?

mquander 14y ago

Does the order of the two terminal conditions matter? / Think about it. Does the order of the two terminal conditions matter? / Try it out! Does the order of the two previous answers matter? / Yes. Think first, then try. - The Little Schemer

dinkumthinkum 14y ago

This is my method of debugging. I tend to think through code for a long time away from a keyboard before writing it, trying to understand corner cases, implications, and so on -- developing a mental model. Well, I wouldn't do this for everything, more for core aspects of a complex/somewhat-complex system.

gns24 14y ago

I think this might be an advantage of pair programming that isn't generally talked about. The time to find a bug with a debugger has a much tighter distribution than the time to find one by thinking about the code. There are some problems that you just can't get to the bottom of by thinking. By having one person take each path, you get the advantages of both. It might seem that a single programmer should be able to achieve the same by switching between the two approaches, but the cost of context switching is so great that it will be more like starting again each time. So it's really hard to know when to stop thinking about it and to get the debugger out. The advice that once you find the bug you should work out what the problem really is definitely holds solid, though.

yresnob 14y ago

read. "pragmatic thinking and learning" l mode and r mode people...

gklitt 14y ago

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

alan-crowe 14y ago
How do you find the middle ground? My hypothesis is that one can write the tests first and use them as a compass. If debugging proceeds monotonically, you have thought enough. If you fix the bug revealed by test r, but later when you fix the bug revealed by test s, test r starts failing again, that is a clue that you didn't think enough. What the clue means will depend on the order of the tests. If the tests were written in order of increasing code coverage it is probably a clue that the algorithm needs more thought, but it could be a clue that one hasn't thought enough about test coverage and has ones tests in an unhelpful order.
liotier 14y ago
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.
_delirium 14y ago
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.
leke 14y ago
I thought thinking in code was how every programmer worked. So people usually write code like they write words?
- adestefan 14y ago
  I don't think in code. My mental model is the process, not the series of functions and objects that make up the process. When the process breaks, I'll dig around to see what code makes up that step of the process.

ww520 14y ago

That'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.

DamagedProperty 14y ago
Ah, Yes. I use to have a strong mental model of our security infrastructure and could troubleshoot problems by just hearing the description of the issues and a couple of variables. I would literally see visual gaps where my knowledge of the system stopped if I was drawn there. I would then fill in those gaps. Now as a developer I haven't worked on a model long enough (my excuse) to be able to do that. But now I realize I already have a process for identifying gaps that I don't use. I work with a guy who can do this and recently he has amazed me with how he can do it. Contrary to this though, sometimes I think he works in outdated models that limit his creativity.
aangjie 14y ago
I am beginning to realize this recently at my new job. Due to a couple of people leaving and stuff like that, i got handed a reportedly(half-written) code base with no test cases. And a knowledge transfer document, that was mainly written by a poor guy who had gotten the code(before me) and left the project in 3 weeks. In any case, couple of months into the project i got handed a different requirement. Guess what, a total of 10 months after i took the job the second tool is done and is in testing while i am still working on the first one. But the main problem so far has been, lack of clear visualisation of the requirements beforehand. Documenting a project specifications (functional or technical) is unheard of here it seems. I swear taking the time to gather all the requirements would have halved the time i spent developing,demoing, getting feedback,correcting/fixing suggestions etc.. sigh

itmag 14y ago

This is relevant: http://esr.ibiblio.org/?p=316 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?

lhnz 14y ago
Some are visual thinkers but I am not. I am a logical thinker and good at creating sensible (that is high-level or very granular dependent on importance) abstractions in my head. Once this is done, it's easy to think "this abstract data gets computed by this function which passes its output to this function, etc." The actual solution will then appear from (0) the association of an (erroneous) result with a particular piece of data/behaviour, (1) strictly following through this model in my head, (2) a holistic understanding of the flow of data and the computational roles inside the system (or external to it in the case of end-users), or (3) a whim to subvert and reframe the question/problem in interesting ways. As Carl Jacob's said: "Invert, always invert." Generally you progress from (0) to (2) before taking out a debugger. Most easy problems are solved at (0). (3) is unusual but intellectually gratifying if you find a way of solving a problem in a way that could not be understood simply through using a debugger and hacking a couple of lines of code.
svdad 14y ago
Very. It's just how my mind puts things together, not something I can try to do or not do. I tend to see programs in blocks and patterns interacting rather than sequences of logical operations, probably why I tend to prefer the object-oriented paradigm over others. I get bogged down when I can't visualize the interactions. It isn't just programming, either -- working with derivative products in finance I formed very detailed visual mental models of how they operated.
sp332 14y ago
Sometimes visual but more often I imagine the code physically. It has weight, or friction, or rigidity, depending on what aspects of the code I'm trying to think about.
- itmag 14y ago

chj 14y ago

Golden Advice.

rimantas 14y ago

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 telling about this twelve years old boy "he fixes radios by thinking!".

djtriptych 14y ago
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 http://amzn.com/0393316041
- rje 14y ago
  I recommend: http://www.amazon.com/Classic-Feynman-Adventures-Curious-Character/dp/0393061329/ http://www.amazon.com/Classic-Feynman-Adventures-Curious-Cha... It has both "Surely You're Joking, Mr. Feynman!" and "What Do You Care What Other People Think?" in a nice hardcover.
sreyaNotfilc 14y ago
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!!

jcfrei 14y ago

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

goblin89 14y ago

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

brazzy 14y ago
I don't understand the lesson to be about "high-level problems", but about not seeing the forest for all the trees. A debugger can give an invaluably direct view of what is happening, but it can allow be a very narrow view. But the debugger is not the problem - in fact, when you don't know the code perfectly, a debugger can be very useful in enabling you to form a sufficiently complete model of the code in the first place. It only becomes a problem if, at that point, you keep looking at details rather than stopping to think about what you've learned.
aangjie 14y ago
Can't agree more. Infact at my current company working alone has led me to slow down on getting stuff done. my solution? Write obsessively, i.e to the extent of opening up 750words.com and putting down whatever thoughts interrupt work even if it is at 30 minute intervals.
tluyben2 14y ago
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.

p9idf 14y ago

The little interactive graphics language they were writing the compiler for is Pico: http://spinroot.com/pico/index.html http://spinroot.com/pico/index.html http://cm.bell-labs.com/cm/cs/who/gerard/cnn.mpg http://cm.bell-labs.com/cm/cs/who/gerard/cnn.mpg http://cm.bell-labs.com/cm/cs/who/gerard/pixelface.mpg http://cm.bell-labs.com/cm/cs/who/gerard/pixelface.mpg

SeanDav 14y ago

Interesting to note that he has now replaced C with Go (GoLang)

thebluesky 14y ago
I also found that interesting, but not a big surprise since he is one of the co-authors of go...
- zedzedzed 14y ago
  Go is very productive and efficient for me too...
- BruceIV 14y ago
  Agreed - we'd probably all be most productive working in a language we'd designed ourselves, irrespective of the merits or demerits of that language for other programmers.
  - zedzedzed 14y ago
    Yeah, but not everybody designs a language. Right? [1]The usage of a language directly depends on comfort, productivity and efficiency. Maybe ''Pike's language'' was a factor, but all the above relations[1] come true in wider light.
    - BruceIV 14y ago
      I'm not bashing Go here, just to clarify - I'm just saying that given Rob Pike's deep knowledge of the language and its libraries, and his heavy design input to it, it doesn't mean much that he's productive in it (well, besides the implied statement that he thinks it's not a toy language any more).
  - deleted 14y ago
    [deleted]
  - kragen 14y ago
    I find that I'm much more productive working in languages designed by other people, because they have much larger standard libraries. :)

nekopa 14y ago

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

arturadib 14y ago

As he says it's indeed a matter of style/preference. I've personally spent 10 years in academia deeply understanding many things that more often than not were good for nothing. Now I'm OK with just getting things to work quickly and not looking back. PS: I'm a really fast typer.

zedzedzed 14y ago

Thanks, I learnt a lot today.