Hacker News new | ask | show | jobs
by seanmcdirmid 3165 days ago
Hyperbolic Discounting Sounds really weak. So what if I use the arrow keys in my editor rather than learn some obscure magic to get where I want a bit quicker? Likewise, testing is always in that area that is nice to have in code that is going to last more than a few days, but adding them in up front when you are still exploring the design and solution space is just dumb (up there with premature abstraction).
5 comments

> So what if I use the arrow keys in my editor rather than learn some obscure magic to get where I want a bit quicker?

Editor magic is overrated. I learned on vim and was proficient in it, but over time discovered productivity was higher by just using dumb navigation.

Every editor feature I need to think about is some feature about the problem I'm working on that I need to forget.

Sounds like you were not proficient at all. I only ever need to think of vim features when it comes to macros/substitute, but those are things that save me tens of minutes of manual input. The rest is muscle memory. The key is to not religiously learn the shortcuts but only stick with the ones you need daily.
Do you think learning you editor's shortcut significantly affected the success of the product you were developing, as opposed to thinking about the problem, choosing the right design and architecture, writing useful tests, having good communication with the rest of the team, prioritizing the right features, etc?

I mean, I'm sure it had some impact, but how did it compare to the other factors I mentioned? My guess: proportionally, its impact must have been insignificant.

Navigating by search is so much faster - at least in Emacs, where you can get back where you started with a single chord. One of the many reasons I use anything else only under severest duress. No counting, no slow tap-tap-tap and watching the cursor move, no nothing. No struggle to get there, no struggle to get back where you were before you went. No effort. See a thing and jump to it. Do whatever, then jump back. Nothing else I've ever used is like it.
But this is like typing speed. If I could type twice as fast, my productivity isn't going to improve much because my programming bottlenecks are mental. What this does allow you to do is develop a nice rhythm, it can be annoying to go back to the old way, but in the big scheme, it probably doesn't effect your productivity that much.
I think there's an important difference. A great part of a developer time is reading code (even one's own), and navigation is part of it. While typing speed is only relevant to writing code. That makes efficient navigation more important than efficient typing speed. Personally, I never cared much about my typing speed (just enough to move from "pathetic French guy typing with two fingers" to "hey I use a majority of my fingers and don't need to look at the keyboard most of the time"), but I do use emacs navigation heavily.
I agree with what you say, but using an editor with bookmarks and simple find ability - and almost every editor has these - is more than enough for efficient navigation of code. One does not have to spend months using vim/emacs until its use becomes muscle memory, to efficiently browse code.
A simple feature of almost all programming editors, having two files open side by side, vastly reduces the amount of short term mental juggling you need to do.
What's really nice is being able to split the window in which you're viewing a file, and keep part of it visible in one pane while using the other to browse or to read another part. (Or, similarly, being able to have two windows side by side on the same file.) When you have strongly interdependent sections of code which are far enough apart that they can't both fit in the same viewport, this is invaluable for quickly gaining a grasp of what's going on.
So you might as well use sed as Eclipse for doing your programming?
I find it extremely ironic that one of the biases is "premature optimization," and then it goes on to say that you should immediately stop using the arrow keys to navigate because "You end up saving a lot of time."
Writing tests is a great way to explore both the design and solution space. For me, that's more than half the value of writing tests. The fact that they can serve as tests after the fact is just an extra bonus.
It's more about efficiency in doing repeatable tasks.