Published on August 20, 2020
Lead Product Engineer, SEP
Computer science degree
Hey! I’m Matt Swanson - I identify with the “full-stack” label because I sit in the weird intersection between engineering, product, and design. I’m primarily a software engineer, but I’ve focused all my career on building products and developing a good design sense.
I live and work just outside of Indianapolis, IN. Lately in my free time, I’ve been listening to podcasts on long walks and discovering my new favorite music genre: retrowave.
I was extremely lucky to have some great opportunities to learn more about engineering, even while in high school. My high school has a “technical vocational” school attached and I was able to take electives in things like AutoCAD, digital electronics, 3D printing, and computer networking. In addition, I joined our school’s FIRST Robotics team. All of these experiences helped me decide that I wanted to pursue some kind of engineering job.
But I was not very much into programming when I enrolled at university. In fact, I didn’t really like it much at all in some of my intro-level engineering courses. Partially because we learned coding by learning C and [Fortran](https://en.wikipedia.org/wiki/Fortran#:~:text=Fortran%20(%2F%CB%88f%C9%94%CB%90rt,numeric%20computation%20and%20scientific%20computing.) (yes…Fortran was taught in 2006).
I think a huge benefit of going through a rigorous engineer program is that you build problem solving habits and get experience working through difficult tasks. Skills like stating your assumptions and working incrementally and checking progress all along the way are key concepts that are super valuable in my work now, but might not be obvious since they don’t show up directly in the curriculum.
I didn’t really know that I wanted to pursue a career in software development until I took a class about scripting that taught Python and where the projects shifted from more academic examples into real-world examples. The final project for that class was to build an IRC chat client with Python. After that, I was hooked and started shifting more and more of my classes into programming-related topics and away from digital electronics and circuit design.
Bootcamps and the wealth of learning resources were not as prevalent when I was going through school, but I’ve worked with several people that have taken the route at my job. I think there is a bit of bias in the success stories from bootcamps in that the people that can get up to speed quickly are generally very driven and usually have an existing background in some other field. But certainly I think it’s a viable alternative.
Both paths have downsides: CS grads may have good fundamentals, but lack experience with more relevant technologies that will be used in the workplace. Bootcamp grads have more experience with certain tools, but may have to play catch up when it comes to more abstract concepts.
I did an internship at SEP after my junior year at school. I got to work on a real client project (a web app for monitoring performance of aircraft engines and tracking maintenance). I was part of a team of around 10 people. It was a great learning experience. After graduating, I interviewed with a few more companies, but ultimately I liked the “small company” feeling at SEP and joined full-time.
In order to get the internship, I had to do one of the dreaded whiteboard interviews. I was able to solve the problem, but once I joined SEP and learned what the pool of potential interview questions was, I realized that of the three questions they pick, I got the only one that I was confident I could answer!
The biggest thing I struggled with early on in my career was adapting to working in codebases that were large and had been running for a long time. In school, you are generally doing small projects and you “throw them away” at the end of the assignment.
In the real-world, you have to deal with legacy code, systems that you don’t understand, and know how to navigate a complex domain. Now try doing all of that while also still learning the fundamentals of building software!
Projects at SEP typically last 12-18 months. Right now, I’m leading a small project team of two engineers that is building a knowledge base for tracking patient access to oncology (cancer) and rare disease drugs. I’m doing a little bit of everything: talking with our client, talking with our users, writing code, learning about the US healthcare system, designing features (product-level decisions, UI mockups), reviewing code, making GitHub issues, writing release notes and project updates.
I love wearing many hats and being able to help small teams do big things.
I think as you grow as a developer you first are just trying to get something working, then you’re trying to make the code good, but as you become more senior, you try to see if you can avoid writing the code at all.
Especially in my context of custom software projects, code can sometimes be a liability as much as an asset. Thinking about what the codebase or product will look like 3-5 years down the line is a perspective that I think is important to develop over time.
The biggest piece of advice I would give to someone just starting in the field is to figure out what kind of projects you like working on. At the surface-level, this could be what tech stack or frameworks you like. But really think about whether you like working at a product company, or a consulting agency, or inside of a non-software business.
Do you like small teams? Big teams? Do you like interacting with customers? You can end up working with your dream stack, but be miserable at work if you’re not in the right environment for your own preferences.
StimulusJS is part of a larger set of tools produced by Basecamp. Typically, you would use StimulusJS alongside Ruby on Rails and Turbolinks to get some of the benefits of a client-side SPA (snappy page loads) with still writing backend code that renders HTML.
Articles, guides and interviews about web development and career progression.
Max 1-2x times per month.