Welcome to Clubhouse's "Meet The Software Engineer" series, where we interview software engineers about their background and what they're working on! Erica Kantor is a Senior Software Engineer from Slice, a company that "connects makers and eaters to enrich their lives through the power of specialization and pizza expertise."
I think I knew probably in my late 20s. I’d gone through a lot of careers and nothing was interesting. Writing code was the only thing that kept my interest.
I was bored at a job and, in a two-week span, a bunch of people happened to ask if I had ever thought about programming for a living. I looked into it, did some Googling and realized it was something I could do.
I had studied coding as part of my graduate degree in Instructional Technology and Media. I realized I wouldn’t be able to get a job with what I knew, so enrolled in a General Assembly boot camp and took an immersive Software Engineering course there. From there I got my first job at Ticket Evolution, then my second job at Slice where I’ve worked a myriad of roles over the past 2 and a half years.
Going to GA was really useful. It taught me a bunch of different languages and how to write code in a professional environment. We learned a lot of best practices and tools which we would need in our day-to-day.
I had created some personal projects beforehand but the first piece of “real” software was at Ticket Evolution working on their API ticket brokers, and an admin tool for their internal team. It was the first time I’d seen a codebase with an insane amount of code and got to get my hands dirty working in it.
I’m pretty easy going when it comes to technology and languages. I like to use the right tool for the right job and will learn a new language if I need to. My approach is to focus on breadth over depth; I know a good amount about a lot of languages rather than being really good at a specific one. I’m a full stack engineer but have gone “both” ways throughout my career.
One thing I’m very stubborn on, however, is my code editor. I’m an avid Vim user and my personal setup is so crazy, with so many customized shortcuts, that I can’t use other people’s.
I always add extra time because something always manages to come up. Also, I never give stakeholders an estimate without talking to the team who has worked in that codebase or language before. Talking to others about the codebase helps identify any unexpected complexities or roadblocks.
I never give stakeholders an estimate without talking to the team who has worked in that codebase or language before. Talking to others about the codebase helps identify any unexpected complexities or roadblocks.Erica Kantor, Senior Software Engineer at Slice
The main thing that I like to do is refactor code to make things easier to understand. There’s always tech debt so I try to prioritize the biggest pain points, the biggest points of frustration, and fix those. I start by restructuring the code to make it more readable then work on making it more efficient.
One thing I struggle with though, is I find it hard to know when it’s time to just cut my losses and replace the code, rather than trying to refactor and fix.
Slice is a double-sided marketplace for consumers and restaurants to assist with ordering pizza. I have worked on almost every product we have that’s web-facing including our consumer-focused applications, consumer-facing partner landing pages and also some of our restaurant-focused products, which owners use to manage their business.
It’s two-fold: the mission and the team. Our CEO, Ilir Sela, is very dedicated to helping local pizzerias and stay thriving in an environment where it’s hard to survive as a small business. Also, I work with a fantastic team; the people here are like family.
We’re around 50 engineers. That includes iOS, Android, web, DevOps, QA, and data. The team is based across three countries: the US (both remote and in-person); Northern Ireland, where around half of our engineering team is based, in Belfast; and Macedonia, where we have three offices. Our offices in Macedonia are mostly for other teams, but there are some engineering and QA folks too.
Ruby on Rails, React, Python, Node.js, Go, Kotlin and Swift.
The majority of the stack is Ruby and React. Most of our newer products are Node based apps with a React front end.
I like that the stack is constantly evolving. We’re improving some of our legacy apps, and improving our infrastructure with tech where we’re taking some risks. For example, we just wrote our first service in Go. We needed something that was fast, which is why we chose to use Go. I thought that was a cool decision.
We do two-week sprints with continuous deployment.
We have stand-ups every day. Some are async over Slack and, for about three days a week, some are in person over video. With the time difference between our locations, having stand-ups gets a little complicated.
The team runs with what we feel works given the situation but, most of the time, we stick to some sort of sprint schedule and continuous deployment of small incremental changes.
We switched to Clubhouse two years ago and, what was cool about is that it allowed us to standardize our boards and change our team processes. Each team has evolved away from that slightly to fit whatever they’re working on, but we still have visibility into what everyone is working on.
The biggest pain point we have is different ideologies. We’re coming from a diverse set of backgrounds, countries and time zones. So, we often find ourselves debating the right direction for a specific project. Usually, we’re able to come to a decision through discussion and compromise.
We have become good at having productive conversations asynchronously, using various technologies (including Clubhouse), and moving things forward.
The biggest pain point we have is different ideologies. We’re coming from a diverse set of backgrounds, countries and time zones. So, we often find ourselves debating the right direction for a specific project. Usually, we’re able to come to a decision through discussion and compromise.Erica Kantor, Senior Software Engineer at Slice
If a bug has anything to do with the main ordering flow i.e. between a customer browsing a menu and the restaurant fulfilling the order, we drop everything to work on that.
When it comes to features, the teams are split evenly between being focused on restaurants and focused on the consumers, which gives both equal attention. Most of the time we balance feature requests by sequencing what those two sets of customers need.
Most feature requests come from internal stakeholders (i.e., sales, marketing etc.) who work with product management to narrow that down. Engineering then acts as a mediator or arbiter to figure out how/if this benefits both sides of marketing place, or identify what we can do to bring value to all partners. We’ve determined that having happy restaurants and happy consumers make for the best experience for everyone.
How complicated pizza can be. A lot of people think pizza delivery is so easy but integrating with pizzerias, that use technology like fax machines, is a challenge.
A surprising amount of our infrastructure is around telephones and fax machines, which is something you don’t see all that often. Obviously, we are building new things to help move them away from those systems, but we’re there for the restaurants and whatever works for their business.
A surprising amount of our infrastructure is around telephones and fax machines, which is something you don’t see all that often. Obviously, we are building new things to help move them away from those systems, but we’re there for the restaurants and whatever works for their business.Erica Kantor, Senior Software Engineer at Slice
I use StackOverflow. I’m not much of a big social media user; I utilize my coworkers to send me articles that I find interesting.
My former manager, Brian Guthrie. He’s a great teacher and advocate, putting people first. I really admire his conviction in writing good clean code and helping people develop their skills.
Brian told me to always trust your instincts. If you have a hunch, follow it. There’s probably something there and, even if there’s not, you’ll probably learn something along the way.
Make it work then make it right. As engineers, we spend so much time thinking and overthinking problems when, in some cases, we should focus on solving it first.
As always, there are exceptions to that rule.
Make it work then make it right. As engineers, we spend so much time thinking and overthinking problems when, in some cases, we should focus on solving it first.Erica Kantor, Senior Software Engineer at Slice