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.
Rob Pike: The Best Programming Advice I Ever Got.
61–70 of 142 posts
Re: Rob Pike: The Best Programming Advice I Ever Got.
#62I'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. =)
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.
#63Re: Rob Pike: The Best Programming Advice I Ever Got.
#64Earlier 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.
Re: Rob Pike: The Best Programming Advice I Ever Got.
#65Re: Rob Pike: The Best Programming Advice I Ever Got.
#66Re: Rob Pike: The Best Programming Advice I Ever Got.
#67That'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.
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.