With all of my software projects I’ve been working on lately, I decided about a month ago to get into some hardware hacking as well. Arduino seemed like the obvious choice due to its fast growing popularity, great support, and the fantastic starter kit. I ordered up the starter kit and over the past month, worked through the 15 sample projects to learn the ins and outs. After completing these, I decided a binary clock would be a cool first self led project.

Reminder, this blog represents my own opinions only and is on no way affiliated with my employer, Audible or Amazon. Still I think these thoughts are pretty common. In 2014, I moved from a software development role on my team to managing it. During the time since, I slowly began to write less code, made a concerted effort to contribute on some projects, pick up bug fixes on critical projects, help with low severity issues, and do some side projects.

I’ve been reading The Art and Zen of Motorcycle Maintenance and one of the topics of exploration that comes up is quality and what it really means. The assertion is that quality can be seen and observed, but is nearly impossible to describe or articulate. With this in mind, I started thinking about what quality means with code. Now, there are a few ways of analyzing code, but when it comes to articulating what really makes code high quality, I am similarly stumped.