Memos From the Cube

To bring you this second, very special announcement. She said “I do”!

We’re married!

It’s been a long time – almost 10 years – since Anika and I met each other and started dating. We’ve moved to another country together, endured a year long long-distance relationship, moved in together and more in that time, all culminating on Friday’s wonderful wedding. Huzzah!

Yes, it’s finally time for another LUFA release, since it’s been over a year since the last.

As everyone can tell from the low Git activity, I haven’t found much motivation for any concrete development for a long time now; I’m still waiting to get back the spark of passion that used to fuel me into working on side projects all the time in my spare time. My recent change of employment has raised my personal happiness levels by leaps and bounds, but still there’s something missing that’s preventing me from extracting enjoyment from coding outside of my job. Playing games and watching TV has a big appeal now that I have long commutes and do embedded development all day. The recent news of Atmel’s sale and the realization that I need to re-do the entire thing from scratch at some point to implement what I missed in my original design doesn’t help, either.

But still, enough wallowing in self-pity. As I said, there’s been some fantastic community contributions, and my friend Morten even managed to resurrect the Rube-Goldberg system I jury-rigged up while I was living in Norway to generate native integrated Atmel Studio help, so it’s all systems go. The builds all succeed (even though I had to set up a new Linux VM to build *anything*, since I’ve hit this show-stopper bug on my system after upgrading Windows 10 to the latest build yesterday) and everything’s all packaged up.

The Atmel Gallery extension will be made available in the next few days, as soon as it’s approved by the Atmel staff. The latest extension is compatible with Atmel Studio 7 only – this is due to the changes in the Visual Studio shell, preventing me from making a universal extension easily. Sorry for that; the older extension versions will still install in Atmel Studio 6.x, and both AS6 and AS7 can be installed concurrently, so it’s not all bad news.

Grab the latest release here. The changelog, as small as it is, is located here.

I’m back from my cruise – there’s truly nothing better than kicking around on a deck chair for 10 days drinking Mohitos and reading a pile of good books. I’ve now got a scant two days before I start at Blackmagic Design. I’m truly excited, exhilarated, anxious and terrified, all at once. This is the start of a new chapter, and hope the narrative winds up being another happy one like my time at Atmel.

So, it’s time for a tiny bit more reflection on the last 18 months. I think it’s important to get it down here just so I can organize my thoughts, and ensure I take what I’ve learned to heart. Here’s what I think – hopefully these will not be huge revelations to most folk.

Know what you want to build.
Engineers love to create, but as any engineer will tell you, if you don’t specify exactly what you want, you’ll end up with a dozen different implementations. It’s OK to not have every last detail on paper, but at a minimum a Product Requirement Document should be written and a Minimum Viable Product sheet should be created and agreed upon, to stop last minute “oh, why didn’t you include X” or “but I thought it would work like Y” situations.

The first pass is not the last.
I love to extend code, constantly making minor refactors while I fix bugs or add features. But a big lesson is that some times a clean break really is needed; the first design you come up with might not necessarily fit all that well a year later as product requirements constantly change. Don’t be afraid to redesign and start again once the tech debt starts to build up, but make sure you do it in parallel to ensure you can continue to push out updated in the meantime. Once the two versions reach pseudo-feature parity, develop new features on both versions for a short while to get a feel for the improvements that have been made, and to give you a redundant implementation for testing until the old version is dropped.

Don’t micromanage. Defer.
If you’re a manager, trust you have hired the right people to build what you’re after. Don’t hire skilled engineers, just to treat them as meat robots to great frustration by everyone. With a good team managers should focus on waving the baton, not strumming the strings. Tool choices should be made on technical merits (with a little fluidity) – don’t force a tool on a team (other than Git, of course) that doesn’t suit the job, just because you’re familiar with it. Ensure that a common minimal “supported” tool-set is agreed upon so that new engineers can get started more easily, but don’t force editors, compilers, diffing tools, etc. on others based on your own prejudices. Except no Eclipse. Ever.

