I’ve spent the last 40 years programming so at this point jumping in to a new language and SDK is my natural inclination. They’ve got sample programs and a commented API? Great, I’m all set. It was with that mindset that I started with the Garmin ConnectIQ SDK so I could do some fun development for my 920XT watch. It’s a great piece of engineering with GPS, ANT+ communication with heart rate, cycling cadence, and other sensors, and Bluetooth communications with my iPhone. Hell it even tells time.
I was able to get a new watchface running within a few hours of downloading the SDK, which I proudly showed off to my Triathlon club. The examples were rich enough to easily cobble together the basic things I needed. I got it to the point where I could get it on my own watch but didn’t bother to publish it to the ConnectIQ Store, i.e. actually complete it. That’s a bad habit I have but we can talk about that another time.
Encouraged, I wanted to dive into developing a data field to tell me when to take on more fuel during training and races: in my case the ultra generic Vanilla Bean Gu’s. Using another sample program I got underway guns blazing. Not so fast. I spent 3 hours frustrated that I couldn’t make Monkey C do basic math with the simulator spewing out ‘unknown symbol’ errors from my code. That turned out to be just a basic language and API knowledge issue. After that it was ‘permission denied’ errors from the simulator for another few hours spent searching the ConnectIQ message boards. That turned out to be an unsupported Attention API for data fields. OK .. time to Read The F!@#ing Manual.
Sure enough, the manual was filled with those answers and more – what a surprise. It was even well-written and had some humor. I found out that my cobbled-together SBTri watch face was reloading the background image for every update, thus impacting the device’s battery life. I found out that the application lifetime was different for Data Fields vs. Watch Faces vs. Widgets vs. Applications in the Garmin world. I found out that my next idea should be implemented as a Widget, not an Application. I found out how to call a Super-class method from a Sub-class.
So, why didn’t I read the manual first?
- Ego. I think I’m smart enough to pick it up as I go.
- Fun. Starting a project by reading a manual is nowhere near as fun as just creating.
- I like to be able to work fast and training can impede that
- I value experiential learning over book learning, apparently to a fault.
I’m using the same dive-in approach at work right now with RTI’s Data Distribution Service but this ConnectIQ experience has me thinking about a modified approach. Diving in lets me produce things quickly and perhaps look better than the next guy, but I’m doing the company a disservice when I then stall because of insufficient knowledge and training. A more effective approach might be to combine the quick start of tweaking vendor examples alongside working through the manual.
Now to see how this applies to my non-programing life