Technical

Programming languages come in a variety of types and flavors: Procedural, object oriented, strongly typed, weakly typed, interpreted, compiled, dynamic, whatever the heck LISP* is, and so on.

They also have a lot in common. Code between them can look virtually identical.

Sure, there will always be weird tricks and gotchas, like how JavaScript passes function calls, or tiptoing around unmanaged memory when marshaling code for C#, or what to do if a language doesn't support polymorphism; but that's what a profound mastery of Google-Fu is for: Attaining new proficencies quickly. Whether you're a software engineer, the lead programmer, or a greenhorn filling in black boxes, adaption is key.

That's because the tools available to each language differ wildly: Game makers, debuggers, engines, environments, libraries, shaders (well, okay, shaders are mostly in pseudo-machine-code), heck, even project management software!

Each tool is written using different paradigms and methodologies. Some tools are fast, others are powerful, some help with team coordination, and others just screw you over. The ability to read documentation and identify best practices is essential in both planning and implementation phases.

This page represents some of my favorite stories that underline my technical competence and ability to adapt. If you want a bullet-point list of my present proficiency, download my resume and scroll right down to skills. But new tools come out every - single - year, and a good programmer can get proficient in any of them, quickly.

*PS: Never change, LISP, never change.

One of my favorite grad projects was the creation of Chloe. She was a large, fluffy, spider-like hexapod. She had three purposes:

• A vehicle for me to learn about physical interactive systems.
• A self-guided project in which I determined the objective, did all of the research, sourced all the parts, programmed all the code, and sculpted the end user experience.
• A prototype for digital pets for addressing loneliness or depression.

At the time I began work on Chloe I had never previously touched embedded systems, and had only worked with a Linux distribution once. Art schools: Tend to be Mac-centric. But I'd always liked the idea of hexapod robots, and seized on the idea to build one.

I had three months.

We were in Hong Kong, so I got assistance from a native Chinese speaker for sourcing the parts for the hexapod on Taobao. It came bundled with a driver board for the legs. This alone was not enough for me: I wanted an autonomous computer running on board the hexapod, not an RC device.

For Chloe's brain, I settled on using the Beagleboard Beaglebone; for a combination of factors involving price, power, documentation, ease of use, and relevant pins and ports. This is contrast to, say, the Audino boards which tend to have very little drive space or working memory, and the Raspberry Pi which is better suited to building tiny PCs.

Everything about learning how to program Chloe was a struggle. The terminology was new. Vim was new. Linux and embedded operating systems were both new. Kernels and launchers were new. I had never Pinmuxed anything. I had never worked with such low level components or communications. The only thing not new was C++, but cross-compiling for arm architectures definitely was.

Perhaps half of all development hours were spent in the lead-up to getting one of Chloe's legs to move for the very first time. Often, the question of "What" even needed to be done was harder than "How" to do it. It involved studying examples, the perusal of documentation, learning vocabulary, learning workflows, setting up environments, building and testing toolchains, and weeks of trial-and-error.

Once I could move a single one of Chloe's legs, development felt like a freight train that had finally reached full speed. I'd made my way to the comfortable domain of C++ coding, and I was writing structures, classes, and fucntions. Building an interface through which Chloe could save, load, queue, and replay instructions was simple. Getting it to run on boot: Simple.

I found someone to teach me soldering, and we attempted to power Chloe through a phone charger bank. One of the experiments I attempted with Chloe was to use wireless charging and point cloud technology, so that in the future she could identify rooms, locate her charging dock, and easily dock herself. This ended up taking up a lot of time and energy and was not ultimately successful, in part because of different voltage requirements. It's something I'd love to tackle again in the future.

Because of the struggles with the phone charger bank, Chloe was actually inappropriately powered throughout most of the development process. She lacked the strength to stand up, and I would turn her upside down or hold her off the ground to inspect her motions. When I finally purchased an appropriate battery, soldered the connectors, wired her up, and plugged her in, it was vindication to see her walk on her own.

Another part of Chloe's design was a kinematics library, so that she could respond to stimuli and move in a more organic manner befitting a pet. While I made extensive progress on this, I had lost time during the wireless charging fiasco, and she had no relevant sensors to demonstrate her skills. I asked my mentor at the time whether it would be more appropriate to finish the kinematics implementation, or work on end user experience. He said the user experience was much, much more important.

"End User Experience," in this context, meant making Chloe look fluffy and furry, like a pet. Focusing on it differentiated me from an engineer. Rather than include a feature I could not fully take advantage of and showing off my code, I started buying fabrics and began studying how to fit them on her.

I lacked a functioning sewing machine, and was in a different country with a limited budget and few resources. I also had no real experience with textiles. I attacked the problem "scientifically", by practicing with thin canvas, stapling the material together to create a quick prototype, and dressing her limbs. I had to address range of motion and pinching.

In the end I used a thick brown fabric that did not easily pinch. I made the necessary patterns. She was 'sewn' together with a thick leather ribbon and shorn holes that made her look rustic and homey. Faux Fur was attached using velcro, to simulate a customizeable pet. Black posterboard with plastic simulated camera lenses for the eyes. A fluffy faceplate gave her an owl-like face. Feathers gave her 'ears.' A red bow was tied around her, to make her pretty as a present. Her feet were equipped with rubber 'chair feet' that gripped tightly onto her underlying metal structure to give her enhanced traction. Her battery and on-switch were accessible through a velcro opening in the belly.

On presentation day, Chloe took about fifteen seconds to boot, stood herself up, wiggled, waved at the crowd, and then promptly turned around and walked off. She remains my favorite project, and is the one I would most love to revisit, with the hopes of making her truly interactive, in the future.