Design for test. Automate.
This was a big one; I’ve learned much from some very skilled people on how to design for test; not just unit tests but also integration tests and automated physical tests. Testing is boring, so automate as much as you can. Ensure you have repeatable builds, a build server and a good test plan you strictly adhere to before each internal and public release.

Automated analysis is your friend.
There’s lots of great free tools around for checking your code – CPPCheck, scan-build (part of Clang), valgrind and more. Get to know at least some of them and use them regularly. No matter how good you think you are, you WILL make errors that these tools will catch.

Hire good people. Put them in positions that suit their skills, but don’t be afraid to let them branch out.
A good engineer likes to learn, and technology is a wondrous thing. If a Ruby programmer wants to have a go at firmware let them, or if a Objective-C programmer wants to see what this whole “programming” thing is all about by all means give them a look outside the locked basement for the day. Having cross-team expertise is a good asset and can help reduce integration issues between teams. Just make sure that any work done is properly scrutinized before it is merged and deployed, and that the engineer’s primary focus remains on their original job.

Engineers are not managers, and vice-versa.
This isn’t a hard rule, but so far it’s been almost universally true. It’s a rare engineer that makes a good manager and vice-versa, and chances are you haven’t found an exception to the rule. Don’t mistake engineering ability for the ability to mange people, as people are stochastic things much like raw NAND flash and are far more volatile.

Treat everyone kindly.
This should go without saying, but I now know better. Do this, or lose your entire engineering team in under a year. And make sure you treat them kindly everywhere; word gets around surprisingly fast, and you don’t want to be the employee everyone wants to throw under a (literal) bus because of those things you said about them you didn’t think they’d find out about. Respect is earned, but easily lost, and once lost becomes exponentially more difficult to regain.

Encapsulate business logic.
Copy-paste is bad when it comes to code. Don’t repeat yourself, as the old saying goes, but also abstract. Are a lot of your products similar? Do you intend on swapping out the underlying platform later on? Build simple abstractions and encapsulate all your business logic together in a reusable, retargetable library. Doing so will allow you to build emulators for your product (scalability testing, integration testing, memory analysis, yay!) but also will reduce the workload later on when you need to switch chip vendors or hardware out, as you can just alter the platform specific code leaving the abstract core intact.

DOCUMENT BUSINESS LOGIC.
There’s nothing worse than encountering “strange” logic in old code, the purposes of which are lost to time immemorial (or engineers that abandoned ship because they literally couldn’t take it any more). Without documentation on the reasons behind business logic, you’re merely building a “do what I mean” machine rather than a coherent piece of technology. Documentation shouldn’t be slapped on at the last minute; it should be done by the implementing engineer at the time of, or at least very soon after, the actual implementation is made.

Support arguments with evidence. Don’t force bad decisions on people just because you “have a feeling”.
We’re engineers, not witch doctors. If you think something is better, give a good technical argument as to why, and if possible back it up with numbers. “But that sounds slower” is a poor argument – without evidence your gut is often more wrong than right. Cache locality, internal bus speeds, network latencies and other factors can often surprise even the best of us.

Do what needs to be done, but maintain a work/life balance.
No matter how awesome or fun something is to work on, don’t routinely do it on your free time. Work/life balance is important, and believe me your efforts will not be appreciated later on, no matter how useful the work turns out to be. If it turns out to be really useful you can look forward to either having it appropriated by those who didn’t want it done on company time in the first place, or an increased workload in the future as your weekend time becomes factored into product schedules.

Use proven technologies.
Yes, new and shiny is great, but a successful company is – with the exception of Optus – one that has a product that is functional. Don’t select hardware based on business strategies or cost to the detriment of the product; saving 20 cents on the BOM to end up with a non-functional or only partially functional product is a fool’s errand. For the initial version at least select parts and software that have a proven track record, and only swap them out in future revision to reduce costs once you already have something successful. A consumer might not be happy with paying $5 more for your fabulous doohickey, but they’ll be much more unhappy if that slightly cheaper Frobulator 9000 doesn’t work the way they expected.

