Hackathons are a great opportunity for developers to work on fun projects they normally wouldn’t be able to work on. There are also many habits developers employ during a hackathon that they should bring to their professional work more often.
I don’t suggest pulling all-nighters and consuming nothing but energy drinks during the workweek (or ever, really). However, here’s are a few things developers do during hackathons that I think they should do more while working their day job.
Hackathon Habit #1: Be unafraid to break things (a.k.a., do more spikes).
Hackathons generally involve no test coverage, bad error handling, and little-to-no peer review. Despite this, developers are generally much more willing to attempt wild ideas that may not work during a hackathon.
Because our day jobs involve better standards, developers should be more willing to try wild ideas. Sometimes there is a place for meticulously planning what should be done and assessing the potential effects. A lot of the time, though, the best way to find out if something will work is to just try it.
Hackathon Habit #2: Be more willing to try new tools.
When starting a new project or approaching a new problem, many developers default to using tools they’re already familiar with. While this can result in things going exceptionally smoothly, developers can miss out on a lot when they go with the same old tools they always use.
Using new, unfamiliar tools has several benefits. Most importantly, it gives developers an opportunity to learn new things. Even if the new tool doesn’t end up working out, you will still walk away having another tool under your belt. You probably also learned new things you can bring back to the tools you were already familiar with as well.
Hackathon Habit #3: Feel more ownership over your work.
Finishing a hackathon project feels deeply satisfying. You’ve come up with the idea yourself, designed it yourself, and developed it yourself. While you may not have as much control over a hackathon project as you do your day-to-day work, you can still create a sense of ownership.
Writing code you feel ownership over will help you focus more on quality and help give you that feeling of satisfaction when completing it. You will feel more motivated, more focused, and, hopefully, you’ll have more fun too.