I started with GoDaddy a little over two years ago in my first ever full-time job, as a software engineer. Before that, I was completing an undergraduate studies degree in Computer Science. I completed some internships before graduating, yet neither those internships nor my computer science curriculum prepared me for any of the things that you'll read about in this post. It was my teammates and manager that were the ones that gave me the most impactful tools to prepare me for the start of my career!
Imagining my career as a marathon
As overused as the whole race analogy is towards a lot of things, it feels particularly apt in this moment in my career. An expected and defined timeline with milestones doesn't exist in the workplace like it does in college. In college, you have a set number of classes to complete in a semester. During the semester you have classes to attend, and each class has projects and assignments to complete and tests to pass. You repeat this process over four years (hopefully!) and you earn your degree. While promotions, title changes, and company changes exist, a career doesn't have a defined timeline like in college. Switching my mindset to embracing this as an opportunity to set a pace that's challenging yet ideal for me has allowed me to learn a ton more! It has also created a space for me to be able to learn about a vast array of technologies and languages over such a short period of time.
For example, in college, my professors set the curriculum for the semester to ensure we learned specific concepts within a specific timeframe that they wanted. At work, I set my own "curriculum," with the help of my manager and team. If I notice that a certain project requires me to understand a language or technology, my manager and I plan to prioritize that. The first year I started working at GoDaddy, I was tasked with migrating all the services my team owns from EC2 to ECS alongside two other engineers. I had zero clue how infrastructure worked within AWS! Because there isn't a set curriculum, I was able to adapt our plan to include time to take courses via LinkedIn Learning to better understand Sceptre (a tool used to drive CloudFormation), and some of the other frameworks required to complete the project. By the time the project was completed, I felt really empowered to look at my career as a marathon with a variety of turns and opportunities instead of a fixed period of time with predetermined challenges and options.
The importance of embracing curiosity
Although this is something my manager emphasizes a lot to me, it has also been the hardest lesson for me to internalize. This could be because my college education placed correctness over curiosity. My team handles a significant amount of money per day. So writing code that works correctly is essential at work too! Yet, the key isn't sacrificing curiosity for correctness. At GoDaddy, I've learned that maintaining my curiosity while also focusing on correctness helps me produce a high-level of quality work. In college, as tests loomed and grades began to determine my GPA or whether I got that prestigious internship, it was understandable to do anything to pass those tests; even if it meant focusing on correctness over curiosity. Ironically, the opposite has been true with my work. Why? Because when I focus on learning why an approach, method, or idea was the best path, it becomes ingrained in me. The next time a similar problem arises, I know exactly what to attempt (or where to start) because in the past I took my time to learn why it worked then.
My team values engineers owning the entire pipeline of getting our code to production and in the hands of our customers. This means that from when I write my code, to the peer review process, to the deployment process, I am involved in each step. For example, while deploying a feature that updated the way fees are labelled on the Payout Report merchants receive, I noticed something odd in the staging environment. The report was not showing up correctly in the staging environment like it had in the test environment. Although I fixed it in a brute force way, I didn't understand why my solution worked. Following my curiosity led me to pause the deployment process and spend time with my manager tinkering with the environment to understand why that happened. This allowed us to implement a more efficient fix that would prevent it from happening to other engineers instead of a fix that would simply let my code work in the short term. Not only do I have a better understanding of how Jenkins (what my team uses for the deployment and staging process) works because of that situation, it reminded me that my team cares just as much about my growth as they care about getting our work done in a certain timeline.
Embracing the idea that solving problems is fun
Being a software engineer, solving problems is my entire job description. As a result, there can be a lot of pressure to not fail at solving them. In the classroom, failing has consequences. I get a bad grade, I don’t graduate. It also has consequences in industry too! If I release a feature that breaks in production, it costs GoDaddy money, customers, or both. However, reframing failure as an opportunity to learn and not “a big bad thing” alleviates that pressure. Adopting this mindset that looks at problems as opportunities to learn has paid off for me in the long run. When I began to look at problems as opportunities, it became easier to tackle them. Time and time again, every debugging session has taught me how a codebase works. Every failure has taught me how to test more rigorously. Every mistake has taught me how to crosscheck my work.
Perfection isn’t the goal. Instead, the idea is to become comfortable with the experience of solving problems. While the solution matters, the process is where I have found significant rewards. I think of debugging as a muscle I can strengthen. Each time I am tasked with a problem, I remember to dig deeper and continue asking why at each step until I arrive at a solution.
Focus on technology over tool
Finally, a key lesson I have learned over the past two years is why it's essential to give less value to the tools and programming languages I use. Instead, I’ve learned to focus on the underlying technology that powers these languages and tools. I used to hold quite stringent preferences for certain tools. “I could never work with Java it's too verbose” and “I hate Python it’s too straightforward” (said no one ever) are some examples. There's nothing wrong with having preferences. We form them from our experiences and our values. However, if a career is a marathon, then being more focused on the tool instead of the technology isn’t sustainable. As engineers, our craft is to solve problems. Although essential, the tools that help us do this aren’t more important than the underlying technologies that they use. Not only has it been important for me to be curious about the technology over the tool, it has also been crucial for me to remove my identity from it too.
The bulk of my courses during undergrad were in Java. As a result, when I first began working at GoDaddy, I felt the most confident writing code in that language. Like in the story I told earlier, when my manager tasked me with an infrastructure heavy project for the bulk of my first year, I will admit that I was not excited. It had nothing to do with the domain of the project, and more to do with the fact that I thought of myself as a Java developer. Why else would I have spent the past four years learning it? I have to start again? Looking back now, I am so happy I spent close to seven months on that project! I learned a significant amount about how the code I write gets to our end users. I am not a Java developer, I am a software engineer who can write code in Java.
When I was in undergrad, I sometimes found myself siding with peers who used certain IDEs to write code over others. Why would I use Sublime, when Vim is cooler? Now I chuckle that those thoughts even cross my mind. The IDE matters but how the code compilation works matters more. I am an engineer, and these are all simply tools that help me with my craft.
Conclusion
A little over two years ago, I embarked on a career as a software engineer. When I graduated, my primary (and probably rightful) focus was to get a job and use what I learned in college to do what I was hired to do. As I've started my career, my focus has shifted a little. I now care more about the craft of engineering, and why things work the way they do. When trying to solve a problem at work now, I spend more time thinking about what technology provides the best solution, regardless of whether it’s something I’m already familiar with. I spend more time thinking about what technology can help me solve a problem best instead of which of the technologies I am already familiar with, which will help me the best. I get excited now when I have a new problem to solve for work and how it means I get to learn a new way of solving problems. I am so lucky to have started my career with the team and manager I have; they have helped me embrace these new ideas and lessons through being patient and modeling these behaviors every day. If my manager had not spent considerable time explaining concepts to me even when it took me longer than the second try to understand them, I wouldn't reap the benefits of being curious. My teammates advocating for taking charge of my own "curriculum" empowers me to alter its course when it is necessary. Our customers trusting our software to collect payments allows me to have interesting problems to solve every day at work. GoDaddy empowering its teams to be innovative allows me to be exposed to so many languages, technologies, and frameworks and I am a better engineer because of it. These four lessons have been foundational for me and I hope sharing them will be insightful for anyone reading this; from engineers much more senior than me, to managers grooming careers of junior engineers, to those entering and graduating college now.
