DEV Community: Fellow Engineering

What is a Hackathon? (And How We Run Them at Fellow)

Alexander Polev — Fri, 20 Aug 2021 13:29:05 +0000

This article describes what a hackathon is, how they usually work, and how running these events can benefit your company.

What is a hackathon?

A hackathon is a friendly tech competition with a relatively short duration, usually 24 hours, with the main idea being “Just do something cool!”. It’s a perfect opportunity to step out of your comfort zone and try something new. Hackathons give you the chance to work together with people from other teams, use new technologies, perform interesting experiments, and showcase your creativity.

The main goal is to implement a working prototype of a project which can be presented by the end of the event. It takes more than just programmers and designers to build an amazing company and in a similar vein, hackathons are made even more impactful when the entire company gets involved. Project managers can pitch their idea for the next big feature, marketing specialists can explore new and innovative promo campaigns, customer success teams can unearth valuable insights from users, etc. The possibilities are limitless!

Hackathon projects don’t have to be something that will become the part of the product and be released soon. The spirit of the hackathon is to experiment and research, not just work on day-to-day tasks more intensely. To illustrate, I’ll show some examples of my past hackathon projects in the next section.

Last, but not least, an important part of any hackathon is lots of pizza and coffee 😄.

What do people do at a hackathon?

At the beginning of the event, everybody is thinking, discussing, sharing ideas and forming teams. At Fellow, our hackathon teams can range from 1 to 4 people which feels like an ideal size for a 24 hour project.

Teams are free to discuss ideas, brainstorm, and plan beforehand but the main rule is — “no coding, designing, or starting on the project until the day of”. Everything should be implemented during the 24 hour hackathon time period.

In general the ideas are limited only by your creativity, but for internal company hackathons, the ideas should add some value to the base product or help improve internal workflows at the company. So while training a machine learning model on pictures of your cat to highlight them on your webcam video is a fun project, it may not be the best idea for this type of event. Don’t worry, everyone will still know that your cat is cute and awesome 😺.

In my personal experience at Fellow, I don’t work with the note editor all that often so the hackathon gave me a chance to learn about and work on a new part of the product. I implemented a small typeahead plugin to insert emojis into a note and the project eventually ended up going live in production! Now, you can type the colon symbol, start typing an emoji name, and you will get a list of relevant emojis:

Once the project is complete, next comes the most important part: presentations and voting. To keep things brief, each team is only given 10 minutes to present. They need to describe their project, highlight advantages, demonstrate functionality (in the case of a prototype), and explain the value to the company. Of course that’s just a generic presentation structure. A hackathon is a highly creative environment, so nobody minds if you make your presentation full of memes and puppies 🐶.

After all the presentations are complete, everybody casts their votes for the winning projects and prizes are awarded.

The benefits of participating in a hackathon

The most immediate benefit is the opportunity to have fun and choose what you want to work on. During hackathons, you aren’t solving business problems directly or working on routine tasks. You are working on something you find interesting and organizing your day and workflow based on how you want.

Hackathons are also a great environment to work on your soft skills. Participants can obtain new management skills such as delegating tasks, planning presentations, and writing more clearly. Since participants are usually working in smaller and unfamiliar teams, it’s also a good opportunity to improve communication skills while getting to know the different parts of the company.

The greatest benefit of all is the educational experience. You may try using new technologies, work on a new part of the product for the first time, or just challenge yourself to think really big. You might be wondering “Can I really do this in 24 hours? Should I narrow my idea?” but don’t be afraid to take a chance. Hackathons are a space for growth and experimentation so don’t let the fear of failure stop you from making the most of your experience.

Last, but not least, hackathons are a great way to bolster team camaraderie. At Fellow, one of our main company values is Fellowship. Our recurring hackathons help us realize our values and increase team cohesion.

Why managers and leaders should organize hackathons

Okay, it seems like hackathons are good time for employees since they get to dedicate 24 hours to fun and education, but how can they help business owners?

First of all, hackathons are a great source of new ideas and uncommon solutions. Usually, projects guided by senior management and new features are all planned by the same group of people. Hackathon projects are new ideas with basic implementations, and after some polishing, are ready to ship to production. Leaders often find themselves thinking, “That’s actually a great idea I never thought about that. Let’s ship it!”. At Fellow, almost half of all hackathon projects find their way into the product some time soon after the event!

Secondly, leaders should consider hackathons as a long term investment in their team. Dedicating two whole work days to a hackathon might sound like a poor use of time, but it will payback dividends in multiple ways. Hackathons help introduce new ideas and approaches, they increase collective knowledge of the codebase, and they foster a friendly team-building atmosphere within the company.

Finally, the unique combination of education and team-building experienced during a hackathon help prevent employee burnout and keep people engaged and fulfilled by their work.

Conclusion

For us at Fellow, hackathons have become an important part of the development workflow. Of course, they require some planning and organization like choosing the right time for the event to make sure core business operations aren’t negatively impacted. At some companies, it’s not always possible for everyone to stop what they’re doing to devote time to a hackathon. One solution would be to split the company and organize two events at different times, whatever needs to happen to make the hackathon a reality. The benefits become clear when more and more ideas that started off as simple “hacks” turn into business successes.

I hope this article will motivate you to organize hackathons at your company and embrace a culture of research and experimentation, which will help make your team more productive and lead to greater success for the business as a whole.

Managing Browser Extension Versions with Gulp

Rachel Harrison — Fri, 20 Aug 2021 13:27:43 +0000

How did we get here?

While developing the second version of the Fellow browser extension, we realized that our current solution for managing the extension for our different environments — finding and replacing all relevant variables in the code before uploading packages — was getting to be too much overhead. In the first version of the extension, the only place where we needed a different value for each environment was for the source URL of an iframe, which was easy to switch out manually when needed for local development, our staging environment, and production, as we could do it right before uploading the extension to Chrome or Firefox.

