Write Code Like You Just Learned How to Program

I’m reading Do More Faster, which is more than a bit of an advertisement for the TechStars start-up incubator, but it’s a good read nonetheless. What struck me is that several of the people who went through the program, successfully enough to at least get initial funding, didn’t know how to program. They learned it so they could implement their start-up ideas.

Think about that. It’s like having a song idea and learning to play an instrument so you can make it real. I suspect that the learning process in this case would horrify most professional musicians, but that horror doesn’t necessarily mean that it’s a bad idea, or that the end result won’t be successful. After all, look at how many bands find success without the benefit of a degree in music theory.

I already knew how to program when I took an “Intro to BASIC” class in high school. One project was to make a visual demo using the sixteen-color, low-res mode of the Apple II. I quickly put together something algorithmic, looping across the screen coordinates and drawing lines and changing colors. It took me about half an hour to write and tweak, and I was done.

I seriously underestimated what people would create.

One guy presented this amazing demo full of animation and shaded images. I’m talking crazy stuff, like a skull that dripped blood from its eye into a rising pool at the bottom of the screen. And that was just one segment of his project. I was stunned. Clearly I wasn’t the hotshot programmer I thought was.

I eventually saw the BASIC listing for his program. It was hundreds and hundreds of lines of statements to change colors and draw points and lines. There were no loops or variables. To animate the blood he drew a red pixel, waited, then drew another red pixel below it. All the coordinates were hard-coded. How did he keep track of where to draw stuff? He had a piece of graph paper that he updated as he went.

My prior experience hurt me in this case. I was thinking about the program, and how I could write something that was concise and clean. The guy who wrote the skull demo wasn’t worried about any of that. He didn’t care about what the program looked like or how maintainable it was. He just wanted a way to present his vision.

There’s a lesson there that’s easy to forget–or ignore. It’s extremely difficult to be simultaneously concerned with the end-user experience of whatever it is that you’re building and the architecture of the program that delivers that experience. Maybe impossible. I think the only way to pull it off is to simply not care about the latter. Write comically straightforward code, as if you just learned to program, and go out of your way avoid wearing any kind of software engineering hat–unless what you really want to be is a software engineer, and not the designer of an experience.