Starting my engineering career at Workiva
During my first week at Workiva, I was an emotional mess. I was incredibly excited to have an opportunity to work at what I considered to be the best job in my city, but I was also extremely self-conscious about my technical abilities and unsure if I would fit into the culture.
When I received my internship offer, I was in the midst of completing a college computer programming degree and knew I had a long way to go. Since then, I’ve come far in my journey. Now, I’m not nearly perfect and still make plenty of mistakes. However, I have learned a great deal about the industry, culture, programming, and most importantly, myself.
The lessons and advice I set out below are things that I’m still working on and aspiring toward. Much of what I have to say is a work in progress. The purpose of this post is to encourage self-growth through deep retrospection. Examining our past achievements and failures is essential to moving toward being better developers.
The first ticket
I remember listening to our team’s first review and thinking to myself, What in the world is going on? I could barely understand what was being said. Regardless of all the cool sounding terminology being used, I felt completely lost. Everyone around me was so highly engaged in their work and extremely intelligent.
For the first time in a while, I felt like the dumbest person in the room. It was liberating in a lot of ways. As intimidating as this may sound, and it was, I felt excited at the prospect of becoming highly engaged and a valuable member of my team just like the people around me.
When I was tasked with my first ticket, the requirements were briefly explained and then I was set loose to get it done. On the inside I was thinking, What have I gotten myself into? I have no clue what I’m supposed to do. On the outside, I was doing my best to keep it together and make it clear that I was up for the task.
To get started, I first attempted to answer all the questions I had on my own. When I was confronted with questions I couldn’t find the answers to, I asked my mentor for assistance. Slowly but surely, the first ticket got done. I was excited to see the glorious purple “Merged” label on my first pull request (PR).
I received a lot of mixed advice around this time about how to handle the challenge of getting work done. Some said that it’s important to ask as few questions as possible. Others said that it’s important to ask as many questions as possible. I took that to mean that those who suggested I ask as few questions as possible meant that it was ok to spin my wheels. To become a good developer, it’s important to be able to figure things out on your own. On the other hand, when starting out, you’re in a position to learn and asking lots of questions is an expectation.
Having said that, I often made the mistake of spinning my wheels for too long, and this is still something I’m working on. I always want to be able to find the required solutions myself, but this approach is not always realistic. I’ve learned many valuable lessons from this mistake. It’s no doubt important to get deeply invested in a problem—I find you learn a great deal from the challenge. However, it’s also important to recognize when you need help.
Asking for help can be very difficult at times. It’s easy to get caught up in your own mind determining when a call for help is required. I worried that asking for help meant that I wasn’t up to the task or that I couldn’t do it. I worried that the question for which I sought an answer might have an incredibly simple solution. I also hesitated to ask questions because at times, it seemed like I was working on something much less important than everyone else. These fears are legitimate, but the sooner you get over them, the better off you’ll be.
It’s always better to ask questions regardless of their complexity when you’re truly stuck, than taking a long time to come to a solution yourself. I honestly believe you’ll learn more this way. All the people I have had the privilege of working with have been incredibly helpful and usually get genuinely excited about answering questions.
That being said, answer as many questions as you can yourself. It’s important to try. Developing a reliance on your own mind will also give you greater confidence as the challenge in your work increases. I believe it’s important to have at least few attempts at a solution before asking for help.
Failure is a part of becoming a strong developer. It’s essential to embrace failure because it is out of failure that we learn and grow. That may sound cheesy, but there’s a great deal of truth here.
That’s why the next piece of advice is to put up your code as a work-in-progress PR as soon as possible. Yes, it’s important to polish your code and make sure it’s as clean as possible, your comments are free of spelling mistakes, your imports are alphabetized, and your logic is clear. However, the sooner you put up your code, the sooner you’ll get advice on improving your work. There is so much we can learn from full-time staff, but that isn’t possible if they don’t see your code.
Inviting feedback is a great way to learn. People are busy, and you might not always get everyone’s attention, but the advice you do get will come from a place with your growth in mind. That’s why it’s so important to not be afraid of sharing your ideas and putting up your code.
The Workiva culture embraces failure. It’s ok to make mistakes so long as you look at them as an opportunity to get better. As interns, we’re here to learn. The pain of putting up code that you may not be entirely confident in is like pulling off a bandage really quickly. The pain of spinning your wheels and not getting any traction is like pulling off a bandage very slowly. Showing your code and learning to accept criticism sooner will make you more productive, more valuable to your team, and better at writing quality code faster. We all struggle with finding the right balance between spinning our wheels and asking for help. Putting up your code earlier will help with course correction and ensure that you’re at least pointed in the right direction.
Getting too close
It’s easy to get lost in your work and get too close to a problem. There have been many occasions where I got way too close. I was so deeply invested in the problem that I overlooked the simple solution that was right in front of me. All it took for me to find my simple solution was to step away.
It’s easy to overcomplicate things in our extremely complicated industry. That’s why it’s important to have at least two things on the go. When you find yourself getting stuck, it’s ok to leave the problem for a little while and work on something else. You might surprise yourself when you return after a few hours away.
Our brains are constantly working on solutions to the problems with which we’re presented even if we’re not consciously working on them. Those few hours away could bring the clarity required to find a solution. The worst case scenario would be that you’re still stuck on the original problem but have made progress or come to a solution elsewhere. At that point, it might be in your best interest to reach out and ask for help, or put up a PR and invite a few team members to offer some advice.
It’s also possible to get easily overwhelmed when taking on too much work. I highly recommend keeping only two tickets on the go and take on a third when both are in the code review stage. We work in complex code bases, and it’s difficult to switch gears constantly. Working on too many problems at once can easily overwhelm the mind. There are times when we will have more than two things on the go, but staying focused on completing one item at a time is the key to success.
Feeling like an imposter
If you feel like an imposter at times, you’re not alone. We’re surrounded by world-class developers, and it’s easy to get lost in the gap between our current capabilities and theirs. Take things day by day instead of looking longingly at where you desire to be professionally.
Progress is like tackling any problem. If you’re entirely set on the end goal, it’s easy to feel lost. You have to break it up into smaller chunks and take the steps toward the solution sequentially. In other words, it’s important to take things one day at a time.
When I first started my internship one of my coworkers told me, “This job is going to beat you down at times, but when you get back up you’ll be stronger and better.” This isn't meant to sound malicious or invoke fear, but it’s important to remember that that is the goal—to make you stronger and better. As interns, we have to have the courage to face that and the perseverance to keep getting back up. There is an endless learning curve and getting to a position where we can keep pace is the ultimate goal.
I’ve thrown around the word intern a lot throughout this post. This may not be the best way to identify myself or anyone else starting out. Yes, that's the title on our contracts, but I’ve never felt like an “intern” at Workiva.
From the moment I was assigned my first ticket, I was never treated as if I were making less than meaningful contributions. Your coworkers have high expectations of you and you need to have even higher expectations of yourself. On my first day, I received a laminated business card sized printout containing the words: “If you’re not failing, you’re not trying hard enough.”
About the Author
Sebastian is a Software Engineer at Workiva on the Web Platform Team. He is driven by the creativity and lifelong learning required for success in software development.