Joe LeBlanc has spent nearly 20 years in software engineering fulfilling a variety of roles: freelancer, book and video author, speaker, open-source contributor, and conference organizer. He is currently a Software Engineering Manager at FORM on the FieldConnector team, which produces a digital communication tool for frontline workers across multiple industries. Advocating for an “investment mindset” when approaching a career in software engineering, he also writes at codelikeaninvestor.com. 

Your VP of Engineering has just announced the dates for the next company hackathon! Are you excited? Are you dreading it? Are you curious? All the above?

I’m gonna level with you here: I hate them. I hate them as a software engineer. I hate them as a manager. I hate them!

As a software engineer, I am swamped. The ticket I was sure would take two days has taken four. I am still almost done with it. Docker is misbehaving again and I have no way of bribing it. I want to see this work through to the end, but I may have to bail if it takes any longer.

As a manager, my team and I have prepared sprints of tickets. We are working together to deliver on a quarterly roadmap, then a hackathon is announced. We now have to yet again replan everything. Scope gets cut on features our clients and stakeholders are clamoring for.

And what is the result of these hackathons? A hastily assembled demo that is 80% working at absolute best. It’s never production ready and unit tests are completely missing. Then the CEO decides they love that feature and really, really, really want it in production. So you and your team are trying to figure out how to ship this half-finished feature. 

Oh and by the way: you still have to deliver on that quarterly roadmap.

In the end, hackathons are a form of gambling. Engineering hours are thrown into the slots. We hope for a jackpot of shiny new features. But we almost always walk away stressed out, exhausted, and empty-handed.

It does not have to be this way. We are not gamblers. We are investors.

What can you do instead?

Instead of a wasteful hackathon where nothing is shipped, what about viable alternatives? What are ways engineers can develop their careers without jeopardizing project timelines? Here is a list of seven alternatives you can introduce. Try a few, or try them all!

1. Volunteer coding

Want an event that is like a hackathon, but for a cause? Many engineers want to write code and make a difference. Organizations like Code for America and Ruby for Good are fantastic for this! These organizations pair software engineers with worthwhile non-profits. Then they host events where engineers write code for them. 

If your company is new to volunteer coding, you could have some of your engineers attend one of these events. Many events fall on weekends, so you could give your engineers a day off on the following Monday to rest up. If your company offers volunteer days off, use them!

Even if your company does not offer volunteer days off, see about offering a recovery day. It would take fewer workday hours than a typical hackathon. And then your engineers would arrive back at work energized and refreshed. Even if they don‘t take a day off, engineers get the satisfaction of shipping code for a cause.

2. A day off for self-directed learning

You may have a web engineer who has always wanted to dip their toes into data science, but never has the time. Or you may have a DevOps engineer who wants to learn CSS and JavaScript. Or you could have an engineer who would like to try functional programming instead of OOP.

None of these skills may necessarily have an immediate impact on your engineers. But having time to explore off-topic topics can help them learn new approaches. 

3. Fix-it time

Engineering managers continually face the problem of how to prioritize bug fixes. There is a balancing act between fixing product bugs and maintaining the platform. Many important tasks get pushed to the side because the scope is either large or unknown.

What if your engineers had a day to put time into bigger bugs and technical investments? Getting regular “fix-it” time on the calendar can make this a reality! 

When several engineers join in the same “fix-it” time, the effect multiplies. They can tackle a list of tasks together, check in throughout the day, and pair program. If momentum is a priority, create a Kanban board (or even a spreadsheet) just for fix-it time. This way, engineers get the satisfaction of seeing the “Done” column fill. 

If the focus is on larger investments, a more experienced engineer can lead the session. Meanwhile, less experienced engineers swap between pairing and taking notes. Extensive writeups of thorny technical problems can be a guide for the future. Next time someone encounters that section of the codebase, there is already a map.

You don’t even have to use this time for big bugs and investments. Lots of smaller invisible investments can pay dividends for your engineers. Is there a warning that keeps appearing whenever you start up unit tests? Use fix-it time to find a way to address the warning. This not only addresses issues. It increases the likelihood other issues are not missed.

4. Hacky hour

Sometimes what your engineers need is some good mentoring time. Make time on the calendar so more experienced engineers can mentor them! A regular “hacky hour” is a good way of making this time available so engineers can get drop-in help.

