Developing Programmers .com

When I was still in school, I tried writing my first text editor. The biggest limitation I was up against was that output to the terminal was extremely slow.

I got clever: I wrote a display engine that’d take where the screen was at now, and where it wanted to be, and figure out the smallest possible change to update it. This meant that depending what was on the screen, scrolling might involve asking the terminal to scroll, or if it was lots of similar text it might just tweak a character or two; depending which required least time to render.

It was a really cool idea, and an over-engineered disaster. The program took so long working out what was “optimal” that it didn’t matter; it was slow anyway. I’d have been better off taking a simplistic approach, for example just updating whole lines that changed; or even not worrying about it until I got a handle on actual speed, then tweaking from there. Sadly, the “cool trick” was so central to my initial design it was hard to replace.

I’d been blinded by a perceived optimization need, and made the mistake of optimizing early. It’s only relatively late in development you can clearly see where time is spent, and where it matters.

Since then I tend to do things the “simple” way up-front; and just focus on keeping the code clean & modular so I can replace the parts I need to at the end for any optimization tweaks.

Now I’m working in a team, and more than ever “optimizing for simple” is paying off bigtime. When I get questions, they’re usually about the places I haven’t simplified or honed down to the basics adequately.