Making Things You Don’t Know How To Make

I mean, I definitely can’t do motion tracking; I can’t build a GUI to record and play back movement traced on top of video; why would I even try building a hardware intervalometer?

This is also clearly not true because, you know, here I am, and some of these things are in progress, and some are finished and work.

So I thought I’d look at how I got there, from step one, and use my timelapse box as a sample piece of work. I definitely wouldn’t have thought I could have done this until even, I don’t know, a few months before I thought to try.

To that end, this talk is a few of the maxims that I’ve found myself sticking to in my work; a series of bullet points, which you can take what you’d like from. To begin:

I never make things because the tutorial was sweet. I make things because I need one, or I want one. Sometimes I want the outcome. Sometimes I want to learn to use a thing – the Kinect, or an LCD, or a new programming language. But I need a goal to go with that. I won’t just learn a programming language for the sake of it any more.

It turns out if you can make Lego you can follow instructions, and if you can follow instructions you can do quite a lot. There are lots of great instructions on the Internet now. That’s good! And if there aren’t instructions, you’ve probably read documentation, and not all of it is terrible – so that’s good, too! Then, if you can write code, you can probably write another type of code. Or if you can work in wood, there’ll be stuff similar in other materials too. So already, you don’t just know one set of things; you have feet in lots of adjacent spaces, too! And so just because I while back I mainly wrote code in languages for the Web and command line doesn’t mean I can’t do other things.

…except for when they’re not. So for me, that was case in point: electricity is weird. It appears to be closer to water than anything technological – it splashes around, it jumps in odd ways, it flows, it’s tempramental and analogue, and there’s no easy way to get your head around it. Or at least: that’s how it felt for me.

All I can say is: suss out what’s going on sooner rather than later. Get to know your materials – more on that later.

Sketching: draw it! I cannot draw but I draw anyway, because things come to life when you try to picture it: you fill in the details your brain ignores when it’s having big ideas. so as well as my box, I drew my UI screens – counting the number of characters on each of them. By drawing everything, you start to fill in the holes in your plan – where the battery goes, for instance!

And then, you can break down your sketch into its component parts to make it.

Break it down into things you either a) understand or b) want to understand.

That begins with breaking down the idea (not the implementation). So, for the intervalometer:

• I knew it had an Arduino in it because that’s the platform I know
• I wanted to play with screen
• I wanted to play with a rotary encoder, because it felt like an appropriate UI
• I was going to hack an existing remote to use it.

One of those things I knew. The rest I wanted to know.

But each of those chunks was a nice starting point. So to begin with, I just sat down with a screen and Arduino and played with it. What could it do? what do 16×2 UIs feel like? (Answer: 80s Roland synthesizers). How should I address it? How do I abstract the code?

When I reached a nice stopping point, I moved on.

Whilst I’d done that sketching on paper, it was important that the sketching also happens with my hands: thinking through making. I think this is important: that you think with the materials you’re working in, because everything else is just dreams. That means holding them and finding out what they can do. It’s something I constantly try to live up to – making sure I’ve understood things with my hands, not just assuming a drawing can be brought to life.

So, you know, even though I had all these libraries about a 16×2 lcd, it was good to know things like how bright it was (answer: bright enough that I dim it when the intervalometer is armed), how quick it was to update, what characters look like. Similarly with the encoder – it was easy to slot in to replace simple “nudge up / nudge down” code, but finding a rate where it didn’t feel over-sensitive: you do that in your hands.

And, of course, IR is the weirdest material, and the one I fell short on – it isn’t the right size/shape for how close it has to be to the camera (not hugely close, but quite close).

The materials also include software. Sometimes what I’d be finding is where the solved problems were, who already had code for it, and whether that’d be suitable or not, if they’d fixed limitations, etc.

There’s no shame in prior art: this is part of the point of open source. We all copy and paste. That will only get you so far, of course – you need to go back, make sure you understand it. But some days, you just need to get over a hump, and if that involves copy and paste, that’s where I go. Then, when it works…

STOP!

You need to understand what’s going on. Otherwise things are going to leak, and when thing Z is going wrong it’s because you didn’t understand thing X a bit earlier. So for every lurch forward thanks to copy/paste, make sure you invest the time later at the end to understand that lurch.

I glued together a lot of existing code for this project. Given I use all these things from other people – did I actually do any work? Isn’t that the whole thing?

Well, no, it’s not. It’s the parts. They still need gluing together, and the glue is important. So in this case, the glue is joining up all the functionality I want this device to have; the glue is the UI, both how the button works and how the screen works and what it says and things like that. That is where the “thing” emerges.

There is a skill to glue code, too – mishmashing everything together and thousand line .pde files is not it!. Keep it clean and tidy! There’s a value in this: if you’re not a brilliant programmer, spending your time on nice hardware or nice ideas and using somebody else’s code isn’t lazy, it’s efficient.

