Becoming A Software Engineer

Today I’ve got some code review to get done, and my release is ready to go to clients. My boss asked me to pick up this release, as the service it is changing to is kind of my specialty; I know it better than anyone else on our team. I also made a note yesterday that I need to ask another team how I should integrate their API into our new service that I’m helping to design. I’ve got a meeting next week about joining the on-call rotation, where I’ll be solving production issues in real-time. I’m a little nervous about it, but I’m confident that I know more than enough to be an effective incident responder. Maybe today I can get some extra work done on my passion project, adding multi-threaded test support to one of our service testing support classes. I feel comfortable each day. I know that pretty much no matter what gets thrown at me, I’ll be able to handle it. But this is how I feel today. Things weren’t always like this.

A year and a half ago, fresh out of college, I didn’t exactly feel like a rockstar.

It’s no secret that most colleges focus heavily on the theory of computer science, which doesn’t do a good job of preparing you for the application of that theory to solve real-world software problems. If you asked me what the difference between a GET and a POST request was, I would’ve had no idea, but I wasn’t just some guy off the street. When I was in college, I took primarily object-oriented programming and SQL classes, without any real time dedicated to web development, and therefore I had no idea about any of the patterns or tools used in the industry. I graduated with a degree in computer science, but I now see the classes that interested me, while providing a solid foundation in CS, created a very narrow range of learning. I learned Java and C# OOP design patterns, I wrote Super Mario Bros in C#, but I never really learned much in the way of practical and modern web development skills.

I did have one internship, but it was centered around proprietary tools, written in VB.NET. Unfortunately, I also never actually got to write any code. The few tasks I was given were debugging a rather strange “code as configuration” system that didn’t teach me any transferable skills. When I did find a bug, I had to report it so another developer could fix it, even though I just needed to change a few lines. At the end of the summer, I found that I really had just spent 3 months watching programming vlogs. I left college with no applicable real-world technical experience, and it made me nervous. I was excited when I met DraftKings at our career fair, did well in my interviews, and received an offer.

When I first started,

I was assigned to the team responsible for handling authentication and permissions. I naturally had a lot to learn, and I felt like I had to learn it fast. Agile tracking software? Automated build software? Don’t I just hit Ctrl+F5 to build and run? Deployment software? What IS all of this!? My teammates were nice, but they were busy. Asking too many questions made me anxious; I didn’t want to be a burden. It’s a good thing our team co-op was very friendly and knowledgeable and I felt comfortable asking them questions. Honestly, I had assumed that they weren’t as busy, being a co-op. (I later learned that that was incorrect, they were just as busy as any other team member..)

It started small. I made a simple database change, then was quickly shown how to push code up, and how to mark it for code review. But I was still learning. I made basic code changes that took me way too long — everything took me way longer than it probably should have. I had never worked with code like this before. Thankfully, my team was patient, and they taught me what I needed to know. One or two slightly stressful but incredibly enlightening months later, I felt like I could actually contribute. I could read a simple ticket, recognize what needed to be done, create a new branch, make the change, push it up, and address simple comments without needing much help. I could also review other people’s basic tickets for simple mistakes, and test the “softball” tickets (tickets needing testing in areas that I understood well).

Right about here I wavered a bit, pretty much exclusively through my own lack of confidence to grab larger tickets. I distinctly remember a period where I refused to pick up any tickets that I didn’t already know how to do. I felt like while I’d been here long enough, people would be frustrated with the questions I would have to ask. This was all in my head, of course. I had never received anything but great answers from my teammates and never had a genuine negative response or interaction. I think I just lacked the confidence to do what I needed to do to learn; pick up a tough ticket that dealt with a concept I’d never dealt with before, and just do it! I feel silly, in hindsight, because I know that I learn best through doing.

My big league debut

There I was, doing my thing, working in the service in which I was most comfortable, beginning to learn my way around it a bit more, when I found one particular piece of tech debt that, while it didn’t affect anything from an end-user perspective, made the system really annoying and difficult to expand. As the person doing the majority of work in this service, it was making my work pretty frustrating. On a Zoom call with my boss, I said, “Ugh this is stupid. Why aren’t we doing [this other thing] instead?” and offered a possible solution. Rather than hear any of what I expected:

• “It’s just not a priority at the moment”
• “Don’t fix what isn’t broken”
• “Shut up noob, go get me a coffee” (ok, this one might’ve just been in my head)

