Your editor is not the bottleneck

Ridiculous. The argument apparently assumes that the only time spent in the editor is writing code. Not writing tests, or documentation, or email, or for reading code, or searching code.

So sure: if you only use your editor for typing in code, it's "not the bottleneck" to getting your code typed in. The problem is that if you're using you're editor like this, your editing skills are absolutely the bottleneck to doing productive development.

I don't necessarily agree with everything written here, but I think it is a good discussion starter. Personally, I think the editor has a huge part in the "code reading" and "thinking" phases. In the former I jump around a lot, and a code reader would end up looking like vim or eclipse or whatever with insertion disabled, and replaced with some sort of annotation mechanism (instead of just inserting comments). I understand that there are other cool things a reader could do, but they would be most useful as additions to an editor anyway, as they have uses in editing and maintaining as well. For the later, I do sometimes walk away from the problem to think, but other times I jump around and look at various bits to help remember the "shape" or imagine how the "shape" of bits would change with my latest ideas.

I disagree with the author on a number of levels. First and foremost, he/she's treating the editor as if its sole purpose in life is the invention of new code. This seems like a somewhat stilted view of reality to me. Features like syntax highlighting, syntax aware block indentation, and project aware search are easy wins in terms of ROI.

Also, they bemoan the fact that for many people their editor is also their primary code reading environment, but it sounds very much to me like what they're asking for is amply provided for in a modern IDE.

While I agree that fixating on a particular tool can be a waste beyond a certain point, IMO a programmer investing in learning their editor seems like time well spent to me.

I disagree with this for a few reasons. Having an editor or tools which feel cumbersome and don't get out of the way, in my anecdotal experience, may cause me to avoid it more often (visit sites like this for instance) etc.

In addition, often when learning new features of an editor or IDE, I enjoy applying it to actual code, which causes me to spend more time coding, which does impact SLOC.

Learning vim features such as autocomplete also save context switches where as previously I would have had to have a browser window open with the documentation. Just my two cents, I think it really does matter.

I would say solving the right problem is the bottleneck. Who the fuck cares what editor you use? Generally, they all work. Startups don't fail because:

1) You can't search through code quickly enough.

2) You couldn't secure the next round of funding because no one was using Sublime Text, or TextMate, or IntelliJ, or Vim, or Emacs.

3) It didn't have all the fancy features that essentially boil down to developer masterbating.

Remember, all startups are supposed to solve a problem that is worth money. WE SERIOUSLY NEED TO STOP TALKING ABOUT EDITORS PEOPLE! Start ups fail because you are solving a problem that doesn't need to be solved, you can't find product-market fit, you have a shitty UI that no one can figure out, your applications are slow or have crazy down-time, or you fail to reach enough of your market to sustain a functioning business model, etc.

None of the problems are code. Code is a means to an end. I'd say code editors are sad not because they focus on the file instead of the class, module or function. I'd say code editors are sad because they focus on code in general that only exists because solving the real problem another way isn't possible.

Let's focus on solving the right problems. Problems that need to be solved, and not problems that look like other problems.

Can we all agree to stop posting text and code editor reviews and editorials and focus on becoming a more integrated component of a larger business? Just for one week, let's not talk about editors and instead think outside of our developer box.

Sorry for the rant but this sort of discussion is not productive, produces flame wars, pedantic quibbling and we never end up anywhere else than where we started. Code editors are like butt-holes, everyone has one and they all stink for one reason or another. Let's not forget that they exist to put poop in the toilet.

*Edit: Some have made extremely valid points that its not all about business, start-ups or money. I agree. My more broader statement is this: the editor one uses is largely a matter of preference and is not the determining factor of success for any project, professional or otherwise. Being able to solve the task at hand (whatever it may be) is largely a function of the focus, determination, experience, and skill of the person using it. At the end of the day which editor you use shouldn't make a damn bit of a difference of the actual bits you compile.

Forget about the speed. Using the right tool for the right job makes you feel better while you work. This not only increases productivity and quality of the product, it also keeps your workers sane. The obsession with finding the right editor (and the right vimrc for it) goes way beyond producing code fast.

I don't know how most other people code, but I rarely write out a module, even from scratch, in a way that doesn't require editing and rearranging. I start with a skeleton which reflects my best understanding of the problem and then try my best to fill it in with code. Sometimes the organization is not quite right, or sometimes you realize you need an extra parameter somewhere that is out of scope; but whatever it is, there's always some kind of stumbling block that requires reorganization.

The overall shape is usually close enough, but it always requires refinement. That refinement happens in a loop; you move stuff around, do a little nip tuck, maybe attempt to fix some bugs, and then run the module (or the tests). Optimizing this loop is important (it's one of the major benefits of scripting languages); once you figure out what change you should make, or what experiment you should run, the faster you make it happen, the faster you get the results, and the faster you can get back to the important mental aspect of figuring out how to fix or create whatever you're working on.

Of course the editor isn't the bottleneck. That doesn't mean that it isn't still the most important tool of the programmer. And there are editors and there are editors. We all have our favorites. Some people get along fine with editors that are nothing but less buggy versions of notepad. Others want their customized Vim or Emacs experience.

Ergonomics do matter.

The problem with a bad editor is not that it wastes time, but that it generates many small interruptions, in the form of awkward editing tasks, which can break trains of thought. The cost of this is drastically higher than the time spend would indicate.

Your editor is not the bottleneck, but reducing the distance between your thoughts and the code is still pretty important. You want to be able to move around, type something and change your mind in the most immediate way possible. Whenever I have to revert to an unfamiliar or inferior editor and can use no motions except from the mouse or arrow keys, I feel like everything becomes harder because I'm not "in" the code.

In the same way, having a compile time of 10 seconds instead of < 1 second is probably the main bottleneck when you code, but your productivity will suffer.

Goodness, this is depressing. I wonder what on earth this guy would say about my breaks to play foosball?

Configuring an editor can be thought of as a similar thing: it can be a fun break from programming, and if it even slightly increases productivity, then that's a win.

I don't think any editor person would argue that using an a particular editor gives a really massive increase in their productivity, but why shouldn't we use specialist editors? It just feels good to write with them, and that can't be a bad thing.

The first thing I thought of when I realized the author was seriously using SLoC as a performance metric was this story: http://folklore.org/StoryView.py?story=Negative_2000_Lines_O...

200 lines of code is the average. What's the standard deviation? There may be some days I write 20 lines of code, and there may be some days I crank through 1000 links of code.

I share the sentiment. Are there any good code readers? Something that could show better what actually lies in your code better than highlighted text does?

Is there a tool like the OP is describing? One that executes portions of test suites when you edit a line of code? That sounds really awesome!