Background Link to heading
Hi! My name is Jonah Alligood. I’m a senior software engineer at Alliance Laundry Systems, the parent company of well-known brands like Speed Queen. The software engineering side of the business is relatively small compared to its footprint which means that I have the opportunity to get hands-on with a lot of different things that I wouldn’t normally be able to in a larger corporation. While I am often doing normal, individual contributor things like writing code and performing code reviews, I am also regularly involved in things like systems design and architecture review. It got me thinking about my career expectations versus reality when I was a high-schooler and early college student, and how my perspective on software engineering has been molded and changed over the last six years doing engineering for a living.
Early Years Link to heading
As a high-schooler and early college student, I spent most of my time working on toy projects to learn and understand how to write code and how computers function at a lower level. While I would consider a few of these projects to have been pretty cool (even today), it was more an exercise in seeing how far I could go in implementing any given idea. I wasn’t concerned with the more formal methods of software engineering. I was just trying to write an implementation that worked. I believe that many college students find themselves in this position for at least the first half of their four year degree if they have not previously spent much time exploring on their own.
By this stage, after several years of teaching myself how to code and getting my toes wet in college, I thought that software engineering was easy, coding is easy, and as long as it “just works” I was doing my job. I thought that 90% of my time would be spent coding, and that I would learn the hard stuff in college, and apply it fairly regularly on the job. I thought all I needed to be good was to be good at writing code. Many of you reading this probably know already the great hubris contained in those thoughts.
Thankfully, it was not long before I was able to jump into the workforce and join a team.
Internships and My First Job Link to heading
Though I had an internship the summer I graduated high school, I really don’t ever consider it as part of my career. By all accounts, this internship was supposed to be an impressive position to list on my resume. Especially in my hometown, it was almost considered to be a rite of passage for anyone even remotely considering an engineering job of any kind. At the time, I thought my future was set. An internship at a Dow Jones listed company? Surely, Google will be clamoring to snag me when I graduate. Instead, the experience I had was largely a waste of time at best. There was almost zero mentorship provided, no value added to the business, and the best I can say for having worked at this organization for three months is that it taught me that I don’t fit in well at large corporations.
The internship I consider to be my first, as well as my first real job, was my time at Precision Planting, a small, but powerful leader in the ag-tech industry. While it was… technically an internship, I was granted the ability to work remotely during the school year (and come back in-office during winter breaks), and was very much treated like an entry level employee by just about everyone. I believe the man in charge of coordinating the internships the final summer I was in-office even implied as much to me personally. Compared to my first internship, I actually got to work on things that were important to the business. I got real feedback and mentorship from multiple experienced professionals. I learned that coding is hard sometimes, and that making something that “just works” isn’t really going to cut it. I learned a lot about what it’s like to do software engineering. Not coding. Software engineering.
There’s a chasm’s difference between learning the theory in a classroom, and even applying that theory for an assigment… and working on a team of engineers with code quality standards, executive deadlines, financial considerations, and future-proofing the systems you’re designing and releasing next Spring. In the world of software engineering, there’s a whole host of other skills you need to be successful. And those skills were not entirely foreign to me, but needed a great deal of time and effort to improve.
I understood by this point that software engineering was very different from what I was used to as a self-taught programmer. In a self-taught environment, you are often entirely alone. Collaboration, meetings with stakeholders, understanding business requirements; these are things that come with being on a team. And you can only get better through practice. By this point I understood that my idea of a career in software engineering was very different from the reality.
A Note on College: A friend of mine is completing his computer science degree next year, and voiced a concern he had that he felt like he wasn’t learning the right things for his career; in that, he felt like he was learning skills but wasn’t finding opportunities to apply those skills on a deeper level in the classroom. I can’t speak for everyone, but I had a similar experience and if you, the reader, are having similar feelings, I want to give you some comfort and say that’s okay. I have had the opportunity to work with new-grads on the job as a senior engineer, and all I would really expect is that you are competent at writing code and you understand how computers work. As long as your mentors and teammates assume a base level of academic engagement with software engineering you will be fine. As I already mentioned and will mention again, there is so much to learn that you will not learn in a classroom. There are also things that you can only learn through experience. So it’s okay. I’ve not met anyone who expected much out of new-grads. Your job is to contribute where you can and learn everything else along the way. Find a mentor. Ask questions. Keep contributing.
Chaos Theory Link to heading
I’m going to largely skip over the next two years of my career. It was not stable, and though I learned a lot about how to weather storms, understanding the business side of organizations, and how better to work within agile teams, my understanding of engineering did not change much. I spent about six months between startups. Getting let go from the first due to budgets, and leaving the second after my probationary period. Afterwards, I joined an organization called World Wide Technology. Today, it seems their primary focus is on delivering AI capacity solutions at scale to other organizations around the world. During my year and a half tenure there though, I got to work on agile teams doing internal work on some monitoring systems. I did not find the work to be very engaging, but it gave me time to try and focus more on my soft skills, and it gave me a brief opportunity to try and mentor another aspiring engineer during his summer internship. The people I worked with were top-tier engineers and wonderful human beings. However, my growth had stagnated, and there’s nothing I can point to from my time there that I’m really that proud of. That’s not to say the work wasn’t important, but it was not challenging, and not what I wanted to be doing.
Then, one summer morning, I accepted a position at Mastercard.
Level Up Link to heading
I got an email from Mastercard’s talent network that they were looking to hire about thirty senior software engineers over the next several months, and invited me to apply. At this time in my life, I had about 4 years of experience, including my “technically internship.” I did not expect to get an offer, but I did. The team I joined was relatively new within the organization. The principal engineer on the team (who later became our director) had created the team with two other engineers to develop an in-house cryptographic key management system. Think AWS’s KMS, but internal to the organization. I joined the team with another senior engineer and a new-grad. The key management system was about to go into production for use by another internal team supplying secure cryptographic operations for teams all over the organization, and all over the world.
During my time here, I got thrown into the deep end of software engineering. For the first time in my career, the hardest part about my job was not the coding. It was not making sure I implemented the most optimal O-notation algorithm. It was not doing things the SOLID way or the DRY way or the whatever way. The hardest part of my job was the domain, and what to do about it.
For most surface-level engagements with cryptography, it is not that challenging to understand. There were many legendary computer forefathers who actually understood the hard math that makes cryptography useful, and we don’t really have to understand it to the same degree in order to effectively use it to our benefit. Say you want to use public-key cryptography to send a message back and forth between you and your friend. The following is sufficient:
Alice has a key-pair, PUB(A) and PRV(A).
Bob also has a key-pair, PUB(B) and PRV(B).
Alice and Bob exchange public keys, so each has a copy of the other's.
Alice wants to send Bob a message, M:
Alice: Encrypt(M, PUB(B)) -> B(M)
Bob: Decrypt(B(M), PRV(B)) -> M
If N is a key-pair, a message encrypted by its public component can only be
decrypted by its private component.
That’s really all you need to know. You could probably implement such a proof of concept without ever knowing, for instance, that the message M must be padded to a certain length. Most high level libraries will provide a reasonable default padding scheme. You might also not know that most messaging applications use hybrid encryption schemes (symmetric + asymmetric) for performance. And I doubt most engineers have ever had to do key wrapping before. (Key wrapping is when you use one key to encrypt or decrypt another key. It’s key-ception).
The team I was on was not implementing a rudimentary messaging application. We were delivering cryptographic keys to distributed data-centers at scale, integrating with our internal public-key infrastructure (PKI) and ensuring at-rest and in-transit encryption. We were writing libraries to interface with multiple hardware security module (HSM) vendors. We were delivering keys to cloud HSM providers. We were engineering.
There’s a fun meme that programmers like to invoke to rage-bait each other. And that is asking the question “what’s the difference between a software engineer and a software developer?” The real answer is that different organizations use different titles. My answer is that a software engineer is concerned with more things than just the code.
Suddenly, writing code didn’t seem so hard. Anyone can write code. Not anyone can write the right code. And the right code can take on different forms across teams and organizations. In my case, the right code was making sure if someone encrypted some data with an AES key we gave them, they better be able to get that exact same key quickly, securely, accurately, and from anywhere in the world.
My time at Mastercard was probably the most pivotal of my career. I realized that, up until that point, I wasn’t really engineering much of anything. I was developing a lot. I was coding a lot. I was delivering value! I was doing what I was supposed to be doing as an individual contributor. But it wasn’t until I was neck deep in an ocean of puzzles that couldn’t be solved with code that I realized that this is what I wanted to be doing. And to be clear: there is nothing wrong with writing code, collecting a paycheck, and going home. If you want to write code and let other people solve the horizontal problems while you solve the verticals, then you should continue to do that. For me personally, I realized that my high-school dream of writing code most of the time was not what my life was going to look like anymore.
And I was actually good with that.
Today Link to heading
That brings me to today. Due to multiple factors, I was not meshing well at Mastercard. I had a family friend in product reach out to inform me of a position at Alliance, and he asked if I wanted him to put my name in. I said yes, and after several rounds of interviews with the engineers, I was asked to join the team. I’ve been here for a little over six months and I think the impact I’ve been able to have on the organization and our customers has equated to more impact than all of my past experiences put together. It’s been a blast, and I hope to be part of this organzation for a long time to come.
I want to wrap up this article with some words of advice to people still new in their careers as software engineers. Everyone’s experience is different. Everyone has different preferences. I knew a lot of people who were very happy to be at Mastercard. People who loved their jobs. It wasn’t for me, but it still taught me a lot. Both in terms of software engineering, but also in terms of what I want to do, and who I want to work with.
1. Culture is (almost) Everything Link to heading
I am very fortunate to be solving challenging distributed systems problems and solving those problems with some of the best people I’ve ever met. And if they told me tomorrow that I didn’t get to solve those problems and all I got to do was write some basic CRUD apps and call it a day… I might just stick around for that too. It’s so important to work with people that support you. If you’re like me, and you’re in this because you love it, then make sure you are working with people that aren’t going to jade you and make you hate it.
2. Coding is (eventually) Easy Link to heading
If you’re struggling to write good code, that’s okay. It gets better. To me, the real fun is solving bigger problems than the code. As an individual contributor, think about the ways you can add value to the business. Think about the space of the problem, the architecture of your system. As my manager and principal engineer at Mastercard used to say to me: “The code will come.”
3. Try Trying Things Out Link to heading
As you may be able to tell from my lengthy history of only six years, I’ve held a fair few positions in my time. On one hand, I wish I would’ve had some longer tenure for some of the places I mentioned. On the other hand, I’ve got a pretty clear idea of what type of work I want to be doing and who I want to be doing that work with. At the end of the day, if I’m doing software engineering (and my first point above is met), then I will be happy. But try and find things you really like doing. There are always going to be things you don’t like doing. For example, I don’t know a single soul that enjoys being in the on-call rotation. But there’s more to the job than just banging out some code. Find out what those things are for you.
In Closing Link to heading
You and I may be very alike, or we may be very different. You might be brand new to the field, or you might be a veteran. What I hope is that in reading this you will come to know that asking “where do you see yourself in five years?” is a patently ridiculous question. Five years ago I thought I was going to spend the rest of my life in central Illinois working on ag-tech. I’ve often found that plans I have for even the next year can find themselves forgotten or otherwise thwarted. Condsider the engineer you want to be. Consider the organization you want to be part of. Consider the experiment of figuring out hands-on what the answers to those questions are. And be okay with those answers changing over time. The trajectory of a software engineer can take on many shapes and sizes. This is mine. What’s yours?