Written by Corey Slaven.
As you may know, being a software engineer is a constant process. In an industry that moves as fast as tech, there are lots of new things to learn. New frameworks, new languages, new hardware.
It never stops.
I just completed my first year as a junior software engineer. This year challenged me beyond anything I could have ever imagined. I have decided to share with you the most important things that I have learned in the past year as a developer.
How to learn a new codebase
I cannot tell you how happy I was to start my career as a software engineer. I walked in with a smile on my face ready to learn.
I was convinced that I knew everything that I needed to know to get up to speed on any project that I was put on.
I was ready to conquer the world.
I quickly learned that this was not the case.
My jaw dropped to the floor when I started working on my first issue. The project I was working on was larger than anything that I had ever touched. I was having trouble just navigating around.
It was difficult for me to see how all of the different pieces interacted. I was just staring at the screen at one point, when one of the senior developer told me to stop.
“Stop staring at the screen! Just break the code!”
This was a terrifying thing to be told. What if I broke something important, or something couldn’t be fixed?
I was quickly reassured that nothing could go wrong, as all of our code is maintained in version control. As long as I was working on my own branch, everything could be reverted back to normal.
I really just needed to start breaking the code.
What could go wrong?
I started commenting out bits and pieces, guessing what would work and what wouldn’t.
Slowly but surely that helped me recognize how different parts of the system interacted with each other.
By breaking things, I was able to see what was needed in a codebase and even what may not be needed. It helped me not only figure out how the code worked, but also that some code didn’t even need to be there.
I now use this technique when learning any new codebase. I just have to make sure that I don’t push any broken code to version control.
How to communicate
Having largely spent most of my time learning how to code by myself, I had to learn how to code with others once I got into a professional environment. This was a difficult lesson.
I had to learn how to articulate complex concepts to others around me. This came out as a garbled mess more than once.
Even though there were times when other developers had no idea what I was trying to say, I didn’t get discouraged. I took deep breaths and thought long and hard about what I was trying to say.
There was plenty of technical jargon that I simply didn’t know.
In time, and through a lot of practice, I was able to start describing things in a manner that other developers could follow.
Beyond describing things that I was talking about, I also had to let others know when I didn’t know what they were saying.
Sometimes it is easy to just nod and say you know what another developer is trying to tell you.
Though it may be easy to just nod and smile, this generally ends up being an issue.
Don’t be this guyI always try to let others know when I don’t understand something, no matter how simple the concept may be to them.
Communication is key in this industry, as good software cannot be developed without it. How the heck are we going to build anything useful if no one takes the time to explain or understand what we are trying to do?
Here are three things I consider crucial when communicating with others:
Listening
I try to consume everything that the other person is trying to convey. I think about how I am going to respond and then reply. I try not to make assumptions. I try not to cut someone off mid-sentence, or claim that I know what they are going to say.
Please listen.
Patience
I try to be patient when communicating with others. I may have to explain something more than once before they understand what I am truly trying to tell them. Everyone operates at a different pace. It pays to be patient.
Empathy
I think this is one of the most important things to develop good communication skills. As humans, we all run into differences between one another.
We will have differing opinions, incorrect assumptions, bad ideas, good ideas, terrible days, and wonderful days. I always try to take into account the other person’s perspective when communicating with them.
Treat others the way you want to be treated. I consider that to be law.
As I learned how to communicate better, my days got much easier. My productivity shot up as I was able to work with others more efficiently.
Though I had mastered many aspected of communication, there was still one key aspect that I hadn’t mastered…
How to ask for help
This was one of the hardest lessons for me to learn.
I am one that had a very hard time asking for help. I always felt like I could figure out things on my own.
It was a combination of me trying to prove myself (silly, I know) and my ignorance on how to ask for help that prevented me from doing so.
I finally learned how to ask for help after I had been investigating an unknown bug in a project I was working on. I worked on the bug for some time and then decided to ask another developer for help.
I went over to the other developer in a bit of a panic. I was basically just flailing my arms around screaming “BUG, BUG, BUG!”
Das Me
That’s not exactly how it happened, but from the other developer’s perspective, that is probably how it seemed.
He, and another senior developer, decided it was best for me to sit down with them and have a conversation about this particular event.
I learned that it was not constructive for me to interrupt another developer to let them know that there was a bug.
It is not constructive for me to let another developer know that I need help without any context as to what I am having an issue with.
I learned that there is a formula to asking for help.
Instead of flailing my arms about and screaming about the presence of a bug, I learned this simple formula:
“I did this thing, and something happened, but I wanted this to happen instead. I have had trouble figuring out why this is happening. When you have a moment, could you help me find the root of the problem?”
This always incites good conversations and generally will lead to a solution to the problem.
Making everyone happy
I had not realized that my previous approach to asking for help was counter-productive and not good for anyone.
I honestly had no idea how to ask for help.
If you are like I was, and you don’t like to ask for help (or you don’t know how) please ask for help. Remember the formula.
Others will want to help you if you ask in the manner I have suggested.
Documentation
This is something that I learned out of necessity.
No matter how many times you tell me how to do something, some things I will never remember.
There are language quirks and programming practices that I always have to Google.
The more projects I worked on, the more I realized I was simply not able to remember everything. This led me to start documenting.
There are way too many moving parts of ANY software project not have any sort of documentation. I do not care if it is in a README or a PDF.
Pretty much any form of documentation is better than no documentation.
Clearly, I am very opinionated on this subject.
There is nothing worse than no docs. Getting started on a project with no documentation is a nightmare. It slows everything down.
Documentation should be clear and concise, providing developers with everything they need to know to get up and running with a project.
I stress this to other developers on my team, and among my peers. I am always happy to write documentation.
It can be tedious and time consuming, but it will make everyone's life easier. That’s the whole point!
So there you have it!
I learned a lot in my first year as a software engineer, and I consider these lessons to be the most important. I still have a lot more to learn, and I look forward to doing so!
Please share with me any experiences you have had as a software engineer that may align with some of these lessons that I have learned. I am very excited to hear what you may have to say!
A little about me: I am a self-motivated software engineer from Florida. I used resources such as freeCodeCamp to start my career in the tech industry. Here is my website: http://coreyslaven.com/
You can follow me on Twitter here.
Thank you for reading!
Happy coding!
Sometimes the hardest lessons are the most important ones to learn was originally published in freeCodeCamp on Medium.