When Joe Mainwaring was in high school he participated in a robotics competition during which he got to meet retired Air Force Brigadier General Chuck Yeager. Joe was in awe of Yeager and his accomplishments. Yeager earned a reputation as a flying ace during World War II; after the war, he became one of the military’s premier test pilots and was the first person to break the sound barrier. At the beginning of NASA’s race to the moon, he trained most of the United States’ first astronauts. Joe cites Yeager’s attention and encouragement as being a driving force in his pursuit of engineering.
Today, Joe works as the Director of Infrastructure at Kazoo, creators of the leading all-in-one employee experience platform for human resources. In his position, Joe often spends his days looking for solutions to problems that the teams at Kazoo don’t even recognize they have, or problems that they likely will have if Joe doesn’t find a solution first. The key is always to be thinking ahead, not reacting, but rather watching, planning, and researching.
One area where Joe saw an opportunity for improvement was in onboarding new developers. Kazoo's product uses microservices, so when new engineers started working they needed to download three different applications to their local development environment and get them running before they could start writing code. Even for very experienced developers, it was an arduous task and took the better part of a day. Less experienced developers needed at least twice as much time.
Those times are significantly less than at many other companies, but Joe thought they could be better. After all, in 1947 when Chuck Yeager first broke the sound barrier few people thought humans needed to fly that fast, but some people like Joe and Yeager are always thinking ahead.
Joe had managed to receive an invitation to try the public beta of GitHub Codespaces and he enjoyed using it for personal projects. So he was familiar with the benefits of a cloud-powered development environment and how they could be used to spin up development environments in minutes rather than hours.
He also knew, though, that Codespaces wouldn’t work well with Kazoo’s infrastructure which is entirely GCP-based. Kazoo needed something that they could run on their own infrastructure.
While discussing the problem, a colleague mentioned that he used code-server for his own personal projects to access his development environment from anywhere and run VS Code in the browser. He also knew that the code-server developers had an enterprise product called Coder and suggested that Joe take a look at it.
After some research, a demo, and a trial Joe was convinced.
Coder checked the boxes:
“It's just pressing that button to spin up a new instance,” says Joe, “and then within less than a minute our engineers have access to their own workspace with VS Code.”
Kazoo’s engineers have embraced Coder. “They see this as a tool that benefits them,” explains Joe. “Hands down there.”
“I'm a multi-tasker,” says Lead Engineer Ryan Poe. “While waiting for PRs to merge or be read, I like to work on other PRs. Switching between branches requires frequent code rebuilds that would chew up my laptop resources. Coder has made me more productive by simply taking the responsibility of running and building code out of my poor lil' laptop's hands!”
Many developers are reluctant to switch to cloud-based workspaces, fearing that the experience will be too sluggish. Ryan disagrees. “Having my own box with 8 or more CPUs and 32+ gb of memory that only runs my dev server makes everything feel much faster than the local development experience.”
Joe also appreciates the freedom that comes with cloud-based developer workspaces. “I have an iPad with the Smart Folio case. I can do development on this using Coder,” he says while gesturing with his iPad. “I can't do local development on the iPad. So travel with this, you know, and still do coding if need be versus taking the 15-inch laptop, which is heavy and a pain when you're going through TSA.”
The issue of reducing onboarding time was Joe’s biggest driver for looking for a solution like Coder. But he also had something else in mind as well.
For quite some time, Kazoo has used a homebrew system to test feature branches. It allows them to compile their application and deploy it in a test environment before the changes are actually merged. It has worked great. It still works great.
The only problem? The author of that system left Kazoo a little over a year ago, making the system difficult to maintain.
For someone who spends a lot of time looking for solutions to problems that the teams he supports don’t even recognize yet, Joe knew it needed to be addressed sooner rather than later.
Today, the teams are mostly doing their future branch testing using Coder and the old manual process is about to be sunsetted.