By November 18, 2019

First Year as a Programmer: Mistakes and Outtakes

There is a saying that every programmer is shaped within their first year of professional experience. Although I believe that you can reshape yourself (with significant effort) after the first year, it is indeed crucial to your success.

I began my first job in the second year of my four year bachelor’s degree. I started at the end of my third semester (early December) working part-time and then awkwardly switched to working an average of 10 hours a day, six days a week during the summer.

While at this job, I learned a lot about the ins and outs of the business. Most of this learning was, unfortunately, done through me making mistakes and having to go back and correct them. This cost me time I could’ve been using elsewhere to better my skills and my professional reputation.

Let’s dig into my first year as a professional software developer to see the many mistakes I made and how you can have a better start for the sake of your professional growth.

First Year Mistakes I Learned From

I got my first job rather easily—it was the only interview I went to. One late night, I sent out several CVs to companies looking for junior developers. About two weeks and several stages of interviews later, I got the job.

Almost instantly, I started making countless mistakes that severely hindered my professional growth.

Being Overconfident About My Knowledge

Needless to say, I had no prior experience with real projects; I had never built anything that was deployed and used by actual people.

My projects to that point had consisted of several classes that usually took their input from the terminal console.

No databases. No external systems. No external APIs. No configuration.

In my defense, one year earlier I had had no idea how to write “hello world,” but that didn’t make my day-to-day tasks easier.

To make things worse, I didn’t know how to navigate large code bases, how to ask the right questions, or how to get people to lend a hand without annoying them. It wasn’t the start I had been imagining. 

Looking back, it’s pretty funny that I thought I would be crushing it. It was a very pure moment of programmer arrogance.

How did I fix it? 

Hard work. Remember the 10 hours a day, six days a week I mentioned? That was my summer vacation. I’d say I came out a decent programmer. The alternative was to spend one to two years grinding part-time to get to that level, but boy oh boy was it hard. I didn’t enjoy it, but found it extremely necessary.

Waking up, going to work, getting home from work, eating a TV dinner, and going to sleep almost every night isn’t fun, trust me. If I could do things over, I simply wouldn’t put myself in that sort of position.

Certain aspects of the job I thought would be important to study and understand beforehand ended up being less significant when it came to actually applying them. 

Don’t get me wrong, algorithmic one-shot types of questions will definitely be on the interview and preparing for them will get you through the door, but this is only the beginning.

Other than personal projects, if you can afford it, don’t rush getting your first job until your skills are relatively developed. Your first year, the majority of your time will be spent not only working on the project but also learning all the tools, frameworks, and libraries the company uses. Learning the basics of git in advance is an often overlooked opportunity to make a good impression.

Lack of Soft Skills 

Let’s cut to the chase—I didn’t have the proper soft skills.I didn’t know how to ask the right questions. I didn’t know when to interrupt people, how to write emails that add value, or how to work with people.

The result was my productivity going down the toilet. I wasted my time doing the wrong things, having to redo them, and needing way more help than I would have if I had known what to ask.

It felt soul crushing.

However, I knew that although people were tolerant and understanding, this wouldn’t last forever. I had to act.

John Sonmez’s book on soft skills wasn’t written at the time, so I had to scramble around for information. This process was painful, but in a few short months, I managed to fix all the major issues.

The biggest one I faced was that often my emails didn’t have enough details. I fixed this by imagining that the person who reads the email has no idea what I am talking about and knows no specifics.

Even though the people who will read the email sometimes do know all the details, the reality is that most technical people read emails in between their tasks, which means they aren’t necessarily thinking in the context of your email, so the details may help them remember things faster and prevent them from making mistakes.

Putting yourself in other people’s shoes can help you provide others with enough value to make it easy, almost criminally easy, for them to do the work you need them to do. 

Not Looking After My Interests 

As a junior, my mindset was “do whatever, just get better; learn as much as I can, whatever the cost.” This is a good way to move fast, but you must be wary not to burn out.

For me this was the projects and impact I was working on. Clearly, as a junior you can’t be given too much responsibility or impactful tasks, but even simple tasks can be spun in a way that can benefit you and help you learn. 

Personally, this went on for the better part of a year before I was able to talk to my boss and start getting more impactful work. 

I was in no way ready to make those decisions on my own, but my boss mentored me, and little by little I started making changes by myself.

The second biggest way that I see first year developers not looking after their own interests is that people aren’t looking after their health when working—taking overtime, not getting up from the chair often enough, not drinking water, etc.

Luckily, this is something that can be taken care of rather easily. Set a timer for every 40 minutes or whatever is convenient for you, and get out of your chair. Take a couple of minutes to walk around and let your eyes rest. Drink some water.

Take care of yourself and your career. You are your responsibility.

The First Year Is Your Foundation, But You Can Rebuild

Let’s say you’ve been at a bad place in your first year, or you already have decades of bad habits formed early on. How do you improve?

There are certainly some challenges, but I believe that anyone can do it.

If you want to improve at anything, there is one specific thing you need: Time. Large chunks of it, preferably uninterrupted.

Do you have that? OK, good.

The next thing to ask yourself is “How does one improve their foundation?” 

There are a few key factors. 

First of all, you need to be open to change. You need to accept that some of the habits you’ve developed are wrong and that you need to hone your craft further.

Second, you want to review your work and see what can be improved upon.

There is no golden rule about pinpointing your weak points. You may have to use a rulebook as a reference to test your code against. This can be a tricky step, since a bad rulebook could actually have a negative effect on you. 

A mentor will help, but this isn’t realistically possible for many people. 

Remember, learning is an iterative process. If, for example, you want to improve the quality of your code, and you pick a rulebook, chances are you will have to go over it several times before you can start adopting its practices.

Automation is always your friend, and you should use it if you can. Enable all code linters, style checkers, and the like! It will help you notice mistakes as you write them.

Lastly, don’t give up. Improvement takes time. Focus on improving, and don’t rush yourself. You’ll get there, I promise.

Be Prepared

Whatever your first job throws at you, be prepared. If you fall, get back up. Remember that gaining experience and seniority is a process. It will take time, and you will surely make the occasional misstep or mistake along the way. 

So don’t worry. Take your time, learn the necessary requirements for the job, gain some soft skills, take care of your personal health, and above all else, be patient.

Success takes time. It takes hard work and constant commitment. Hopefully, these tips will help lighten the load for you and help get you started down a healthy and very successful path.

I believe in you. Don’t forget to believe in yourself, too.

About the author

Zlatin Stanimirovv

When not dealing with high scale distributed applications with millions of active users Zlatin usually tries to get to the next level in building scalable and performant software with high quality code. Consistency, quality and automation are his priorities. Get in touch with him on LinkedIn or check some of his open source projects here.