Live data from Hacker News

Rob Pike: The Best Programming Advice I Ever Got.

informit.com

61–70 of 142 posts

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

#61
post #55

Earlier quoted context omitted.

I also found that interesting, but not a big surprise since he is one of the co-authors of go...

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.

[deleted]

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

#62

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

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.

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

#64
post #55

Earlier quoted context omitted.

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.

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.

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

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

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

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

#67
post #23

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.

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.

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

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