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 theprogram, 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.
Good read and guilty as charged.
I can no longer write anything these days without laying down frameworks, importing libraries and following conventions. That includes weekend projects. To be fair, if you write software for a living, this kind of mindset is mostly valuable in prototyping. If you’re doing production code, I would argue that not only this is counter productive but dangerous as well.