[Toybox] Editors and such.

[Rob Landley]

Gah, have to get used to new keymappings.  (Thunderbird reply-all was 
ctrl-shift-R.  In balsa, it's just "a".)

On 09/05/2012 11:11:09 PM, David Seikel wrote:

> But as I mentioned, not interested in a bug hunt right now.  That 
> will be more appropriate when it's less of a "sandbox for testing the
> ideas" and more of a "good enough to bother using".  Always good to 
> have other terminals for testing though.

Ok, back up.

I've learned lots of snippets of open source general practices over the 
years, and some day I need to track down Al Viro's "trail of 
breakcrumbs" post so I can attribute it properly.

Don't give me a big finished solution. Give me a small set of easily 
understood chunks that take the code from where it is now to where 
you want it to be.

Yes, I'm explicitly saying it: I'd rather the code you give me be easy 
to understand than that it actually _work_. I can fix "doesn't work", 
once I understand what it's doing.

The result of each addition must compile and run, so I can bsect 
regressions introduced by changes (that's not an "if", that's a "when", 
including for my own changes). But beyond that, the important thing is 
that I be able to read each chunk of code and see what it's doing.

And one of the big truths of computer programming is that READING code 
is harder than WRITING code. When you write code, you construct a 
mental model first, and the code on the screen trails the mental model 
in your head. But when you _read_ code your mental model trails the 
code on the screen, and you understand _why_ it's doing stuff before 
you type up the _what_.

Programs do not have a single simple linear ordering, they jump around 
all over the place in normal operation, so whenever you're reading code 
it will rely on stuff you haven't read yet which isn't in front of you 
either, and you're either constantly going off on tangents or reading 
past gaps you don't understand yet. You have to assemble an 
understanding of the code by reading it out of order, and you have to 
reverse engineer the _why_ from the _what_.

And that's if it's good code, reasonably cleanly laid out, with no 
mistakes.

So when you give me code, assume I'm dumber than you. Because in this 
context, I am. I need bite sized pieces, each of which I can understand 
in its entirety before moving on to the next.

I already understand the code that's _there_ (modulo things like login 
and du that I haven't had a chance to properly go over yet), so give me 
manageable deltas against the bits I understand, and let me chew on 'em 
a bit. (Otherwise I get overwhelmed and we wind up with pending 
submissions like people from Georgi and Ashwini that I don't get to for 
an _embarassingly_ long time because 15 minutes of poking at it doesn't 
make progress and until recently my time was only available in small 
chunks. I have more time now, but a much larger backlog...)

Thanks,

Rob