What I Learnt Running a Hackathon
I was curious about using Catalyst to build a Mac app, so the next day we ran another hackathon. By the end of the day, we had an iPad and Mac app, too.
There were a few UX and other problems that required a couple of days more work, but launching a new app for two platforms is still a great outcome from these hackathons.
In addition to having some new apps out and learning some things, like Catalyst, there was also an important meta-learning for me. I had worked for many years at a company that has extremely high standards for code quality. So I adopted (to some extent consciously and to some extent not) the belief that that’s how you succeed. I did learn soon that better code quality is not always good, and it’s more about achieving the desired result with acceptable code quality. But I had lost this muscle after almost a decade of unuse, and disapproval whenever my code didn’t meet my former employer’s exacting standards. Even when I told myself to do it quick and dirty, my deeply ingrained habits kept reasserting themselves. It’s almost as if I was programmed to think and act in a certain way.
But doing it quickly is an important skill if you’re running or working at a startup, where taking too long to deliver a gold-plated product will kill your startup. Or if you’re a consultant — we just finished an engagement with a client who wanted an MVP, and he said the time to invest in code quality is if people use it. Or if you’re an advisor, where you can’t give good advice otherwise.
In general, keep playing with things without feeling the need to justify it to yourself via some kind of a plan. For example, I might be writing an app that converts videos to HEVC and photos to HEIC. It will be command-line. It will meet my needs. I asked a good friend whether I should be doing it, and he said we should do it only if there’s a sufficient market for it, and no competitors already meeting those user needs. Then there are other requirements about marketing, UX, meeting needs of other people than you, performance, compatibility, and so on. But when you raise the activation energy so high, you won’t be able to do hackathons, and you fall back to perfectionism.
Earlier, I’d have said, “No, I’m not interested in Mac programming.” But while a month-long Mac project would not be a good use of time, a day-long project definitely is. It adds another tool to my toolbox. Don’t always think top-down. Also grab some bottom-up opportunities when they present themselves without being too lost in your plans.
It’s fine to play with stuff as long as you limit the time to say 10% of your total working hours. And as long as you’re clear and disciplined about time, rather than getting carried away and saying, “If only I spent a month on it, it has a chance of taking off”.
In summary, I learnt some specific things from the hackathons I ran, in eng, UX and product. But the more important lesson is the need to allocate some time to keep tinkering and improving myself, which is an investment that will yield returns over the long-term.