Check out part 1 of our “There’s No Wrong Way to Become a Software Engineer” series.
So you or someone you know is interested in becoming a software engineer or pursuing one of the many adjacent careers (e.g., data scientist, system administrator, tech support, etc.). Well, here’s the not-so-secret secret:
There is no wrong way to become a software engineer.
Each path is rife with challenges and opportunities and can be customized around schedules, needs, and aspirations. Some people may choose to take a more lazily winding trail with various stops along the way, and others may take the highway straight to Code City.
Whatever path you choose, remember that no matter what course you initially chart for yourself, your career as a student will always look very different from your career as a software engineer. Furthermore, the road never ends; there’s always more to learn!
I categorize the relevant learning paths into three general tracks:
-
Academia: Primarily defined by higher education and focused on theories more so than skill sets
-
Bootcamps/Tutorials: Intense multi-month courses or targeted training focused on specific languages, frameworks, and skill sets
-
Hacker: Self-taught and solo-driven training that leans on any resource available, “poking around,” and learning on the fly (e.g., using developer tools in the browser to see how web pages work)
Starting My Journey
Tracks: Academia
While my engineering origin story is primarily centered in academia, credit/blame should first be directed at the Boy Scouts of America for their Computers merit badge (since replaced by Digital Technologies) for introducing adolescent me to HTML in much more of a hackerspace.
Despite this early exposure, it wasn’t until years later that I realized how rewarding software development can be. I was fortunate to have several teachers and professors who did a fantastic job of transforming coding from a collection of humdrum tasks into interesting problem-solving exercises that, alongside coding competitions, kept students engaged. As a computer science major at Rice University, I found that the raw desire to keep learning, to figure out how to get the computer to do what I wanted, was motivation enough to continue in the field.
However you prefer to engage, embrace it! Software engineering is wonderfully malleable and adaptable to a variety of approaches and outlooks. Do you have an artistic or creative approach? Great! Think about coding as an art medium, and you’re the artist trying to sculpt a solution.
> Get Started
Internships
Tracks: Bootcamps/Tutorials, Hacker
I cannot stress how helpful internships were in confirming that software development was, in fact, something I wished to pursue professionally. I also acknowledge that internships are not always desirable or attainable for everyone; not everyone has access to high-quality internships or the time/resources to take on an internship. This can be especially true for those pursuing software development as a second career or outside of academia, and that’s OK! There are other ways of trying software development on for size! (See Bianca Henderson’s “There’s No Wrong Way to Become a Software Engineer: Part 1.”)
During my first internship at OpenStax in 2013, I was thrown into the deep end of web development. This was particularly enriching since I had not pursued web development in my coursework, so I had to rapidly ramp up via tutorials, webcasts, and other training resources.
The following summer, I interned at a high-performance computing (HPC) center within an energy company. This team adhered to more of a self-starter culture; it was entirely up to me to identify the best technology and design and implement a solution to the internship problem. While I could draw on technologies I was already familiar with, I had to dig into more niche topics like search algorithms, user authentication, and database integration. Always look for ways to expand your understanding. If you’ve used specific technology before, identify areas where you can deepen your learning and get out of your comfort zone!
Through my internships, I learned two valuable lessons:
-
Large solo projects are a fantastic way to learn rapidly.
-
Large solo projects are costly to maintain long-term.
Embrace large solo projects early in your career as a learning tool, but don’t get too distressed if the project doesn’t gain meaningful traction.
> Get Started
On the Job
Tracks: Hacker
We’ve all heard at some point that you learn more during the first few months on the job than during years in academia. This is likely because academia often seeks to teach the history and theories behind practices rather than current industry practices themselves. After I graduated I rejoined the HPC center, and those first few years of employment were marked by rapid-fire projects, from supporting legacy Fortran and C codes to helping stand up a new Python technology stack (which happened to be Conda based) to overhauling the team’s approach to version control (Git to the rescue!).
A common practice within the tech industry is contributing to open-source software (OSS) to boost your profile and level up your career. While it’s well intentioned, I find this recommendation problematic for several reasons. First, few of us want to volunteer hours of our free time for projects that large corporations tend to rely on with little regard to cost. Second, since OSS projects are out in the open, there tends to be more community involvement in all aspects of them. This community involvement is generally critical to the success of OSS projects but can also be very toxic and emotionally draining. So absolutely do not feel pressured to contribute to OSS for the sake of exposure.
That being said, I was very fortunate to be able to dedicate work hours to interacting with and contributing to several OSS projects that we used in the HPC center. This gave me a learning avenue outside of my daily work (much of my understanding of version control, code review, and sustainable development come from my interactions with the OSS community). Ultimately, my involvement and interest in OSS projects spiked my interest when Jannis Leidel (now my colleague) posted a job opening at Anaconda on Twitter in June 2021.
Find ways to make your job work for you; your career should always be building upwards to the next step you wish to take. Inevitably, you’ll find yourself plateauing at some point, meaning you’ve learned pretty much everything you can learn in your current role. At this point, you have a few options:
-
Be content with your success.
-
Seek out a new project, a new team, or a new company, any of which will provide you with unique learning opportunities.
- Return to the three learning opportunity tracks:
-
Pivot back to academia for additional courses or even an additional degree
-
Engage with bootcamps/tutorials and attend workshops/conferences
-
Engage in self-directed learning (e.g., via professional development books)
> Get Started
Making Myself Obsolete
Tracks: Hacker
I’ve never been a fan of repetitive tasks, especially tasks that need to be revisited every few months (with just enough time in between to start forgetting specific details). This means I love automating tasks; I aspire to make myself obsolete. I consider a job well done if I can solve a problem in a way that empowers others to solve their problems. Consequently, I place a high value on code maintainability and readability and lowering tech debt.
I also have a strong distaste for complicating the technology stack—especially when doing so disenfranchises individuals who could have otherwise solved the problem in question (i.e., sometimes adding a database is overkill and a JSON file is perfectly sufficient). A simple tech stack gives me confidence that future problems or desired changes won’t necessarily result in an urgent phone call asking me to step in.
That said, long-term software support is critical, and software developers must be comfortable maintaining existing codes. What I’m advocating for here is NOT attempting to build any implicit job security into the code; don’t design bad code that others cannot understand or maintain to give yourself job security. Doing so is a surefire way to set up a project’s eventual demise.
The upside of making myself obsolete is that I’m constantly able to pursue new problems. I’m also more likely to avoid the learning plateau previously mentioned. Software engineers that understand the value of learning and continue to stretch their skills are invaluable to their companies and teams; they enjoy strong job security through being a conscientious thought leader. Seeking to make yourself obsolete allows you to make choices that are in your project’s best long-term interest, and you’ll reap the benefits.
> Go Further
Never Stop Learning
Tracks: All
The pace of technological innovation appears to be on an exponential trajectory. As a reminder, the Wright brothers completed their first successful flight in 1903, and Apollo 11 landed on the moon only 66 years later—all comfortably within the span of a modern human life. Many of us can track similar progressions within our own families; my ancestors, including my grandparents, were farmers/farming adjacent in rural Norway, and within two generations we immigrated to America and adopted previously unfathomable engineering careers.
The most important skill you will ever acquire is learning. If you stop learning, you sacrifice the chance to keep your daily job exciting and new and your ability to keep up with the changing world. Tomorrow’s tech stack doesn’t exist yet, and project management methodologies are ever changing. The workforce you enter today will not be the one you exit years later.
Learn to learn, to be adaptable, to embrace change. Try new technologies early and often, and don’t be too stubborn or set in your ways. Remember that as you learn and the world around you learns, a previously solved problem can be solved again using a different technology, theory, or perspective and could result in a more elegant solution.
> Go Further
TL;DR