Making it a drop-in event makes it possible for engineers to get help on places where they are getting stuck. This is also an opportunity to discover side issues. These issues may not be directly related, but are worth discovering and investigating. 

If more engineers show up, they can take notes while they observe other engineers pairing on code. These notes can then be posted in a Slack channel where everyone can review them later and learn.

5. Book club

Do your engineers want to learn more about a specific topic, like refactoring code? Starting a book club is a way of helping several engineers all learn together. Getting more people involved increases accountability. This increases the likelihood engineers will do the reading and any associated exercises.

Getting several engineers to all agree on the book will make it possible for you to bulk-order copies. Depending on the publisher, this can sometimes get you a group discount. Even if you do not get a discount, books are still a very affordable learning opportunity. 

After the book is selected, make sure there is an engineer who will lead the book club. This leader will ensure regular checkpoints happen and engineers are not getting overwhelmed. These checkpoints can be short, informal meetings lasting approximately 30 minutes. The leader can use feedback from these meetings to keep everyone on track. If people are falling behind, they can make adjustments to keep the pace appropriate.

6. Lunch and Learn

Book clubs are affordable learning opportunities, but they are high commitment. Also, many newer topics will not have books available right away. For these situations, Lunch and Learn sessions are a good alternative.

There are a couple of different approaches you can take for Lunch and Learn. One approach is to play a video and discuss it. Another is to have an engineer prepare a presentation. Both of these styles have their advantages and disadvantages.

For videos, archives of conference talks are readily available. A video that is approximately 30 minutes in length is ideal. You can also pick a longer one and break it up over several sessions. Videos take little effort beyond deciding which ones you want to watch. They also cover every topic imaginable. 

But videos do have disadvantages. The speaker will not be available for questions in real-time. You can ask questions in the comments section, but may not receive a response. Sometimes the recordings are poor quality, which can distort detailed slides. And you may discover only after the talk starts that it was not what you were anticipating. 

If you are willing to make the time investment, you can have one of your engineers prepare a presentation. This addresses the disadvantages of presenting a video. It also gives one of your engineers practice in giving presentations. Your engineer gets to share about a topic they are passionate about. And you have the opportunity to have the content tailored to your team.

Having one of your engineers present a topic is not without drawbacks. The quality of the presentation may not be the same level of a conference talk. And your engineer will need to dedicate time to researching and rehearsing. But this is a good learning opportunity for engineers giving the presentation.

For regular Lunch and Learn sessions, offer both video and presenter-driven sessions. Make sure your presenters are prepared. If they are not ready, either have video to fall back on or cancel the session.

7. Slack channels

A great way to help your engineers learn more is to create specific types of Slack channels. They are low-effort to set up and can help keep great discussions going throughout the year. Here are a few of the types of channels I have seen work well:

• Today I Learned (TIL) channels. This helps engineers share tools and tips they have learned in the course of doing their work. Sometimes engineers will not share about things they believe are “common knowledge.” Having the “TIL” channel helps because it encourages people to share regardless.
  
  
• Feeds channels. Slack has a not-well-known feature for automatically importing RSS feeds into a channel. This is helpful for staying up to date on official feeds of languages and frameworks. Your team will be among the first to know when there is a security update or a breaking change coming in a new version.
  
  
• Language/framework/tool-specific channels. These are especially helpful when your company has several engineering teams. There can be overlap with “Today I Learned” channels here, so be sure not to start too many channels too quickly.
  
  
• How can I convince upper management?

Now that you have this great list of alternatives to present, how do you get upper management on board?

Start with talking about time and money. Almost all these alternatives take less “engineering clock time” than a hackathon would. Several are low-effort and can be trialed without spending money. Start with a couple of the “cheaper” ideas and show success first. Then use that success to convince your company to sponsor higher commitment activities.

Next, find engineers who prefer fixing bugs and making technical investments over hackathons. Even if a hackathon still takes place, you may be able to find support for these engineers. This way, they can make better use of their time. Meanwhile, you can gather more data on the efficacy of hackathon alternatives.

Finally, stay persistent. If you are reading this post, you care about your engineers. You want to create an environment where they can excel. You want them to be free from needless distractions. You want them to avoid waste. You want them to feel like their contributions matter.

Big changes do not happen overnight, but you can start making a difference now. Start with the smaller changes and make your way up to the bigger ones. You’ve got this!