Working at a startup is different from working at a big business, or even an established small company. Startups are fast-paced and unpredictable — you never know quite what will happen next, and sometimes the ground shifts out from under you. There's a lot of trial and error, which is a big part of what's fun about startups. You can just do things and discover what works.

Recently I sat down with Pete and Moe, two of Hedgehog's frontend engineers, to learn how they approach contributing to the grand experiment that is Hedgehog. If you want to listen to our conversation, please do! We recorded it to share:

audio-thumbnail
Chat with Pete and Moe
0:00
/18:25

Otherwise, read on 👀

Pete Schreyer was employee #1, the first to join after the founders, and now he's been at Hedgehog for two years. "It's gone by like a blur," he said. Moe Abdrabou joined about a year ago, and he specializes in design as well as code. Pete joked that frontend development had "two major phases: pre-Moe and post-Moe. The quality has improved quite a bit since Moe came on."

That's the first tip: Appreciate your colleagues and what they bring to the table. Go Moe!

Get started without getting overwhelmed

I asked the guys how software engineers go about building a new product. What's the procedure for "breaking ground," so to speak?

According to Moe, the best way to start is with a technical spec from the business side. You should know what the product is supposed to do — that's the first step. After all, if you don't know what you're building, it's going to be an extra challenge to build it.

Next, create a design language and wireframes, using a tool like Figma, to sketch out how the functionality should flow and what the UI should look like. At this stage you have a lot of freedom and flexibility, which makes it easier to change your mind or try out different solutions. Only then, after making the majority of design decisions, should you start writing code — either the frontend first or the backend first, or both at once if you have the requisite manpower.

"That would be the ideal process," Moe said. "Sometimes the development process itself doesn't allow you to have time to design first. I would recommend to anyone to design first, that takes [care of] a lot of questions to be answered during the development time." When you design first, you can work out kinks and move things around easily before committing (pun intended).

Today Hedgehog is design-first, but it wasn't always the case. Like Moe said, there's the ideal process… and then there's the reality of what you can tackle with the resources you have at the moment. The earlier days of Hedgehog were a bit more chaotic.

"Our CEO Taylor is a whirlwind," Pete explained. "That man can crank out some code. I was stunned. When I first came on I was used to kinda corporate slow-moving, talk to the designer, go back and forth with the designer a few times. But when Taylor latches onto a new style he likes, he will redesign the entire app in the course of two weeks. So, it's just unbelievable. I was not ready for that."

When I first started, we kinda just designed on the go, and I was getting up to speed on everything. There was no Figma, or any designs that I remember. I was just copying his style. And then when we decided okay, we wanna do this version 2, this cool new exciting version 2, then we implemented Figma, where we started building out the designs way in advance, for the web app actually. I think around that time we hired Moe. I'm not super good at design, so I was just so relieved that Moe was here and able to pick up that slack that I was leaving.

I asked what aspects of the development process have been most difficult so far. Pete reflected, "The biggest issue — we're struggling with it less now that things are stabilizing — the biggest issue we had for quite a bit of time was the backend and frontend getting out of sync in terms of what we expected the data to look like. It was really challenging, 'cause it'd be totally broken for a bit, we'd have to do a weird setup where we'd have to be on one database seed, one branch of the Rust code, a different branch, just doing all this special stuff just to get it working. That's thankfully settled down a bit. We had like a week where our providers all crashed on different days."

"Just normal software stuff," he chuckled. "Our backend guys have been doing a wonderful job."

Be as annoying as necessary

Naturally, the frontend and backend code need to talk to each other. For that to happen, the frontend and backend engineers need to talk to each other. Currently Hedgehog consists of 12 people, which might be the size of a single team at a larger company. But we're also completely remote with a high-autonomy culture. To counterbalance the tendency for everyone to go off and do their own thing, we need to be intentional about syncing up regularly.

"The soft skills, that's one of the good things to have outside of being an engineer," Moe said. "One of the key features of success literally on any team is communication." In other words, knowing how to write code isn't enough — it's important to understand which code to write, and for that you need to stay in the loop with your teammates.

"Like Moe said, communication is unbelievably important," Pete agreed. "I think when I came onto the team, I was used to the more corporate culture where you do things more formally. But [at Hedgehog] we move really quickly, so you have to not be afraid to be annoying. I struggled with that at first, but now I constantly pester people if I need something from them."

"I'm not perfect obviously, but I pester a lot more than I used to, I'm not so afraid of being annoying." — Pete

Hedgehog has needed more organization and structure as the team has grown, to keep everybody coordinated. "As of three months ago, we only had one meeting a day, one formal meeting," Pete pointed out. "We all felt a little bit siloed, so now we have multiple meetings per day, and I find myself in meetings much of the day now, versus before I was just working independently, and communication stuff would get lost." (Most of these meetings are "parallel play" coworking sessions.)

"I'd end up doing something that somebody else had worked on, just the stuff that happens when you don't communicate. Now we're a lot smoother in terms of stuff like that."


Even after those recent changes, working at Hedgehog still entails a great deal of independence and individual responsibility, offering ample opportunities for personal development. "These past two years I've grown more in my capabilities and leadership skills, more than any other point in my life," Pete said.

Moe shared a word to the wise, both for newbies and experienced engineers: "Keep up with technology. Especially in our field, every day there's something new, and technology keeps evolving every single second. Keep up, and every day focus on yourself more and study more."

Writing code for a startup is exciting, a challenge in creative problem-solving. You must think quickly and work around constraints, often with limited resources and time. You also need to be able to manage yourself, and potentially work on multiple tasks at once, all without losing track of the team's larger goals. For the right type of person, that environment is a dream come true. And the code you write could potentially make a huge impact… which is what we're shooting for at Hedgehog!