Lessons I Learned My First Year As A Software Developer That Have Very Little To Do With Coding

December 4th marked my one year anniversary as a software engineer/developer/programmer/coder and after a year I have learned a few things. One of those things is that job titles mean very little, especially in a startup but I’m getting ahead of myself. So here are some of the non-technical lessons I have learned about being a developer in the past year in no particular order.

Being a software developer means being constantly overwhelmed but productive in spite of it

About 2 weeks into my job I had a bad day. Well I had a lot of bad days in my first year but this day I complained about it and the advice I got was that consistently succeeding at this job is hard. It’s true! Technology is constantly changing. Business logic is fuzzy and evolving. Algorithms are hard to track and predict how they’ll interact with other code.

It’s overwhelming. It’s more whelms than anyone can handle every day and it doesn’t get any better which is comforting in a weird way. Hearing that experienced developers struggle is a reminder that programming is hard regardless of how much experience we have.

Programmers are constantly being told we’re wrong. It’s a big part of our jobs and that’s OK

The afternoon of my first Friday at my new job I got a message from my lead developer, Nicholas. It was something along the lines of “We need to talk about a mistake in your code on Monday” and I started to worry. “What is he going to say? How will I deal with this criticism? He’s going to tell me I’m wrong!!” Then I started to panic a little. Then I thought about what I had been doing all week. Then I chuckled at myself.

When I run my code that doesn’t work correctly, my compiler tells me I’m wrong. When my code works, but not the way I intended, the results tell me I’m wrong. This happens multiple times a day. I am told constantly that I’m wrong by my computer so why should it be any different when the criticism comes from a person? Being able to take criticisms at face value is a good skill to have in this career. We are wrong and we are wrong a lot. And that’s ok. It’s just part of the job.

Questions are just questions

One big thing about working in a team is that other people are required to read and understand the code that you write. At Infinicept, this is the primary reason behind pull requests. I had never worked on a team before so initially I got very defensive when another developer would ask me why I did something a certain way and I would assume that I did the thing wrong and that they were passive aggressively letting me know that I was dumb. This is a lot to assume from someone asking a simple question.

Engineers like solving problems and we like finding different ways to solve the same problems. The kind of engineers I work with (and like to work with) like to help each other do this. This should be assumed to be the reason for questions until proven otherwise.

Equal parts pride and humility are required for this career

Being new to professional software development, my humility was unbound. No one was more humble than I was (that’s my favorite humility joke)! For months, my impostor syndrome was a huge part of how I saw myself even though I was aware that impostor syndrome makes no sense especially when I had the job and I was helping to hire more developers and I was contributing code and it was working. Too much humility makes you miserable.

As I took on more tasks, I found that I had to have a certain amount of pride to start the new task. I had to tell myself “I can do this thing I’ve never done” or “I can learn this thing I didn’t know existed til just now” or “This new idea is worth trying even though I came up with it.” We need to be proud of our work and our ideas to write code! However we can all picture working with someone with too much pride. That one person who doesn’t accept feedback and listen because they know all the things? I don’t want to be that person.

Being a software developer requires being proud of your ideas and your work and being accepting and proud of others’ ideas and work!

It’s VERY important to take care of yourself!

In March I started to feel like I should be more competent. I had been a professional coder for 4 WHOLE MONTHS. Instead of feeling accomplished, I felt stressed that I should be able to do more. Our company was delivering our first real big-deal deliverable to an important client at the end of the month and my daughter was struggling with a strange issue with her elbow that was very painful and required surgery. All employees were working 10+ hour days and weekends. Oh, and I was finishing up my last Computer Science courses for my degree.

For the whole month I didn’t go to the gym once and survived almost solely on caffeine and alcohol. Then at the end of the month, after I had served in the Marine Corps and spent 12 years as a 9-1-1 dispatcher, I had my first real anxiety attack. I never want to do that again. My coworkers, managers and founders never want to have a month like that again. So we all resolved to take better care of ourselves and each other as people.

We do not do good work when we are too tired and/or too stressed. This is why it’s important to take care of our mind and body. Also it just makes the job and life more enjoyable!

Programming knowledge is not linear

Working for a brand new startup meant that I got the opportunity to help hire more developers which meant I got to talk with a few developers who had more experience and it makes sense that someone with 5 years of experience as a programmer would have 5 years more knowledge about programming. It turns out this is not true.

First of all, “experience” is a very vague term. Two years of being pigeonholed in doing small repetitive tasks is way different than spending two years building and designing new things. You can have two years of experience or you can have one year of experience twice and it’s hard to tell at a glance what kind of experience someone has.

Then there’s the ever changing world of languages and frameworks. Did you know all the things about JavaScript four years ago but haven’t used it since? Did you switch from a back-end role to a dev-ops role? What knowledge did you or can you retain from the work you did 3 jobs ago?

It is impossible to assume that another programmer knows more or less about a specific technology just by looking at their years of experience.

You’re going to encounter bad code

Learning to code involves starting from “Project -> New” and all the code you write is very small in scope, structured properly and efficiently and checked by someone who knows better. Then that project is quickly discarded for another project that highlights another concept.

Writing code as a professional developer involves working on the nth iteration of a code-base using libraries, tools and concepts that may or may not work well together. At first the code won’t make sense because you’re new to all this but sometimes code won’t make sense because it goes against best practices or just doesn’t work and no one really noticed yet.

It’s VERY hard to tell the difference between the two starting out but I found it very liberating to find out that some of the code I didn’t understand was code that didn’t make sense.

It’s also very important to consider why the bad code happened. There are tons of reasons other than “This person is teh stupidz!” for bad code. It’s important to have empathy for that prior developer because that prior developer is going to be you one day.

These are just a few of the things I’ve learned in my first year as a software developer. I look forward to all the things I get to learn in the next year!

Leave a Reply

Your email address will not be published. Required fields are marked *