**Programmer’s Efficiency Disease**
Don’t fixate on 1% improvements and miss the biggest, easiest gains. Michael Nielsen says in Augmenting Long-term Memory:
I know many people who try Anki out, and then go down a rabbit hole learning as many features as possible so they can use it “efficiently”. Usually, they’re chasing 1% improvements. Often, those people ultimately give up Anki as “too difficult”, which is often a synonym for “I got nervous I wasn’t using it perfectly”. This is a pity. As discussed earlier, Anki offers something like a 20-fold improvement over (say) ordinary flashcards. And so they’re giving up a 2,000% improvement because they were worried they were missing a few final 5%, 1% and (in many cases) 0.1% improvements. This kind of rabbit hole seems to be especially attractive to programmers.
He calls this fixation “programmer’s efficiency disease”.
I fall victim to this all the time. My girlfriend asked me for a simple email scheduling app: her work necessitated she manually send out multiple repetitive reminder emails for scheduled weekly classes. We tried to create a simple solution using airtable, but it didn’t quite work and I told her I could create her a simple app. I’d been playing around in blitz.js, and wanted to make a “real” app. (My previous projects had all gotten sidetracked and I had abandoned them…) I started off strong: mocked up a pretty landing page, signup screen, and home screen, and then got started on the meat of the application - scheduling. it was clear scheduling was a complex task (I referenced this blog post for help), and I needed to make sure it worked right: start and end times, daily, weekly, monthly occurences, a calendar view, time zones, the whole lot! I wrote unit tests and refactored over and over, and then I realized - I’d never even shown her what I’d been working on. Did she actually need these features, or had I just been caught up in the rush of building the best, most scalable, bulletproof solution I could imagine?