My Biggest Mistakes as a Junior Developer
October 19, 2019
Photo by Sarah Kilian on Unsplash
I graduated from college bleary-eyed, in-debt, and ready to tackle the world of “professional” software engineering.
I had learned about Agile and kinda-sorta-not-really practiced it in my internships. I had written lots of code between classes, personal projects, and various employment gigs. I had even tried my hand at moderate design proposals and bigger-picture thinking.
I felt confident that I was going to have a good start in my first career software engineering gig and was eager to start. I was like most engineers fresh out of school: I was ready to learn, grow, and become the best engineer I could be.
And like most junior engineers, I made mistakes. Within my first two weeks, I had already written a bug that caused one of our team members to work extra hours to get a report delivered on time.
Most of the mistakes, though, weren’t about bugs that I wrote or not finishing a project in time (both of which did happen). Most of them were about my fear of looking stupid. Many refer to it as imposter syndrome. I was afraid to admit not knowing an idea, concept, or that I was having trouble remembering how to traverse a tree. This fear led me to a few mistakes at the beginning of my career. By sharing my mistakes, hopefully, you can avoid them in yours.
I Didn’t Ask Enough Questions
I knew this in my head, but actually experiencing and feeling my lack of knowledge didn’t lead me to ask questions. Instead, I figured I didn’t belong and would try searching for all these ideas I heard via Google and Stackoverflow (like any good developer, right?).
In meetings, I would just silently nod and agree with what the others on my team were saying, hoping they wouldn’t directly ask for my input.
In code, I just kept reading more and more of the terrible code I saw (my first role was attempting to bring an arcane billing system up to date), hoping that it would eventually explain itself. It never did. I would spend hours pouring over code that I couldn’t make sense of because I was too afraid to ask for definitions of acronyms or terms I didn’t know.
Ask questions! Don’t believe the lie that you are incapable of understanding something simply because you didn’t understand it the first time it was explained to you. Remember that every engineer on your team had to learn everything they know; they didn’t walk out of their education or experience knowing it all either. They probably needed some help learning it too, so don’t get discouraged.
Or they are like you — just trying to keep up. You would be surprised how many engineers just nod and silently agree about an idea and have no clue what it is.
Instead of being ashamed, learn how to ask great questions that are focused on elevating understanding for the whole team. Examples might be:
- “You mentioned something about partitioning that table that I didn’t understand. Could you walk me through it a little more?”
- “I’m having trouble understanding how this project is architected. Do we have any documentation on that you could point me to?”
- “I’ve been trying to learn a little more about how to use ansible, but I think I’m stuck. Would you be willing to help me clarify a few things?”
I Made Too Many Statements
On the inverse, when I wasn’t asking questions, I was making statements. Usually, these statements were also disproportionally loud or confident in comparison to how much I knew.
I found this happened to me around the one-year mark. At that point, I had gained a lot of knowledge, didn’t feel like the new guy, and wanted to show off what I had learned while on the job. I think this is important actually to remember: the types of mistakes made will change over time in any career.
I was too quick to assert an opinion and too prideful to listen to others.
I wasn’t until I was on a project on the brink of collapse that I realized how much I had been doing that. Our team got some new senior engineers who took a look at what we had been building and quickly starting to show us what we had been doing wrong. Granted, we should have had a few actual senior engineers on our team before that, but can’t control that.
It was in that process that I realized I still didn’t know what I was doing. I still had way more to learn than I had realized. I learned to listen, to ask questions again, and to be ok with not knowing everything.
You will likely experience a similar moment. A time when you realize you have learned a lot but have a truly humbling realization, you have much more to learn. If you can, try to have it sooner rather than later. The earlier you truely embrace that you will never know it all, the faster you will start learning and growing.
I Stopped Doing Non-Project Coding
This is where I think I lost the most ground. Instead of continuing to hone old-school coding chomps, I kept focusing more and more on just the code in front of me.
Don’t get me wrong, focusing on the code and projects for my employer was (and still is) vital to being a successful engineer. However, I wish I would have traded say two hours a week of project-specific coding to do either open-source development or do coding challenges on LeetCode or TopCoder.
Why? Well, because after a while, most project code tends to find a “mass” around a few particular coding concepts. I work mostly on building high-throughput and low-latency distributed services that communicate via RESTful APIs at my current employer. It has some significant challenges, but after a while, most of them are similar to each other. I find, therefore, that I solve most of them in very similar ways.
But I haven’t worked on anything related to graphics engines or even simple text editors (and many more). I don’t know for sure they have a different set of challenges, I would bet they do.
Working on other code besides your work projects is a great way to keep your overall coding skills up and, potentially, boost your resume via open-source contributions. If you invest just a few hours a week, I bet you would find your skills skyrocket. If you don’t think you have the time, ask your manager if you could reach an agreement on how much time you could take at work to do so. After all, becoming a better engineer is valuable to you and them.
I made many more mistakes, of course. These are simply the ones I feel hurt me the most.
The first two comes down to pride of either not looking stupid or wanting to look the best in front of others. Don’t fall into those traps! When you are focused on what others think about you, remember they probably don’t care as much as you think.
The last one is just old-school grit. I forgot to practice the skills that lead me to my first software engineering role in the first place, which was a dedication to the craft of code. Since becoming a senior engineer, I write more non-project related code than ever, and it has helped me write better code for my work projects (and write it faster too!).
I hope this helps you navigate starting your career as a software engineer! If you have any other mistakes you would like to share or ask questions about, leave them in the comments. I’m not perfect (clearly from this post), but I’d love to try and help if I can.
Happy coding!
If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.
Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.