What I actually heard was:

• “What are you telling me for? Write a document and call a meeting so we can change it.”

What? Write a document and call a meeting? Write a document, sure that makes sense, I can do that. But call a meeting? I can call a meeting? I’m the new guy! It was a shocking idea, that I could just schedule a meeting and all of my teammates would show up and listen to what I had to say. Again, this shouldn’t have been shocking because my team had never done anything to lead me to believe my thoughts weren’t valid, but I was the new guy!. Now I had to schedule a meeting because my boss told me to. So, I wrote a document detailing the benefits of my proposed change and the technical details of how I thought we should implement it, and included it on the meeting invite.

Come meeting day, I read through my document and tried to cover all of the important details. Then… “Any questions?” After a brief pause, everyone nodded and the most senior member of our team said “Yeah, let’s do it!” After a bit of tinkering with the specifics later, I was instructed to write the tickets. I broke up the project into digestible pieces and specifically detailed the exact code changes we intended to make. Through this process, I had to dig through code I hadn’t really touched and make decisions about what to do with it. This process opened my eyes to the fact that this was software engineering. There’s no magical quality that separates good software engineers from software engineers like me. The “good” software engineers around me had just taken the initiative to try and be good, and now it was my turn to do the same.

Looking back, I think I could reasonably split my career (so far) into two parts.

Before that project, and after that project. Now, when I have an idea, I present it to my team for feedback, I write tickets, my team and I complete them, and my project is in production a short time later. My ideas directly improve our product. We are able to launch our Sportsbook product in different states easier than ever before, something that I know directly impacts our company in a measurable way. After this project, I started picking up the tickets I was too afraid to pick up earlier. That ticket I wasn’t sure about — I just did everything I could and asked for help with the difficult part and took notes.

Fast forward a few months, and several more of my project improvement meetings later, that engineer fresh out of college feels pretty emphatically in the rear-view mirror. All of the lessons I’ve learned so far show up in the little things. I notice that people are asking for my opinion on things and trusting my answers. I’ve started running releases and reading between the lines in code review more. Once I started taking on tickets I wasn’t sure about, my domain knowledge about our services rapidly expanded and I began to feel ownership of things.

My development really expressed itself when I picked up the most difficult/important ticket I’ve done to date; essentially a total rewrite of our authentication token code and how the tokens are stored. This involved some pretty cool tech and required a lot of very careful design considerations due to the sheer scale we were working at. My code would have millions of requests going through it. Sure, my code was operating at scale before this, but this was different. It was such an important part of our codebase.

Sometime after that ticket ended

I was happily doing my job every day. Someone asked us for clarification on one of the more subtle points about our authentication token logic and my boss referred them to me saying, “He knows the most about authentication tokens.” And that blew my mind. Just a few months prior I couldn’t tell you what a GET or a POST request was for, but now, I know the most about a backend system that is totally critical to our business.

I don’t feel like the same software engineer that I was when I started. I feel confident and competent in my everyday job. I pick up complex tickets that challenge me and complete them on time with a great deal of independence. I go out of my way to propose and write cool solutions to interesting problems. I genuinely feel the impact that my actions have on our team’s goals. I don’t think I would have learned as fast had I kept up what I was doing and if I wasn’t encouraged to take on that early refactoring project. I just wish that I had had the confidence to take up something like that myself sooner. That’s a very important lesson I learned here: Don’t wait for someone else to have confidence in you, have confidence in yourself!

You might be that engineer from 2019.

You might be just like I was, trying to hide how little I knew from my boss because I thought I was just a hiring mistake. You might be wondering how you got into your current job, or how you’re ever going to get a job where you really get to contribute to a serious codebase. There’s no magic answer that’ll make your imposter syndrome go away, and it can be difficult to ignore. Do your best to not listen to your imposter syndrome. Instead, listen to your ambition. Open that confusing piece of your codebase and find something to improve. Not working anywhere yet? Find an open-source project you’re interested in and start reading, maybe even fork the repository and make some changes. You’ll be shocked at how much more you know when you’re done. Then, do it again!

…

Interested in learning more about #DraftKingsLife? Here, we’re inspired by our shared passion for developing creative solutions to complex challenges and empowering the people around us to do their best work. We’re Hiring!