Written by Julius Boateng
Published on August 30, 2022
Reading time 5 minutes
If you asked me a year ago what a software engineer did, I would have said something along the lines of “solving problems through code.” It’s a simple answer that points to how the work we produce is evaluated. For engineers on product-driven teams, these problems could include how to implement a new feature that customers have been asking for, or how to improve the performance of existing features.
If you ask me the same question today, I would give a slightly different response. Software engineers are tasked with solving the right problems through code—and when solved effectively, they accomplish business goals. Figuring out which problems to solve and how to solve them is the most important part of being a developer, with the actual implementation details being secondary.
I became interested in programming after taking a class at Upperline Code the summer before my freshman year of college. I got this opportunity through a college and career readiness program that I was part of called The Opportunity Network.
Upperline Code was my first introduction to programming, and where I quickly realized I was interested in learning to code. Later that summer, I received my Notre Dame enrollment packet and switched from the College of Arts and Letters to the College of Engineering so I could major in Computer Science (CS).
Some of my favorite CS courses were Design/Analysis of Algorithms, Cloud Computing and Programming Challenges. The problems were interesting and the professors were great at presenting new ideas and explaining concepts.
Throughout undergrad, I knew that I wanted to work as a software engineer and use the technical skills that I gained. Thankfully, the summer before my senior year, I had the opportunity to intern as a software engineer at Kantata and pair-program with other engineers to help deliver features.
My internship experience, along with pep talks from my professors, gave me the confidence to not settle for any other role when I first started applying for jobs. After plenty of time spent in office hours, I graduated in 2021 with a CS degree and accepted an offer to be an Associate Software Engineer here at Sprout Social.
Part of being new to the role and new to the company was having to develop both general software engineering skills and Sprout-specific domain knowledge. I found that tasks which required general programming knowledge to understand were the easiest for me to solve. However, tasks that required knowledge of Sprout’s architecture took time for me to tackle and I had to rely on my team for help. While there are some problems you can solve by reading documentation online, you can’t always find information that is relevant to the work that you’re doing—being able to ask others for guidance is crucial.
One of the first things that stood out to me when I joined Sprout was how collaborative the development process is. I knew that it took entire teams to develop features, but I didn’t know what that looked like in practice. I quickly realized that releasing a successful feature required many people in different roles working together—from product managers defining project requirements, to designers creating mockups and engineers implementing features. Collaboration wasn’t something that was optional, but a necessity in accomplishing our team’s goals.
Learning how to navigate through the various codebases and building a mental model of how different services interacted with each other was a steep learning curve. Since Sprout’s core business is software, its architecture is heavily shaped by its business requirements. As I was ramping up, I had to be aware of the business problems developers were trying to solve and why previous architectural decisions were made.
Initially, I was a bit intimidated that pull requests required reviews before they could be merged into the codebase. Understanding that the main purpose of code reviews is knowledge sharing and maintaining code standards helped change my perspective.
Going through code reviews has helped sharpen my technical skills and improve the quality of my pull requests. Having peers give me advice on what to change, introduce me to new patterns, and point me to relevant areas of the codebase has been really helpful. Reading the pull requests of other engineers has also given me valuable visibility into other services that I am not directly working on.
There is a prevailing idea that as you enter new stages in life, your previous experiences no longer matter. Once you enter college, your high school experiences no longer matter. Once you enter the workforce, your college experiences no longer matter.
But something that is often overlooked is that our experiences, knowledge, and habits have a compounding effect. We usually are only able to achieve new things thanks to the work we’ve done before. The knowledge and skills that I previously gained have greatly influenced how I approach new challenges as an entry-level software engineer.
The classes during undergrad that had the most direct impact on my day-to-day work at Sprout were Programming Challenges and Database Concepts. The former taught me how to break apart large problems into smaller pieces to solve them more efficiently. It helped me become more intentional on how I structured my code and improved the readability of my code.
Database Concepts taught me fundamental relational database concepts and covered topics such as database schema design and SQL. I learned how to write queries, which has been extremely useful since I frequently need to query our databases to solve problems or answer questions.
The opportunities I had outside of the classroom were equally as valuable. Java wasn’t a language that was covered in most of my courses, however I had the opportunity to work on it for a business project that one of my professors was leading. I gained hands-on experience writing Java, working with MySQL databases and creating Docker images. Learning Java was especially helpful since most of Sprout’s services are written in it.
There are a lot of other skills that I gained over my time in undergrad that I take for granted, like navigating the command line and understanding core programming concepts. It’s a common misconception that since most of the topics covered in undergrad are theoretical in nature, they won’t prepare you for software engineering careers. However, I believe the opposite is true—the skills you learn in undergrad matter, even if they aren’t directly applicable to your day-to-day work.
CS covers a variety of specializations such as artificial intelligence, machine learning and data science. The experience you gain in undergrad serves as foundational knowledge that can serve you well in a variety of entry-level roles not exclusive to software engineering. Making the jump from undergrad to a full-time position provides an opportunity to explore what kind of role and specialty is the right fit for you.
If you’re looking to start a career in software engineering, Sprout’s a great place to begin.
Julius Boateng
Julius Boateng is an Associate Software Engineer at Sprout Social. Outside of work he likes to play basketball, listen to rap music and hang out with friends.
Read all articles by Julius Boateng
Join 70,000+ professionals and become a better social media marketer. Get social media resources and tips in your inbox weekly.
Sprout Social helps you understand and reach your audience, engage your community and measure performance with the only all-in-one social media management platform built for connection.
Contact
Support
Solutions
Platform
Integrations
Company
Resources
© Copyright 2022 Sprout Social, Inc. All Rights Reserved. Privacy | Terms | Disclosure Policy | Cookies | Do Not Sell My Personal Information