Admit mistakes.
Not everyone is right all the time, and everyone makes a mistake from time to time (sometimes blowing up previously perfectly good equipment, *cough*). Own up to it, and suggest a way to resolve it. Doing so will help earn the respect of your peers, and bring the team together towards a common goal. Don’t hide mistakes or try to cover them up; people will know, and they will not help or trust you in the future. Similarly, it’s OK not to know something, so admit it and try to learn rather than making up junk on the spot. Finally, don’t spend all your efforts pointing out the mistakes of others rather than getting stuff done.

So, it’s been a while. One might even say “quite a while”, in fact. A long, long time. But hey, I’ve been busy!

A few months ago, I finally took the plunge and bit the bullet, deciding to move out (again) into a rental property with my shiny new Fiancee while we watch and wait for the housing bubble to collapse. Well, I hope it is and it does; after more than a year of searching it seems anything but a shack or shanty is overpriced by at least $50K at the moment here in Melbourne. Since I’m tired of being blatantly lied to my face by Real Estate agents Anika and I’ve signed on for a short lease while we regroup.

The end is nigh people, I can see it in sight. A little while ago I decided enough was enough, and sent in my resignation at LIFX. It wasn’t a decision made lightly, but magically after hitting send on that short email, a year of frustration, anger and regret flowed out and I’ve felt happier than I have for a long time. My time there has been turbulent; I’ve met some fantastic engineers, but also some horrific – nay, abysmal – managers and learned both how to think on my feet and design/test/ship a product with only a small handful of guys. It’s been the most instructive part of my life to be certain, and I’ve learned an entire swath of new tools for my future career.

It’s a time of my life I won’t look back on fondly (one pivotal decision will remain the biggest regret for a long time coming, and was the eventual straw that broke the proverbial camel’s back not just for me, but for many others too) but despite all the problems I’ll miss a bunch of my Melbourne colleagues; it’s amazing how well a small team can work together despite all the odds and still get things shipped. To that end, I’m happy I joined, if only so I can say I’ve worked alongside some great veterans of the electronics and software industries.

After making my decision I sought out somewhere new, and found it in Black Magic Design, local to Melbourne of all places. Actually, my dad’s been bending my ear about the place for a year ever since he heard about it from a friend whose son works in the film industry, but I didn’t realize it was both so close and so well established in the industry. I start there in a few weeks, but as I haven’t yet been told what I’ll be doing I’m a little apprehensive. I’m sure it’ll work out in the end. I’m excited to have the change of scenery and to jump into a whole new branch of software engineering, and overall it should be a great positive step in my life.

Moving out has also led Anika and I to buy a bunch of new things – I have a tendency to hold on to things until well past the point at which they should be replaced – so it’s been nice to experience good cookware and whatnot. That’s led me to start trying to automate my life a little more; I’ve bought a real Synology NAS which I’ve had great fun fiddling around with, then bought a Raspberry Pi 2 to run OpenELEC as a media center for my TV. I’ve always looked at the RPi boards with interest but never had a particular project in mind, so never ended up buying one before now. It’s all set up and working amazingly well, but that’s led me to buy another to use as a general purpose server/Linux machine.

It’s a revolution people, they’re fantastic little things. I can totally see why they’ve achieved the popularity they have, and I’m having great fun learning more about configuring Linux systems. I’ve used Linux a lot in the past as a VM, but always for firmware development and other general purpose tasks. Now I’m setting up OpenVPN services and making Python-based web GUIs to remotely start and stop the encryption tunnels and having a world of fun. Next I think I’ll see if I can attach some sensors to it and use it for temperature and humidity logging or something.

And with that, the next phase of my engineering career begins. It started with the 8-bits, moved to the bare-metal 32-bits, and now on to figuring out how to write Linux kernel modules. Huzzah!

To bring you this very special announcement. She said yes!

We’re engaged!