As we added more features to our extension, the list of places we needed to swap out URLs grew from one to three. Still, we managed this manually as we only had to do it a few times. There were a few developers working on the project, and we all changed the URLs back to match our staging environment when committing code. Then before uploading our extension for approval, we swapped them out for production. We knew this solution was far from ideal, but with only three places to swap out values and only a handful of developers who needed to remember where to swap them, it worked fine.

Then things got more complicated.

By the time the bulk of the development was done on the second large iteration of the extension, there were a dozen places that we’d need to swap out values. Additionally, it was no longer just the environment URL that we had to change — we also had a value to get the correct cookies, and another that acted as a flag for functionality that we needed only in our local environments. On top of that, with our extension now being a more robust project that was really taking off, it wasn’t hard to imagine that soon even more developers would need to run the extension locally to contribute to its development. The overhead of documenting all the spots to swap values, and which values to swap them with, would have been hard to maintain and lengthy to execute.

One half-measure would have been to pull all the values that needed to be swapped out of their files, and instead export them from a global config file. This solves the issue of having to document (or remember) all the places where values need to be swapped, but is still more overhead than we’d like. We’d still need to document somewhere what those values are for each environment, and generating the extension for a new environment would still involve editing a file.

Then we found a solution that allowed us target a specific environment for the extension with one command. Using Gulp we can run a command like gulp — config STAGING and we’ve generated a directory with a version of our extension targeting the staging environment, ready to upload.

How does it work?

In the end, it’s really just a fancy version of the config file solution. All the values for an environment are placed together in a config file, one file for each environment. These are named with the name of the environment like config.STAGING.json. Then, when the gulp command is run and the environment is specified, a version of the extension with the correct values for that environment is generated and dumped into a specified folder.

The bulk of this process in defined in a file called gulpfile.js at the top level of our extension directory. When gulp is run this file takes the appropriate config file and dumps those values into a file called config.js. This file is where the values are imported from elsewhere in the code. This config file and all the other extension files are copied to a separate folder, ready to be uploaded.

So how does it do that? It defines four primary functions and executes them in order:

First it deletes any contents of the target directory, to make space for the newly compiled one.
Then it makes copies of all extension files, excluding config files, and adds them to the target directory.
Next, it selects the correct config file, based on the config flag passed when the command is run.
Finally, it writes the contents of the selected json file to config.js in the target directory. Once these four steps are complete, all the extension source code and a config file with values for the target environment are in a single directory, ready to be uploaded!

What else can we do?

We’ve already extended this basic concept in a few ways. In addition to creating config..json files for development, staging, and production, we can also create what I’ve been calling “on the fly configs”. These are config files to target rarely used environments, like sandboxes, or environments without consistent URLs, like the environments generated by our CI process. Unlike the other environments’ config files, these ones are not tracked in Git. Instead, they are intended to be short-lived files that are created when necessary and then discarded.

Another complication that arose surrounds the config file for local development. Every developer at Fellow has a different URL for local development. If I were to commit a config file with my URL in it, that wouldn’t be helpful for the next developer looking to run the extension to point at their local environment. Instead, the config file for local environments is not tracked in Git, but a file called config.template is. This template contains json to be copied to a local environment config file and populated with the correct values for that developer’s local setup.

There are also other applications for this than just switching environments! For example, we could add a flag like --browser and define different config files for Chrome and Firefox. Currently in our extension, the browsers only differ in one way: the path to use to import images. We’re checking if we’re in Firefox before adding any image so that we can import it in the correct way. Instead, we could define the path to an image for Firefox in one config file and to an image for Chrome in another, then use Gulp to generate the correct version of the extension for upload.

These are just a few ways we’ve already expanded our use of Gulp, and there are many other possibilities! It’s helped us improve our development workflow and has reduced the amount of things we need to remember. I hope these tips will help you out too, and am excited to hear about any other interesting use cases for Gulp with browser extension management!

For a larger example (including extra features such as watching files for changes, and a sample extension), check out this great post!

Hellow World

Alexandra Sunderland — Fri, 20 Aug 2021 13:25:47 +0000

Fellow Engineering Blog: The technology behind the platform that makes meetings delightful

No, that’s not a typo. Over the last few years, all of us here have typed the name “Fellow” over and over again — so many times that now every word that ends with “ello” is accidentally followed up with a “w”. Most of the time we catch it, but it’s one of those adorable mistakes that we like to have fun with once in a while, and gives a glimpse into the culture of the team.

Starting today with this new publication, we’re going to be making that mistake a whole lot more! Many members of the engineering team here have been contributing to tech blogs, giving tech talks, speaking on podcasts, and open-sourcing projects for a while now — because we love helping others learn, sharing the cool things we’re learning ourselves, and giving back to the community. We’re excited to launch this new Fellow Engineering blog as another platform for our team to do just that!

We don’t quite know what this blog will be just yet, but it will grow with us and evolve over time as we build out new projects and discover cool tech that we want to share with the world. The core of our platform (and the heart & soul of the technology behind Fellow) includes our collaborative notes editor, our calendar, and our integrations. While we may give a peek into how we’ve built those once in a while (join the team to get the full story), we want to start off by sharing our learnings about things like how to build a dark mode mobile app, or how to manage browser extension versions when you have multiple environments. We’ll also be writing about tech-adjacent topics too—like how to run engineering retrospectives, or why and how we run the best internal hackathons. And we may even have posts about product & design too!

As a team of engineers that loves to build and problem solve, we’re all figuring it out together as we go along. And that’s half the fun.

See you on the blog! 👋