Everyone who is new to programming will be labeled as a junior software engineer, but your code can make you don’t seem like a junior one.
A software engineer is one of the hottest jobs right now. Many people want to jump into the coding world and apply as a software engineer. Not only that, more universities with a technology background is graduating more people that will be seeking a new job as a software engineer. If you are one of them, you might need to read more in this article.
After applying to some companies, eventually, you will get a new job as a junior software engineer. Most likely you won’t be the only junior software engineer in your new company, and because of that, you will need to become more than the other to make an impact and impression inside the company.
One thing that I understand after I passed the junior level is that I know junior level engineer is scored based on their code quality. The company that hired you will assume that you can code, but with less quality and knowledge at the upper level. Knowledge is not easy to get when you are new in coding, because it can be gain with time, the more you work and research, the more you know.
The only thing that you can be better than the other right at the start of your software engineer career, is about code quality. There are some guides that you can follow in order to make your code much better than what you have ever written in college and during the hiring process. Here are some things that I do in my earlier day as a junior software engineer and it make my coding day easier.
Write a Clean and Readable Code
Everyone can write code, but not everyone can write a clean and readable code.
As a new software engineer that has been hired into a company, you are already capable of writing code in a certain programming language. You might think that your code is already good because it can run and solve the problem correctly. It’s not wrong, but it can be improved much much better.
The first thing to do to prove that is trying to explore and read your company code repository and compare it with your current code style. For me, I was a little surprised or even shocked because my code looks so horrible compared to the code at the company.
There are some simple things that you can do in order to make your code better, and steadily reach the level of your company’s code.
Use a Proper Variable’s Name
When I was in college and do some coding tasks, I never think this was an important thing to do. The only thing I think about is whether my code is solving the problem or not, and it leads me to make a random variable name like the below code example,
That code is working fine, it can print some value and show it to the user. But, what do you think about other people who want to modify or understand the code?
l? what is
v? what is
Starting now, please remove that kind of behavior when you are writing code in your new company. You can rename the variable with a better name so your teammate can maintain and read your code easily.
How’s that after we change the variable’s name? It is so much better than the previous one.
Use a Verb for Function Name
Same with the previous one, please use a clear name for a function. A function is a kind of tool to do something, therefore it will be better if we use a verb for the name. Avoid using a noun for a function, because it can lead to inconsistent between a function and variable inside your code.
Avoid this one:
Write this one instead:
Write Everything Twice
When you writing a program, eventually you will notice that you are writing multiple codes with the same result or intention. This is fine and just continue your work. Don’t let the redundancy distract your work. The important thing is that you already realize that your code has some redundancy and you want to do something about it.
Don’t Repeat Yourself
This is the continuation of the previous note. After finishing your work and realize that your code has some redundancy, you can refactor the code. Extract the part when your code is repeatedly written into another function. Don’t forget to use a verb for the function’s name.
Single Responsibility Principle
Make sure your code especially its function adheres to this principle. The simpler and smaller it got, the better it is. If you notice that your function is doing multiple things at once, and you are having a problem naming it, it means that your function is too big and needs to be separated into smaller functions.
Write like this:
Write Additional Comment
After writing more codes, you might eventually write a code that isn’t readable enough and can make other people confused when reading it. To solve this problem, you can add additional comments around your code.
This is debatable between software engineers, but for me, it is better if you can write a code that doesn’t have any additional comment on it. Adding comment in your code indicates that your code is not clean and readable enough, but it is inevitable the bigger your program and codebase.
Use Validator or Linter for the Written Programming Language
Each programming language has their own standard writing style that has been agreed upon other programmers who is using that particular programming language. By following that standard your code will be much better because you are writing with following some rules.
You don’t have to memorize all the rules for each programming language, because usually, you can find a library or tools to able help you validate your current code whether it is following the standard or not. It’s called Linter. For me that is using Go as the programming language, I am using
goimports plugin in my IDE. You can find the others by googling it with Linter as the keyword.
Learn to Read Documentation
If you ever found documentation inside a codebase or a library that you want to use, please read it carefully. Most engineers that I know don’t like to write Documentation, therefore if you ever find one, it means the creator truly cares about their product.
Reading the documentation will make you master the library faster than anyone who doesn’t actually read it. All the features on that library are written inside them and usually, the developer also gives some example which is very useful for you and your team.
Ask Your Mentor or Senior About Company’s Best Practice
If your company already has at least an engineering team, they might have their own best practice and style for their codebase. This is a good chance for you to discuss and ask them about it. Politely ask them everything that you don’t understand or even when you feel it isn’t quite right.
A good engineering team will always open to a question and discussion about everything that they did. They also like a new-comer, because a new-comer will have a fresh point of view and it can make the code and even team better than before.
Don’t be afraid to ask them.
Read a Lot About Your Company Tech-Stack
You might be confused and puzzled about all the tech-stuff that is used at your new company, and it is very normal. In order to catch up with them, read as much as possible about everything that your company uses.
Sign up for some newsletters, follow some tech Twitter accounts, and of course regularly reading at Medium will eventually expand your knowledge about them.
Spend some time at the start time or end time of your work to read as much as possible. You will be very happy. and surprised with the result when you are able to join some discussion regarding the tech-stack that you previously don’t know about it.
Don’t Hesitate to Join the Code Review Process
Code review is very important to the engineering team inside a tech company. The team got a lot of advantages, and of course, you are one of them. One of the biggest advantages of code reviewing is the transfer of knowledge. This is the best time for you to gain as much as possible knowledge from your team member and even your senior.
Don’t be sad if your code got so many reviews from the others, because it means that they truly care about the product. My biggest record is I got over a hundred review messages about my Pull Request and all of the team members don’t give approval. Surprisingly after doing all the refactor and fix, I have more understanding of the environment and code style within the team.
Don’t be afraid to give a comment, whether it’s a question or a suggestion on a certain Pull Request. You have the right to comment on those and by directly comment it, you will have an answer rather than just guessing in your head.
That’s it. I have told you about how to have better code as a Junior Software Engineer. I hope this will help you become more confident about your code and job role.
Happy Coding! 💻