Of course, because you’re thinking with your hands, you might eventual find your glue code doesn’t quite cut it any more – which is fine; that’s the time to replace it. Because even if you do, there was still value in using something off the shelf to start with – it helped you to understand the problem. Your understanding of the problem has meant you now know why somebody else’s code doesn’t cut it.

Now, the realities of thinking through making mean you can’t always choose how you work; I end up veering from one pole to another – mad hacking away, and then pausing to tidy, rather than keeping everything tidy. Sometimes, starting loads of prototypes with no end in sight. That’s fine – just finish them later. You lurch at a problem from both directions, starting at the beginning and coming to the middle, and then starting at the finished thing in your head and working backwards.

What i’m essentially doing is creeping up on the problem. Sometimes I have a big idea and I go for it. When I don’t, I get a bit scared. so to assuage that fear: I creep up on the problem. I find out the knowns and get them out of the way. I work out what’s going on with the material and solve it one thing at a time. And slowly you hone in on a thing: the circle gets tighter, more things become known knowns, and you whittle down the options as to what the thing in the middle could be. Usually, by the end, it becomes quite obvious.

You also discover more about that thing: you might have had an idea up front, but often, the purpose or necessity or real trick to what you’re doing comes to you whilst you’re doing it – you find new uses or reasons or utility just by holding this stuff in your hands.

You’re creeping up on a kind of thingness. Intervalometerness, for instance. It’s important in the making process to understand that final thing as a thing in its own right.

Becuase really, I don’t think it’s important that it’s an “Arduino That Does X”. We care, it’s nice to talk to other craftspeople about how you made a thing, but really, it’s just a thing. I want to show it to people and explain it to people because it’s an exciting object that didn’t exist before, not because of the componentry inside.

You’re not making An Arduino That Does X.

You are Making an X.

So, you know, nobody cares about what you can see here – a dangle of cables and electronics. It was useful to take a first timelapse with, but come on! It needs finishing!

Make it releasable/understandable, don’t just leave it hanging. Aka:

Once I’d got everything working, I rebuilt it. This took almost as long as getting to that point.

I put it onto an Arduino Pro Mini, so it’d fit into a sensible box, and built a new circuit board. I made everything connected with headers and sockets – so I could take it apart easily but leave it in a finished state/shape. (This turned out to be a really smart move, even if my soldering of headers was rubbish; it meant taking it apart time and time again was quite easy).

Then I went back to my original sketch and tried to mount it all up: cut some holes in the box, line it up, job’s a good’un.

No, not really.

Boxes chewed me up and spat me out. It was harder making a box – pacakging it – than the software and electronics for me.

Look at that box – it’s an ugly mess. That’ll teach me – but at least I tried. And now I respect packaging – and boxes – a bit more!

Keep it small. One thing I’m increasingly sold on (given lack of free time) is that the easiest way to get something finished is to make it small enough so that you can. Set your own brief specifically so it can be finished. not having a head full of unfinished ideas.

There is a space for ambitious projects, but small can also be good. Small isn’t limited; I’m not talking about “minimum viable product”; small can be maximal! Small can be the right amount of stuff! This is why I began working on small ideas, even though they’ve often ended up taking ages, like the intervalometer.

A friend once described James Bridle as the best developer he knew not for the quality of his code but for the sheer ratio of ideas had to things finished. Which is a really, really useful metric: how much you get into the world. And sometimes, James does that by making tiny things.

Well, I think it does, anyway. That’s why I enjoy making something out of nothing so much: you discover other things on the way. Not just “how to do a thing” or “how a library works” but actual purpose, meaning, significances you don’t see. And this is recursive! We have a purpose going in, but it changes and shifts; we find out what we’re doing by doing it. That’s hard to get your head around, but important.

Building the intervaometer led to shooting timelapses, which led to writing software to display them, to a project that uses the Kinect to scrub through them. All these ideas, I definitely didn’t know how to make when I began.

Here, I showed a demo of using a Kinect to scrub through timelapses, which you can see a still of.

So really, there’s a slight lie at the beginning – we never know how to make anything when we begin work. We might know some techniques – everything from how to solder, to how to code, to how to knit, to how to research well – but so often, no-one’s made the thing in front of us. Maybe they’ve made something similar, but there’ll always be something unique.

And so what I have to do to learn – and do my best work, usually – is take a step into the unknown. Take a bit of a risk. Push myself a bit, and trust that I am a competent adult and can do things and at worst, follow instructions or ask for help.

You probably all know that I’ve been lying to you since I began the talk.

Well, not lying. But this statement – “making things you don’t know how to make” – is a tautology.

Making things you don’t know how to make is making things. So the reason you should keep making things you don’t know how to make, is the value of making something you see in your head – that’s the best way to learn stuff. Making those mental pictures real. So, you know, keep taking that leap.