Programming: Doing it more vs. doing it better

Part of it is using the tools others aren't aware of, so simple things become simple (counterexample on codinghorror, someone not knowing that XML has libraries to parse it, and started parsing it manually with regeps. From my own experience taking over a web-scraping project, I used XSLT where they previously used regexps). I have plenty of other examples of people doing things the hard way because they didn't read the docs.

Part of understandability is recognising a simple solution exists instead of a tangled ball. The simple SQL solutions are often most efficient, with tweaking, and the most understandable (which does NOT get you out of writing comments, BTW!)

Performant? The easiest code to optimise is that which is well written and nominally 'less than efficient'. This separation of layers allows me to put in new layers easily as I can see what's going on. Example: for an SQL + pascal product I got a minimum 10X speedup on the GUI, which really made a huge difference to the users, by sliding in a 3rd layer between 2 existing layers. It was simple and quick to do (3 days).

Other example: if someone had thought for a moment about creative use of SQL indexes they'd not have written another complex - and slooooooow - feature in the product I just mentioned.

So IME understandable = clever = performant = maintainable surprisingly often.

(disclaimer: I'm no coding god, I make plenty of mistakes too).

It looks like you add purposeful breaks, experiment, and then see what happens. I wonder if you also talk with your colleagues, self-reflect, think about the big picture rather than just the task at hand when you're doing this?

One night last year I wrote http://canonical.org/~kragen/sw/dev3/usql.py, a toy SQL database supporting queries that join up to two tables. I would have implemented more of SQL, but I had set myself a two-hour time limit, and there isn't a parsing engine in the Python standard library.

Last month I wrote a Mandelbrot set renderer in Python, but it was slow, so I rewrote it in Lua using LuaJIT, which made it extremely fast. That took less than an hour, but I subsequently added some more features to it, so it represents maybe a few hours of work now: https://gitlab.com/kragen/bubbleos/blob/master/yeso/mand.lua

(That one will only run on Linux right now, or MacOS with X11, because it uses my GUI library Yeso, which I haven't ported to Quartz or GDI yet. The others are portable.)

aspmisc, dev3, and bubbleos are Git repos you can clone if you like. You may need to append /.git to the URL.

Those were all purely programming exercises, not drawing on frameworks and libraries and whatnot beyond the very basic stuff that comes with the languages in question (and, in the Mandelbrot case, the Yeso library), but of course I've also learned how to use a bunch of tools; I can spin up a new React project with an Express server and get something working in an hour or two, I can hack together a visualization with D3 in minutes, I can spin up a test server on Bithost in a few minutes, I can import stuff into SQLite or LevelDB in a few minutes, I can write a website scraper using Beautiful Soup and urllib2 in half an hour or so, and so on. So if there's something that's easy to do in SQLite, I don't waste my time doing it the hard way in Python, and vice versa.

I think there's enormous value in investing in tools like Docker to reduce the overhead in spinning up a new environment. There's also a lot to be said for improving low-level skills like typing, text editing, and writing and debugging simple code. It allows you to devote more attention, and more uninterrupted attention, to higher-level tasks like system design. But mostly programming more productively is not about writing code faster, although that sure helps; it's about writing less code.

Yeah, there are; I've had the privilege of working with some of them. Probably they're even better now than they were then, though.

James Joyce wrote Ulysses at the rate of a hundred words per day if you only consider the finished product. However, I doubt every word that Joyce wrote ended up in Ulysses. I'm sure he did quite a lot of cutting and rewriting.

The takeaway from me from the two quoted stories was that quality and quantity are not at odds, but instead are the yin and yang of productivity. They reinforce each other. The more things you produce, the more patterns you are exposed to which in turn leads to higher quality since experience leads to efficiency, giving you more time to get things right.