Live data from Hacker News

Rob Pike: The Best Programming Advice I Ever Got.

informit.com

91–100 of 142 posts

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

#91

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

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.

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

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

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

#93

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…

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.

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

#94

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.

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

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

#95
post #54
post #24

This 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?

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.

Interesting. I should try using that. That is mechanical models. I have come across it(using a mechanical device analogy/metaphor for thinking about something) in other fields(http://www.ribbonfarm.com/2010/06/30/the-philosophers-abacus...).But never really used it in code/design consciously so far.

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

#96
post #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?

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.

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

#97
post #24

This 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?

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.

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

#98
post #87

Earlier quoted context omitted.

A Go implementation is likely more complicated than a C one. You don't think that GC is free, do you?

You forget the fact that Go is a young language while modern C implementation has to support several standards, countless extensions and probably decades of cruft in the codebase. Additionally, if you factor in that go includes a tool that replaces most of what autotools gdoes in the C world, we're talking about a huge blob of accidentally complex code. It's very reasonable to think that the Go implementation is simp…

I'm not forgetting. The make tools are not part if the language and irrelevant. Most C developers I know avoid extensions for portability reasons. The cruft part doesn't matter much for this discussion either, you can start from scratch if you want like TCC. The language definition of Go requires some things that C does not for any reasonable implementation. I think it is much more reasonable to think a C implementation will be much simpler.

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

#99
post #80
post #37

Earlier quoted context omitted.

I think you missed "coauthored Go..."

Not just that, he coauthored Go together with the coauthor of C.

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.

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

#100

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…

[deleted]
Post reply on HN