Challenging

Sometimes you get to know a person better and you learn more and more about how they tick. Fundamentally I think most developers are searching for a challenge and I had a chat with Frank Hunleth (of Nerves) that reminded me of this recently.

It was an off-the-cuff exchange. He was doing some for him trivial work to support a new helpful feature in fwup (friendly unique-ish names for firmware) and he encouraged me to look at the code because he'd been up to silliness. Because the task was dull he made it interesting. And we meta-talked about that a little. He mentioned that he needed to find challenges to stay motivated and I quipped "that's why you got into embedded" and he said some variant of "yeah, definitely".

Embedded is not the only type of difficulty you can strive for. There are so many varieties. You can go for mathy with machine learning. You can go for massive distributed systems and scaled performance and reliability in the huge clouds. You can go deep into type system theories. Formal verification. You can go into design. You can go into writing and communicating. All of these are fractally complex and hard the deeper you go.

I can't say whether all devs feel this way. It is entirely possible that I filter for devs with this mindset and that in the world of speakers, maintainers and ecosystem deep-nerds I simply mostly deal with this mindset.

Programming itself is a ton of hard stuff and things to learn as you start out. Then you pickup web dev or a domain area and things get deeper. More problems, more challenges.

The problems in embedded are filthy with physical aspects. It is a messy place where while we aspire to rigour we are dreadfully close to being betrayed by hardware and consequently physics at every turn. Especially since IoT is also usually a budget-sensitive space so you end up compensating for things that are bad because they are cheap. You are never done. The results can be good but it never feels complete, finished and squared away. A particular product may reach a solid end-state but you'll have a laundry list of things you wouldn't do on the next one, things that worked well. Deeply pragmatic craft, continuously challenging. And a fun mix of theory and practice. Rubber really meets the road.

Others want a more pure challenge. I bet there are a lot of ML researchers that resent the limitations of GPUs and processing as it constrains what they can do with their beautiful math. And then there are the people who really enjoy seeing how much bang they can get out of a GPU buck. And you'll also find the people that really explore the gotta-go-fast aspect. I've had tons of fun chatting with Matt Topol who works a lot on Apache Arrow (the underpinning for Pola.rs and Elixir's Explorer). The whole point of his work is to remove unnecessary copying of data structures in memory for analytical data. Making it flow faster, saturate hardware, compute tighter.

As you get into a thing you'll learn a ton about the shape of the challenge. I don't enjoy all types of challenges. I enjoy some way more than others. I think embedded suits my scrappiness. I don't think I have a head for the ML space.

And sometimes you have to be aware that you are doing something just for sport. Frank is also the guy who wrote  a boot loader rather than helping me configure U-boot. I personally keep pushing lower level because I have an appetite for it but very little practice. I don't drop into C on a client project unless it is absolutely called for. I try to operate in my most reliable toolset. I've seen how Frank keeps things simple in production projects and how he learns by playing with things where there is no harm. I think that's part of how we grow.

Where are you finding your challenges?

Thank you for reading. I appreciate it.