

Your editor is not the bottleneck - sophacles
http://lateral.netmanagers.com.ar/weblog/posts/your-editor-is-not-the-bottleneck.html

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

~~~
akkartik
There's also the question how how that 100-200 LoC number is measured. They're
looking at code that actually got checked in to the project they're looking
at. I write less than that at work, but there's also an iceberg of code that
wouldn't ever get counted. Iterating on multiple revisions before checking one
in. Throwaway experiments. Side projects (the only reason I have them is that
with fewer constraints they let me stretch my legs and code up a storm).

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

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

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

~~~
mixmastamyk
I don't believe he is saying to use _any_ editor. We could easily list ten of
the best ones than meet your standards above. Someone proficient in one of
those is probably going to do just fine.

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

~~~
TheBoff
Equally, I'll bet that no startup has ever failed because the developers spent
too long configuring their editors.

Why the hell does it matter so much to you that people enjoy being good at
using a powerful tool? If you don't want to see editor articles, downvote
them, or move to another website, or filter them out (either mentally, or
programatically).

~~~
ecaradec
Actually, I think that a bunch of startups failed because of not configuring
their editor, not writing tests, not doing code reviews and refactoring, not
automating anything and generally by not taking the time to clean up things.

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

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

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

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

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

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

------
decklin
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...](http://folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt)

~~~
fisadev
the author says he isn't using SLoC as a performance metric (he is having
trouble to post comments here)

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

~~~
debacle
And, on average, you will write between 100 and 200 lines of code per day.

When you're talking percentages, the standard deviation doesn't matter.

~~~
akkartik
If your editor limits the max it impacts the average. If the days when coding
dominates were more productive you could have fewer of them and spend more
time designing, testing, writing documentation.

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

------
ninetax
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!

