First of all, Happy New Year to everyone in the OSHW community! 2011 has been an amazing year, and I look forward to everything 2012 has to offer as the community continues to mature and develop.
One of my main resolutions for 2012 was to improve the way that I design, test and document most of the boards I work on, particularly where sensitive analog and high-speed parts are concerned (op-amps, high-resolution ADC inputs, SDRAM, etc.).
This desire to improve in these areas is the result of a number of things, but one of the main reasons is the unique challenges and constraints of OSHW. Unlike the traditional HW development models, OSHW implies working with or for a larger community in a relatively transparent way. Your audience isn’t just a consumer base purchasing a functional black box, but a wide spectrum of people with varying skills and experience who need to understand not just what a product does, but how the inner workings of it fit together to make it all tick.
OSHW puts a certain obligation on the developer to not just create products that work well, but to detail and document how they work, setting the bar a lot higher in certain areas. Publishing an open source project can be nerve racking for anyone. It’s akin to opening your kimono in front of the whole world, but one positive result is the pressure to do things the right way, simply because you know hundreds or thousands of eyeballs will be looking at it. My own code and design work has actually improved enormously over the years due to this self-inflicted pressure as well as the valuable feedback of others who took the time to (often graciously) point out some things that can be improved in the messy innards of my own code or PCBs. It’s at times been awkward, and sometimes embarrassing, but and I’m a much better engineer today because of it.
Looking around at the expanding OSHW landscape, I can see a number of tutorials on areas like basic board design, PCB manufacturing, basic coding, etc., but I haven’t seen a lot of articles explaining the hows and whys that go into making products well, or that get into a lot of detail on the messy ‘process’ details that make it possible to get from concept to finished product in a relatively sane and productive manner. OSHW has done a great job of establishing some ground rules of how things should work and some clear business models are taking shape around OSHW, but there hasn’t (in my opinion) been nearly enough effort in defining how to get there in an intentional, productive way. There’s a gap between what people want to do, and empowering more people to be able to do it in a productive, meaningful way.
At this point, you’re probably expecting a 10-point list of things that need to be followed to make you a better or more intentional engineer, but as much as I love a good, well-thought out list, this is actually a drum I’d like to beat on throughout the year rather than one big (naively authoritative sounding) article all at once.
I’d like to drag this one out across a number of blog posts, since being a good engineer (or being good at anything you take pride in!) is an endless and highly iterative process where you constantly need to examine (an re-examine) your work, your conception of things, and your methodologies, endlessly asking yourself — and others! — how you could do things better.
I have a number of hard won suggestions I’ve learned the hard way (that I’m happy to pass on to other people to try to shorten their own journey in embedded development), but it all comes down to a single question I often find myself asking to people who express an interest to me in embedded systems or engineering. Whenever I had to interview a 20-something intern or candidate at a company for a potential position (often their first real engineering job or experience), I’m always sure to ask them the same question: “Do you like learning? Like, really like learning!?” Inevitably, I don’t really care what school they went to or how well they can answer that tricky technical trap question. If I have the impression that they are independent, sufficiently intelligent and genuinely inquisitive, I know that all the technical gaps will naturally fill themselves in.
I always make a point on explaining why I ask that question, though. The honest answer to it is what will determine whether they will be wonderfully happy or terribly miserable working as an engineer in the embedded world. Good engineering is a constant learning process, and if you have the right kind of brain that experience will be either the most fulfilling career option you can possibly chose, or the most dreadful. I’m convinced there isn’t anything in between. If you like learning, constantly improving and never settling for where you are, you’ll excel. If you just want the status quo and good enough, you should probably find a different area to work in.
Without getting too far off topic, though, there are a lot of improvements we can all make in the OSHW community whether in design, documentation, development, or a dozen other Ds. I have a few articles in the works offering concrete suggestions on some of those things (mostly from looking in the mirror myself), and I hope it will inspire other people in the OSHW community to make more of an effort themselves, and also to offer back some lessons from their own experience.
In any case, I’m looking forward to a great and productive 2012 with Adafruit Industries, as well as with the broader OSHW community! The whole community has matured a lot this past year, and I’m looking forward to see what everyone else comes up with as that bar is continually being raised higher and higher!
I’m committed to being a better engineering, specifically in a couple areas this year, and I’m happy to try to propose some changes in a concrete way that I hope others can benefit from as well – but what would you like to be better at this year, and what are you going to do to improve on it? What’s on your engineering reading and ToDo list for 2012? It’s an important question we should be asking ourselves every day, and not just once a year!
