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. =)
Rob Pike: The Best Programming Advice I Ever Got.
91–100 of 142 posts
Re: Rob Pike: The Best Programming Advice I Ever Got.
#92When 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.
#93I 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…
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.
#94This 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.
Re: Rob Pike: The Best Programming Advice I Ever Got.
#95This 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.
Re: Rob Pike: The Best Programming Advice I Ever Got.
#96A 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?
Re: Rob Pike: The Best Programming Advice I Ever Got.
#97This 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?
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.
#98Earlier 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…
Re: Rob Pike: The Best Programming Advice I Ever Got.
#99Earlier quoted context omitted.
I think you missed "coauthored Go..."
Not just that, he coauthored Go together with the coauthor of C.
Re: Rob Pike: The Best Programming Advice I Ever Got.
#100This 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…