Loading...
Loading...
I have a history of taking hardware apart, from electronics such as inkjet printers (anything with a plug really!) to small engines.
This article gathers my lessons learned and reflects on how these could be applied to software engineering.
There's a unique joy in physically disassembling a device. It's a tactile and visual experience that engages both hands and mind. As you peel each layer away, there's a possible "A-ha" moment right around the corner. I get fully immersed in this (flow!) state of discovery.
There’s always two questions that drive me:
And taking things apart is a really effective way to learn too. Not because it’s easy to do, but because you are immersed in the experience, actively discovering and utilising your senses.
This is active learning, as opposed to passive learning, where you’re just reading or listening to something, and have to rely on your brain to encode the information. Which my brain doesn‘t bother to, because I won’t have applied the new information into a real-life situation – and therefore I haven’t really learned anything yet.
It’s the difference between hearing an idea and thinking ‘oh, that’s interesting’, and being able to tell a story about a discovery you did yourself. Active learning is the real deal!.
First, my favourite perk of this disassembly mindset is that it helps to train your problem decomposition skills. You’ll see something and automatically start to see the building blocks it’s made of.
Second, it’s like opening a surprise gift box, and then another one, and then another one, and then another one.
Third, you’ll start collecting your catalogue of ready-to-go parts. I have a box full of motors, gears, sensors, switches, LEDs, and other components. These are both building blocks for something new, as they are also keepsakes of my disassembly adventures.
And these ready-to-go components are GREAT. As an example, I’ve been reusing the internals of a couple of Philips Hue lights and it’s the perfect way to get started with doing custom light fixtures. I don’t have to mess about with any electronics or soldering LEDs, and the Hue lights are already smart. I can focus on building something around it instead.
Fourth, ideate like mad! Once I start seeing those parts, I get the urge to repurpose them. My brain goes wild and starts to think of creative ways to use these parts in a different context. It’s like taking your brain out for a day to the amusement park. But there are no queues and no shitty food!
Now, once you get to the Printed Circuit Board of a piece of hardware I’ve had most of my fun already. Attempting to understand the circuitry and the logic behind it is a whole different ball game. I’m not going to unsolder a microcontroller and try to access its firmware. This is my point of No Fun No More.
The thing is though, modern tech is way more reliant on complex software and advanced chipsets. So you won’t see me take a smartphone apart, because there will be so little to re-use. And thinking of it, taking bigger things apart is more fun than miniature things with baby screws. I have zero ambition to be a watchmaker.
The immersive active learning experience and collecting reusable parts are my favourite two things here. How could I apply this to my software engineering practice?
Let’s start with the elephant in the room. You won’t be needing screwdrivers and pliers, there’s a lot less to see and touch. But you can still take things apart and learn from it. (Wouldn’t it be fun to have a physical representation of a code base though? Or am I suggesting punch cards here?)
It’s different with software, yes. Often components (if designed well) have a distinct function, are isolated enough in order to be tested and reused, but more often than not, they only function well within the context (system) they were designed for.
Think of a React component. Can you just take it out of a code base, drop it into a random (non-React) project and expect it to work? Probably not. Would it be incredibly awesome if it could? Yes!
This is where the ‘what if we design our components like LEGO blocks’ comes in. You’ve heard people say it before, I’ll dare to say it’s a cliché by now.
And yeah, LEGO is great, it allows you to build tons of different things using an (endless) variety of blocks. But LEGO blocks are designed to work together, and they don’t fit non-LEGO blocks. I’d like blocks that do not depend on a specific design system.
Maybe really good building blocks are not about being able to instantly fit together, but about having a distinct function and just well-defined inputs and outputs.
Having written this, I have some things to explore and follow up on:
What would it look like if I would literally take a code base apart into parts, and put them on a re-use / no-reuse stack?
Are there tiny bits (the nuts and bolts), that do not have a distinct function other than connecting things, and can I reuse these in other contexts?
Is it possible to take out some of the bigger components (the equivalents of motors, sensors etc.), and make these easy to use for other projects?
What would a catalog of reusable parts look like?
There’s work to do! :)