What rebuilding an engine (re)taught me about software engineering

Over the last month I have stripped down and completely rebuilt my the engine in my Subaru WRX. Throughout the process (and with tons of help from my Dad, NASIOC and Tom Weimer) we went through many iterations of trying something, finding that it didn’t work and having to backtrack and try again. This single aspect of the rebuild made it an incredibly frustrating experience – having to take apart what you just built sucks, especially since it usually happens because we got the order wrong or forgot one small little piece. There’s nothing that turns around a mood quicker than realizing you were wrong and now you have to no just do it again, but recover your mess-up before you even get another shot. This same situation come up a lot in writing code for research.

Good engineering involves building complicated systems by breaking complicated processes into smaller cooperative blocks. This says nothing about the process to actually build a system though. Just like rebuilding the car, you end up replacing these smaller blocks multiple times as the project goes on. It is frustrating to have to rewrite code multiple times, but you improve it every time you rewrite. That’s why it’s worth doing it. The magic of abstraction allow us to have these independent blocks.

I feel like I knew this about software engineering and writing code. It is frustrating and annoying to rip out something you wrote yesterday and redo it, but creating perfection is a long series of small steps and a lot of hard work. It’s much less frustrating when you expect stuff not to fit and having to be replaced/-written, and the instantaneous feedback of doing real mechanical things drove home this point very deeply. I’m exited to get back and write some gpu and compiler code!

One Comment

  1. [...] EECS from the Trenches » Blog Archive » What rebuilding an engine … [...]