DIY, hackathons, and getting better at getting better
I’m spending a lot of time in the shop these days, trying to live the Maker Tank Manifesto!
Need a thing? Make a thing.
Break a thing? Fix a thing.
Learn a thing? Do a thing.
I’ve noticed a couple of interesting side-effects of that shop time:
Sure, I’ve re-primed my short-term memory to be able to recall the width of saw kerfs and the nominal vs. dimensional measurements of lumber and plywood.
But more interestingly, after three decades making software, I’ve begun to think in three-space again. And once again, as I did when I was machining prototype astronaut swag for a living, I’ve gotten comfortable thinking not only in spatial orientation, but also in a few extra dimensions—the steps, the order of the steps, and the tooling required to build whatever is in my head or on my workbench.
The Maker Tank workbench, with some emerging Fancy Handles
The net of this is that I’m starting to feel like a mechanical engineer again!
The reason for this transformation is explained by Hebbian Theory:
I knew that if I worked in my shop more, I’d get better at working in my shop. I knew this because I’m a believer in neuroplasticity. Hebbian Theory suggests synapses that fire together wire together.
I’m only a hobbyist when it comes to neuropsychology, but to me Hebbian Theory explains why I aced the Maths section of the GRE shortly after getting out of Georgia Tech; and it also explains why these days I need to pull up the calculator app on my phone to split a bill at a restaurant.
If you do a thing, you get better at the thing. Your brain is like a muscle, and it too needs exercise and training.
Because synapses that fire together wire together, and you just get better at stuff the more you do it.
And coming full circle back to making software, Hebbian Theory explains why a lot of companies get hackathons wrong…
For those of you who don’t know, Hackathons are “festivals of innovation.” Some Tech companies do annual or semi-annual hackathons as sort of a working vacation for their technical staff. I’ve had the privilege of comparing notes with a number of technology leaders through the years, and have accumulated a few data points on what hackathon means to companies. In my unscientific sample, about a third of companies use hackathon as a proxy for “please work on the problems in our backlog that we can’t actually afford to prioritize.”
The second third of companies use hackathon as a way to place a bounty on solutions to problems that are currently too poorly understood to prioritize—put differently, “please have an inspiration that solves this problem we previously thought was unsolvable.”
So, again with apologies for the unscience, two thirds of companies that do hackathons expect them to compensate for missing prioritization and decomposition of work already in the backlog. The efforts are still very much aimed at supporting their business. Which, don’t get me wrong, is just fine in so far as it goes.
But, some companies, and I was fortunate enough to work at one for several years, get hackathons right—hackathons should be about leveraging Hebbian Theory and turning engineers into better engineers. They should be about priming synaptic pathways for learning. They should be about getting better at getting better!
And in that world, tackling a tricky wood-working problem is as good as learning a new (spoken) language. Is as good as learning a new programming language. Is as good as prototyping a solution to your business problem du jour.
Because Hebbian Theory. Because learn a thing, do a thing. Because Maker Tank Manifesto.