My interview with Matt Swanson

Published in August 2020

Matt Swanson

Lead Product Engineer, SEP

11 years of development experience

Computer science degree

Ruby on RailsTurbolinksStimulusJS.NETJavaAndroid

Hey Matt! Can you quickly introduce yourself?

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.

What was it like studying Computer Engineering?

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 (yes...Fortran was taught in 2006).

What were the biggest benefits of going to university and studying Computer Engineering?

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.

Learning to code by yourself/bootcamp vs CS degree?

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.

How did you start working at SEP and what were the challenges in the start?

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!

What does a normal day at your job look like nowadays?

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.

What are the not so obvious differences between junior and senior developers? What should a junior dev start thinking about?

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.

Could you explain why you are a fan of StimulusJS for folks who haven't tried it before?

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.

In my experience, so much of the software in the real-world is closer to something like Shopify or Basecamp than something like Figma or Netflix: most business apps are what I like to call “CRUD++”. The bulk of the functionality is creating and viewing some domain-specific database models and then maybe there are a few pieces that are more interesting once you have that solid platform.

StimulusJS appeals to me as someone who came up during the jQuery days of web development. The workflow of being able to attach small little pieces of Javascript functionality onto a page has worked great for a long time. StimulusJS helps bridge the gap by allowing you to still write code in the same mental model as jQuery, but with a bit more structure and with the benefit of using ES6.

If you have some free time and interest, I recommend you to give Stimulus a go in order to see what's the alternative to React and Vue.

The official handbook is a great resource to see what it's all about.

How do you find the time for side projects while also having a full time job?

One of my personal mantras about building products is to be anxious in the short-term and patient in the long-term. This definitely applies to side projects. Doing a little bit of work here and there over a long timespan snowballs. My energy and motivation seems very seasonal: I get bursts of productivity and then long-stretches where I struggle to make any progress.

It works great when I can find a side project that overlaps with my day job. Right now, I’m working a lot on BoringRails and the lessons I’m learning to put into that are coming directly from my job. Another project I worked on last year was an analytics tool for a niche football league. One of my hobbies is playing fantasy football so I was able to combine the two.

People start building their side projects but never ship. How can we get out of this cycle?

I still do this all the time. I have a graveyard of domains for projects that never got started and notebooks filled with sketches for things I was so excited to build (and never returned to). I don’t think it’s necessarily a bad cycle. It depends on if you’re getting out of the project what you want. If your goal is to fiddle around with a new technology, it doesn’t really matter if you shipped something.

One shift I’ve tried to make recently is to think about side projects as assets. Not necessarily that a project has to make money, but that an ideal side project should be something that can grow and get better over time. With BoringRails, I started writing articles first instead of a full book. “Finishing” an article is way easier than finishing a book, and the project starts building up value as soon as I post the article. Over time, I can add more and more articles and build the audience. Even if there are large gaps when I don’t feel motivated or don’t have time to move the project forward, new people are finding the content and learning and signing up for the mailing list.

For my football analytics site, I did a burst of development to build out connections to data APIs and design the pages on the site, but after that it was on auto-pilot. Every week, scripts would run to download the game data. The goal was that the tools would become more valuable month after month, without me having to do any more development (unless I wanted to add new features).

If you were to hire a developer with no previous professional experience, what would you like to see in them?

I’ve worked with several “apprentices” in my career: people with a non-traditional background that are starting out in the industry. The most successful people have been naturally curious and unafraid to ask lots of questions. It’s important to help foster an environment where it’s okay to ask questions and get help when they’re stuck.

I think the best way to learn is to have a project that you’re interested in and start building. When you get stuck, figure out a way to move forward: whether that is asking for help, or working with someone else, or teaching yourself a new skill.

Can you share some of your favourite tools and resources for learning to code and shipping products?

  • Books: Getting Naked is the best resource on working as a software consultant and really shaped how I interact with clients and my teams. Apprenticeship Patterns is the most underrated book on becoming a great software developer ever written.
  • Courses: Find a good screencast series for whatever technology you like. For me, that was Destroy All Software. Nowadays, that might be a course of Egghead or Laracasts or GoRails.
  • People that have been influential to me: Patrick McKenzie, Amy Hoy, Kathy Sierra, Adam Wathan, Gary Bernhardt, Ben Orenstein, Ryan Singer, DHH, Jason Cohen, David Cancel, Nassim Taleb, Nathan Fielder, Gary Vaynerchuk, David Perell.

The best way to learn to code is to code.

The best way to learn to ship products is to ship products. You will learn so much faster when you are faced with an actual problem and you have the full context of what’s going on than by purely consuming content.

Use these resources to get exposure to tools and to have reference points, not as a substitute for rolling up your sleeves and diving in.

Where can people find you on the internet?

The best place to reach me and keep up with what I’m doing is on Twitter.

You can find my personal site and blog at https://mdswanson.com and my collection of in-the-trenches articles about building apps with the same “boring” tools and practices as GitHub, Shopify, and Basecamp at https://boringrails.com.

Thanks Matt for the interview and thank you for reading it! 👋

Level up your web development skills

Get articles, guides and interviews right in your inbox. Join a community of fellow developers.

No spam. Unsubscribe at any time.

Full Stack Heroes logo

© 2020 Full Stack Heroes