Un-Expected Value and a Slow Snake

I just finished the latest course towards my Masters in Electrical Engineering at UW – Probability and Random Processes for Electrical Engineering. And yeah, I got an A (>100%). And I’m glad I took it even though I had, years and years ago, taken Stochastics at Johns Hopkins. Although core concepts like probabilities, random variables and the like haven’t changed, the options available to engineers for numerical methods seem more practical now.

Our final project involved using a Naïve Bayes Classifier to classify handwritten digits from the large MNIST database ( http://yann.lecun.com/exdb/mnist/ ). First you train your classifier against 60,000 training images (handwritten digits from 0 to 9) and then you run 10,000 test images against the classifier and see how well it identifies the digits in the images. I don’t remember doing anything like this in the Stochastics course at Hopkins, and it was fun to translate Bayes’ Theorem into code and even more fun to see it work.

That was the un-expected value in taking the course again (and it freed up transfer options which will allow me to take a Comp Sci IoT course next quarter and have it count towards my MSEE.) (BTW – that’s a probability pun there – un-expected value – get it?! Wokka wokka.)

I wrote the classifier first in MATLAB (we get a generous student license for this powerful not-free software) and then again in Python with NumPy ( https://numpy.org ) (because all the cool kids are trying ML with Python and although some assembly is required, Python and NumPy are free [including as in beer].)

Both MATLAB and Python/NumPy yielded the same results:

Basically, when presented with a “0” digit, the classifier correctly identified it as a “0” 90% of the time (or incorrectly as a “5” about 5% of the time and so on and so forth.)

What I didn’t expect was how SLOW Python was to do the same work. MATLAB processed all the data in about 5 seconds but Python took almost 3 minutes to do the same work. The majority of that difference I suspect comes down to MATLAB scripts being compiled into native code before execution whereas Python is interpreted on the fly. Then again, for free software, it does open access to numerical methods for those without access to the professional tool, so that’s a positive – it reminds me of some of what we run into with WooCommerce and how I see native code projects like PeachPie ( https://www.peachpie.io ) as a potential game changer for performance.

While researching the speed difference, I came across this article that sums it all up well and in a funny light:

MATLAB is the BMW sedan of the scientific computing world. It’s expensive, and that’s before you start talking about accessories (toolboxes). You’re paying for a rock-solid, smooth performance and service. It also attracts a disproportionate amount of hate.

Python is a Ford pickup. It’s ubiquitous and beloved by many (in the USA). It can do everything you want, and it’s built to do some things that other vehicles can’t. Chances are you’re going to want to borrow one now and then. But it doesn’t offer a great pure driving experience.

Toby Driscoll, https://tobydriscoll.net/blog/matlab-vs.-julia-vs.-python/

I’m glad when I have access to or can afford “BMW” level tools, but I also appreciate the experimenting, low risk prototyping and access that “Ford” level tools unlock.

Back in the Engineering Saddle Again

A little over two years ago, fresh off the heels of helping ready my company’s part of the Internet for the GDPR, I offered to again take up the leadership of a small team I had led before – this time to launch another SaaS offering – this time in payments. The opportunity aligned well with my personal goal of leveling up my leadership skills with what was then an eye on a director of engineering role, and it also aligned with a engineering roadmap I had set forth nearly five years ago to get hardware related work (specifically integrating our software with mobile payments and point of sale hardware) into the company.

My team launched the next step of that vision earlier this year, as WooCommerce Payments, on time and (mostly) on scope. Looking back, I’d say I enjoyed the earliest parts of the project the most – when the team was smaller and the emphasis was on nailing down the architecture and tech stack. In hindsight that’s a key observation. Of the things I had on my plate – people management, project management and technical leadership – I found myself increasingly spending the majority of my time in people and project management and less and less in architecture and the tech itself.

I’m quite grateful to Stripe for setting an expectation at the beginning of the project that (eventual) hardware integration was a requirement – because that has opened a door for me to pull a phoenix and re-birth myself with a focus on technical leadership. I’m keeping myself laser focused on that this time around. 🙂 And I want to still spend more time with people, but not as their manager. I’d rather be a mentor. I learned that too.

I also owe a debt to an article by Charity at https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/ where she so eloquently laid out this engineer-manager-engineer pendulum that so many of us engineering types do 🙂 It helped shine a light on the path forward.

So, there you have it – a brief retrospective of my experience as a team lead / engineering manager. Onward and upwards!

Z Nope

I was excited to start setting up the Z-Wave bridge. That excitement has dimmed. I’m got the device in the mail, whipped out the installation instructions, plugged it into my Pi and…

The first step was to run a curl command to a http site and pipe it to sudo bash. Eeek.

I mean I know people joke that the “S” in IoT is for “Security” but this wasn’t funny.

I’d never ever do such a thing on a device and trust that device again. I proceeded against my better judgement to see how far the rabbit hole went. (I’ve since disconnected the Pi from the Ethernet and will reflash it soon.)

The next red flag was that although installing the bridge plugin went smoothly, the iOS Home app warned me that the bridge was not certified. Strike two.

I was about to try adding a Z-Wave device to the bridge when I just stopped. I was not going to trust this with access to my home’s devices.

Maybe I can write a bridge for this Pi peripheral myself and now I am curious about what Apple requires for certification:)

Till next time…