03 Feb 25

Fascination Street #4

This week’s newsletter

Writing for the week of Feb 3, 2025

A number of people have reached out in the last few months to ask “you’re a software engineer, why did you get an AWS data engineer certificate?”. Along with some followup questions about the exam. The naive answer was that I felt like I had enough experience with AWS services that it would be easy. After I started researching the prep materials, I realized it was going to be harder than I thought. I needed to study. So I did. I’m a Maven.

The more extensive answer that I’ve been mulling about is that I think the industry might need another coined term. Meh, right? Insert eyeroll here. Maybe we don’t, but this is the best way I can think to describe my real reasoning.

Most people in the industry have heard the term “full stack engineer”. In it’s basic form it means someone that can work on the frontend, backend, and can be self-sufficient in a data store. That’s great and would have been how I described myself many moons ago. However, I’ve gained experience outside those three things. I’ve done infrastructure as code. I’ve built APIs. I’ve built CLIs. I worked on data platforms, and CDC, and event architectures using CQRS. Machine learning, CI/CD, etc. These things aren’t typically involved in the “full stack” conversation. We draw boundaries. We say data platforms are for data engineers not software engineers. Data engineering is a distinct role. Data engineering should borrow “~~best~~ practices” from software engineering. Etc.

But there are plenty of people that fit what I am coining “full system engineer”. This person is comfortable in all of the various pieces that make up a system. They understand the patterns and boundaries of the system. The sum of the parts. Maybe it has an architectutal pattern to uphold. They understand how to deploy it. How to monitor it. Everything involved with standing up, operating, maintaining, and upgrading the system. How to debug issues. This includes the “full stack” that is present inside the system.

That’s right. Full System includes Full Stack. It’s a different level. And it has some caveats. By spending time on other parts of the system, one may not be the most fluent or efficient with the frontend framework for example. I’m not suggesting generalist. Expert of none. I’m suggesting in the short term another teammate might be more efficient and that’s ok. The Full System Engineer type is working various parts of the system.But if the system includes a Rails or Django app, they are familiar with the framework and contribute to that app.

I’ve spent the last few years gaining experience in what is called “data engineering” today. We didn’t call it that before. Software engineers moved data around. Now there is a distinction. Sometimes I fail to see it. But I obtained the AWS data engineering certification to cement that I knew the domains, patterns, and services that now receive the data engineering distinction. And really understand how AWS thinks about them. Those services have been a part of the systems I have worked in over the last decade.

Maybe “full system engineer” won’t stick. Regardless, hopefully it articulates why as a software engineer I studied and obtained the data engineer certification. The simple answer is that the systems I have worked in have deployed data engineering. I don’t think of them as separate. My responsibilities over the last decade have involved both traditional software development and data wrangling.

It’s a long winded answer to the original question. Maybe my newly coined term articulates it. Only time will tell if it gets used beyond this post.

Note: I’m aware System Engineer exists in some circles already and is different than what I am proposing.

▧ ▧ ▧

Links

▧ ▧ ▧

Music

▧ ▧ ▧

A couple of promotions each week. First, use my invite link to try Warp as your terminal. It’s fast and has some great features. I’m not affiliated with them at all, just really like it. Also, check out my project–Schemabook, especially if you work in an organization that wants to get organized around defining data through contracts and collaboration. Lastly, I’m writing a book about learning Rust if you are familiar with Ruby. Stay tuned. As always, you can connect with me more at https://mikekrisher.com.