My first few days of work at SalesLoft were pretty nerve-wracking. I wasn't a software developer. Not really anyway. I had written tons of Ruby on Rails code on the side for my personal projects, but the quality of that code didn't really matter. Even if my projects were just barely hanging together with duct tape and shoe-string, no one could tell that from the outside.
When I started at SalesLoft, I identified as an electrical engineer who knew how to code, and I was walking into an office where people expected me to be able to write production-quality code on a daily basis.
Not wanting to be found out as someone who knew more about CPUs than the code that they process, I did what any reasonable person in my situation would do: I got to work right away. I didn't want to waste any time ramping up on learning about what I was about to do. I'd ramp up while getting stuff done.
I could have been cautious and declared that I didn't know enough to solve this problem or that, but I did the opposite. By getting to work on the hard problems right away, I was able to quickly identify the many gaps in my knowledge and fill them by asking my teammates so many questions.
This worked out really well for me. It's only been a couple of months, yet I've already worked on and made meaningful contributions to projects using several different technologies I'd never touched before.
I've always tried to have an open mind when it comes to change, and this was vital in my first few days on the job. Any time you start a new job, things will be different. Processes for getting things done, the coding style the team uses, and the personalities of the people around you are all things that are sure to change. Being open to these changes and trying to find the positive side of them all allowed me to adapt quickly.
Beyond those first few days, as the weeks went by, I found that my success at SalesLoft began to have less to do with me than it did with the company culture. Sure, it was important that I continued to learn and grow, but simply being in an environment that encouraged that learning and growth was far more important.
My coworkers were eager to help me solve hard problems, helped me correct my mistakes with compassion, and just generally tried their best to make our workplace a great one: a place where being human and making mistakes is only the first step in learning, growing, and achieving our goals together. After I had made the initial effort to adopt the SalesLoft Core Values and exhibit them every day, simply being around other people who did the same made it effortless to become a better developer.
Of course, not all of my first 90 days were sunshine and rainbows. Sometimes my builds would break because of some completely unrelated test. That was frustrating because I didn't know to expect flaky tests. However, the engineering team at SalesLoft has a Slack channel dedicated to fixing these flaky tests where anyone is free to both alert the team to a spec that is failing intermittently and fix any of the flaky specs that have been reported. (I'm happy to report now, about 7 months after I started working at SalesLoft, that Slack channel is mostly deserted. Flaky specs are not really an issue anymore.)
Another problem I've had is it's sometimes very difficult to navigate a codebase written by somene else. If you're considering becoming a software developer, this is a problem that you too can expect to encounter. For me, this was only a minor problem. Every team at SalesLoft has a more senior engineer that knows the codebase pretty well and can guide newer developers around it. Just by asking for a rundown of the section of code I was working on, I was able to make progress myself pretty easily.
Also, a good chunk of the SalesLoft codebase is broken out into microservices, so once I'd identified which microservice I needed to work in, there wasn't really that much code to sift through anyway.
Although SalesLoft is a fast-growing company and my team there works on a core part of the SalesLoft platform, I've found my stress levels to be lower here than at my previous job. Everything feels like much more of a team effort here. If something goes wrong, everyone works together to fix it instead of trying to distance themselves from the problem.
I feel lucky to have started my software development career at a place like SalesLoft. Everything at SalesLoft feels normal; there's no one thing I can really point out as being a great part about working here, and that's not a bad thing. Places that have one or a few really great features tend to have bad features that highlight the good things.
Places like SalesLoft where everything is great tend to feel very flat in contrast. At SalesLoft, there just aren't any bad things to show how great the rest of the experience is. If you work in a place where everything just feels normal and smooth, like it does at SalesLoft, take that as a sign that you're working in a functional work environment.
In my experience, the highest-performing teams don't feel like high-performing teams. They just feel like teams where nothing is wrong.
In my first 90 days as a software developer, I feel like I've learned more about what it's like to work in a productive and functional workplace than I have about coding. I guess a job is a job in the end, and what makes it special are the people you work with the and the relationships you make. After all, the code is just an implementation detail.
Photo by Annie Spratt