When Merrill Bajana, one of our product managers and myself volunteered to take over the hosting of GumGum’s 5th annual Hackathon, it was pre-COVID-19. We began planning for an event in our Santa Monica office, but later made the call to go fully remote this year. We put a lot of thought into how to make 2020 the most successful Hackathon yet — here are some considerations and ideas for hosting a remote hackathon!

Image for post
Image for post

Building excitement

  • Website, hype video, Zoom background: We launched our Hackathon website with the help of our amazing designer Sebastien Shaeffer. The site features an incredible teaser video shot by and one of our actor-cum-engineer Florian Dambrine. We also had Sebastien put together a themed Zoom background, which we used in meetings leading up to the event.
  • Hackathon archive: We put together and then promoted a page that showcases each past Hackathon (teams, ideas, presentation videos, and winners) to give people an idea of how hackathons work and to hopefully inspire some new ideas.
  • Posts in our Slack chats: Leading up to the sign up deadline and event, we posted in our company channels. For example, this throwback style…

Image for post
Image for post

We have used Storybook to document our React component library for a while, and although we love it, we’ve had to use various addon packages and do some hacky things to get components to show how we wanted. Storybook has undergone some big versioning changes recently, so I sat down to upgrade everything from 5.0 to the latest version and see what changed.

After upgrading all of the storybook npm packages, I see that the config files have completely changed. I can remove .storybook/addons.js and .storybook/config.js

Instead, I need:

// .storybook/main.jsmodule.exports = {
stories: ['../_stories/**/*.stories.@(js|mdx)'], // adding mdx support here
addons: [
'@storybook/addon-knobs/register',
{
name: '@storybook/addon-docs', // new addon for docs
options: {
configureJSX: true,
babelOptions: {},
sourceLoaderOptions: null
}
},
]…

Image for post
Image for post

On Monday, April 23, GumGum held our first Women Who Lunch event. This recurring event was started to bring women from the tech industry into our office to share their story and answer questions from the women in engineering here at GumGum. Our first lunch featured Tricia Lee, the SVP of Product and Development at Sony DADC New Media Solutions. Tricia shared her story and answered our questions about career advancement, balancing your career with other things going on in your life, the best part of being a woman in tech (standing out and being unique!), …


Sanja Stegerer has been working at GumGum as a Data Scientist for past two years. She has worked on various parts of our Natural Language Processing systems. In the talk below, she explains one of the most important systems in GumGum’s NLP systems — The Threat Classification System. The Threat Classification System allows us to identify whether a page is suitable for advertising or not. If a page content has violence, sexual content, illegal acts, disaster etc. Advertisers do not want to show their ads on the page. In this talk, Sanja explains how exactly we make machines identify these issues. Besides the system explained by Sanja, GumGum also uses it’s propritory computer vision systems to indentify Brand Safety issues.

The talk was part of Women in Software Engineering meetup series.

We’re always looking for new talent! View jobs.

Follow us: Facebook | Twitter | | Linkedin | Instagram


At GumGum, my team builds and works on many React JS web applications. As the number of apps grew, we found ourselves writing the same code and components for each app. This is not ideal because we had to spend time writing similar code, and it was not centralized, so each variation might have slight differences.

A few things came together at once for our team:

  1. Our UI team created a design system that allowed us to use the same UI styles across all apps.
  2. We liked the concept of our BEM style library, but found it verbose to add so many class names on everything.
  3. We kept getting more projects quickly, so we needed to streamline our development process for fast prototyping.
  4. My team discovered React Storybook, a development environment for React components.

It all made sense — let’s create a shared component library!

  • We can import these components into each project.
  • Code is only developed one time in one place. …

I manage a team of 4 people responsible for 5 different web products, both internal and B2B. Inspired by a question from Out of Office Hours, here’s what a typical day might look like for me.

9:30am — Specific product stand up

I have 2 stand ups each day. The first is for one of our products. We have representatives from big data, computer vision, and web teams, and it is led by our VP of Product.

In a stand up meeting, everyone gives an update on what they did yesterday, what they will do today, and if they have any blockers. Ideally a stand up meeting with be very short — 1–5 minutes, so we table any discussions that arise until after the meeting. These quick meetings keep everyone on the same page and informed about what people are working on, so the product manager doesn’t need to constantly ask for updates. It also shares knowledge; if I find out someone is working on something I know about or have a question about, I can ask. We also get a business update from our VP of Product, which I enjoy hearing because I like to know if we have any new clients or feedback. …


As with most first time engineering managers, I headed down a road with not much guidance and hoped for the best. I armed myself with a lot of books, read a lot of blog posts, asked my friends what they liked and didn’t like about their managers, and reflected on my own experiences. Here’s some things I’m trying and learning in this WIP.

Prepare yourself mentally for the switch.

You’d think this would be obvious, but it was a shocking adjustment for me when I switched to the management path and realized, “hey, I have to talk to people all day now.” I went from sitting at my computer lost in code most of the day, to talking to people ALL day. Most days I finish exhausted from these interactions, but I look at my team and what we accomplish with the satisfaction of a proud parent. To avoid burn out, acknowledge the change and make sure you make time for yourself to balance it out. …


For a brand new developer, their initial contact with their very first tech job is crucial. They’re probably anxious, nervous, and unsure what to expect.

Here are some tips for new developers and their employers to help ease the transition, based on my experience with my first company which I think did a great job on-boarding and setting me up for success.

1. The Company

From day one, promote an open, collaborative learning culture

As part of my first company’s on-boarding process, we went over the company’s values, and as one of them, they stress a learning environment.

  • Questions and mistakes are ok.
  • What we know matters. What we’re learning matters more.
  • Mistakes are part of the learning process. …

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store