Work remote and enjoy life![/caption] All that being said, "good" hackathons do exist. These events, usually run or sponsored by big companies sensitive to the pitfalls of overworking people, are designed specifically for competitive reasons (or held for fun). Hackathons can help developers land jobs, too. While nobody is going to win a hackathon and land a CTO job straight away, bigger events sponsored by large companies can – and have – led to jobs. But some big-company hackathons can turn out poorly for developers, as well. For example, a 2013 Salesforce hackathon raised many questions about favoritism and event "fixing." Finalists were chosen behind the scenes, and the winner may have purposefully broken a rule. Moreover, Salesforce might have been well aware that the winner didn’t deserve to land in first place, but awarded them the prize because the underlying code was useful to Salesforce itself. One Medium post hints that the event was essentially a ruse, trading pizza for a reporting tool. Hackathons aren’t bad. Companies such as Google have morphed the hackathon concept into the famed 20 percent time, where employees are encouraged to work on projects that excite them (and are potentially useful to the company, as well). Other tech companies simply shut down for a day or more to encourage internal hackathons, which can yield interesting code and lots of fun. For developers, hackathons can prove a good way to network, learn in a team environment (if you have more senior teammates), and generally get some experience under the proverbial belt. For those who do well under pressure, it’s also a good bit of fun. ‘Fun’ may also be the only reason developers should bother with hackathons. Jobs via hackathons are few and far between, there’s no lasting notoriety, and prizes are usually more ceremonial than beneficial. Fun should also be leisurely; maybe a 48-hour slog is a framework that hackathon sponsors should abandon. Is It Time to Rethink the Hackathon?
A hackathon can be a thing of beauty: A bunch of developers anxiously trying to solve a problem, typically against a clock, competing with other devs or teams – it’s electric. But the whole thing may also be toxic. If we’re being honest with ourselves, it’s sometimes the culture of hackathons that prove most attractive. Movies like "The Social Network" romanticize the ‘go big or go home’ competitive nature of these events, and glorify the socialization that sometimes occurs between participants. But in reality, hackathons are just a bunch of developers and/or designers working too long on a project they’re not familiar with, eating poorly and getting snippy with each other. Even without the "cool factor," the hackathon is still a good concept turned against itself. There’s often no widespread glory, either; hackathons may only prove relatable or important to a certain group, or enticing in a particular city or at an event. Plenty of developers are anti-hackathon. A recent Reddit thread underscores why: hackathons spit out half-baked products, little is learned in the truncated timeframe, and the platform is sometimes self-serving for sponsors. Developers usually walk away exhausted with little or nothing to show for it. The very concept of hackathons also runs contrary to recent trends in tech. The Dice Salary Survey shows developers are increasingly aware of their work-life balance, and value things such as vacation time or the ability to work remotely more often. Developers aren’t really interested in taking their bodies and mind to the bleeding edge for glory anymore. [caption id="attachment_138950" align="aligncenter" width="2048"] Work remote and enjoy life![/caption] All that being said, "good" hackathons do exist. These events, usually run or sponsored by big companies sensitive to the pitfalls of overworking people, are designed specifically for competitive reasons (or held for fun). Hackathons can help developers land jobs, too. While nobody is going to win a hackathon and land a CTO job straight away, bigger events sponsored by large companies can – and have – led to jobs. But some big-company hackathons can turn out poorly for developers, as well. For example, a 2013 Salesforce hackathon raised many questions about favoritism and event "fixing." Finalists were chosen behind the scenes, and the winner may have purposefully broken a rule. Moreover, Salesforce might have been well aware that the winner didn’t deserve to land in first place, but awarded them the prize because the underlying code was useful to Salesforce itself. One Medium post hints that the event was essentially a ruse, trading pizza for a reporting tool. Hackathons aren’t bad. Companies such as Google have morphed the hackathon concept into the famed 20 percent time, where employees are encouraged to work on projects that excite them (and are potentially useful to the company, as well). Other tech companies simply shut down for a day or more to encourage internal hackathons, which can yield interesting code and lots of fun. For developers, hackathons can prove a good way to network, learn in a team environment (if you have more senior teammates), and generally get some experience under the proverbial belt. For those who do well under pressure, it’s also a good bit of fun. ‘Fun’ may also be the only reason developers should bother with hackathons. Jobs via hackathons are few and far between, there’s no lasting notoriety, and prizes are usually more ceremonial than beneficial. Fun should also be leisurely; maybe a 48-hour slog is a framework that hackathon sponsors should abandon.
Work remote and enjoy life![/caption] All that being said, "good" hackathons do exist. These events, usually run or sponsored by big companies sensitive to the pitfalls of overworking people, are designed specifically for competitive reasons (or held for fun). Hackathons can help developers land jobs, too. While nobody is going to win a hackathon and land a CTO job straight away, bigger events sponsored by large companies can – and have – led to jobs. But some big-company hackathons can turn out poorly for developers, as well. For example, a 2013 Salesforce hackathon raised many questions about favoritism and event "fixing." Finalists were chosen behind the scenes, and the winner may have purposefully broken a rule. Moreover, Salesforce might have been well aware that the winner didn’t deserve to land in first place, but awarded them the prize because the underlying code was useful to Salesforce itself. One Medium post hints that the event was essentially a ruse, trading pizza for a reporting tool. Hackathons aren’t bad. Companies such as Google have morphed the hackathon concept into the famed 20 percent time, where employees are encouraged to work on projects that excite them (and are potentially useful to the company, as well). Other tech companies simply shut down for a day or more to encourage internal hackathons, which can yield interesting code and lots of fun. For developers, hackathons can prove a good way to network, learn in a team environment (if you have more senior teammates), and generally get some experience under the proverbial belt. For those who do well under pressure, it’s also a good bit of fun. ‘Fun’ may also be the only reason developers should bother with hackathons. Jobs via hackathons are few and far between, there’s no lasting notoriety, and prizes are usually more ceremonial than beneficial. Fun should also be leisurely; maybe a 48-hour slog is a framework that hackathon sponsors should abandon. 
