---
author: ''
category: ''
date: 2012/07/15 22:22:12
description: ''
link: ''
priority: ''
slug: your-editor-is-not-the-bottleneck
tags: python, programming
title: Your Editor is Not the Bottleneck
type: text
updated: 2012/07/15 22:22:12
url_type: ''
---
This may cause some palpitations in some friends of mine who laugh at me
for using kwrite, but it really is not. Any time you spend configuring,
choosing, adjusting, tweaking, changing, improving, patching or
getting used to your editor is time invested, for which you need to show
a benefit, or else it's time wasted.
Let's look at SLOC, which while discredited as a measure of programmer's
productivity, surely does work as a measure of how much a programmer
*types*, right?
Well, estimates of total code production across the lifetime of a product
vary (just take the SLOC of the product, divide by men/days spent),
but they are usually something between 10 and 100 SLOC per programmer
per day. Let's be generous and say 200.
So, 200 lines in eight hours. That's roughly one line every two minutes, and
the average line of code is about 45 characters. Since I assume you are a
competent typist (if you are not, shame on you!), it takes less than 20 seconds
to type that.
So, typing, which is what you often tweak in your editor, takes less than
15% of your time. And how much faster can it get? Can you get a line
written in 10 seconds? Then you just saved 8% of your day. And really,
does your editor isave you *half* the typing time?
How much time do you lose having your eyes wonder over the sidebars, buttons,
toolbars, etc?
So while yes, typing faster and more efficiently is an optimization, it may
also be premature, in that, what the **hell** are we doing the other 80%
of the time? Isn't there something we can do to make that huge chunck of
time more efficient instead of the smaller chunk?
Well, I think we spent most of that time doing three things:
1) Reading code
2) Thinking about what code to write
3) Fixing what we wrote in that other 20%
The first is easy: we need better code *readers* not *editors*. It's a pity that
the main interface we get for looking at code is an editor, with its constant
lure towards just *changing* stuff. I think there is a lost opportunity there
somewhere, for an app where you can look at the code in original or
interesting ways, so that you understand the code better.
The second is harder, because it's personal. I walk. If you see me walking while
my editor is open, I am thinking. After I think, I write. Your mileage may vary.
The third is by far the hardest of the three. For example,
autocomplete helps there, because you won't mistype things, which is interesting,
but more powerful approaches exist, like constant running of tests suites while you
edit. Every time you leave a line, trigger the affected parts of the suite.
That's much harder than it sounds, since it means your tools need to correlate your
test suite to your code very tightly, so that you will see you are breaking stuff
the *second* you break it, not minutes later.
Also, it should enable you to jump to the test with a keystroke, so that you can
fix those tests if you are changing behaviour in your code. And of course it will
mean you need tests ;-)
Which brings me to a pet peeve of mine, that editors still treat the file
as the unit of work, which makes no sense at all. You never want to edit
a file, you want to edit a function, or a class, or a method, or a constant
but never a file. Knowing this was the sheer *genius* of ancient Visual Basic,
which was completely ignored by all the snobs looking down at it.
So, instead of tweaking your editor, get me a tool that does what I need please.
I have been waiting for it since VB 1.0. And a sandwich.
.. admonition:: warning
This post is 99% lies, but I want to hear the arguments against it. If I tell
you now it doesn't count as a real lie, I have learned from financial press ;-)
**UPDATE:** Interesting discussions in `reddit `_ and `hacker news `_