Being a software engineer is hard — There are many aspects you need to improve. Most of the times, people just focus improving their skills at one aspect and forgot the others.
Everyone who has just starting doing software engineering will always make a mistake. In 3 years of the beginning my career as a software engineering, I had done many mistakes. In this article, I will share 5 mistakes I noticed the most and why they’re important.
Not creating a unit test
Photo by Science in HD on Unsplash
Creating Unit test — a process that every software engineer despise. Imagine that you worked hard to create a complex feature for days, and after that you need more days to create the unit test. The deadline is coming, one of the piece in the code is very hard to cover. You tell yourself “Man, why do I need to create a unit test, it only slows the development process”. Unit test is not that important, only bring troubles, you might’ve think.
Unit test, Integration Test, or maybe another kind of test, is something many software engineers rarely like doing. But it is a very important process in software engineering.
Finding bugs before your codes goes to production
Unit test is the first gateway to make sure that your code behaves as expected when it’s deployed in a staging or production environment. When creating a unit test, you often discover bugs in your code. This is very critical, especially in a large company that has many processes before your code can go to production. Large unit test coverage shows that the software engineers that developed the feature are aware how their code behaves from end to end. It’s the first filter on finding bugs.
Making sure other software engineer doesn’t break your code
Unit test will make other software engineers aware of how your code behaves and its expected response. It will make sure that other software engineers working on your project don’t break the behavior of your code if they don’t intend to. This is very important, especially if there are many developers in your projects or company.
How to Improve
Cover as many lines of codes as you can, typically you can consider tests that cover 90% of the codes as good enough. Make sure that you fully understand the code you’re writing the test for. Sometime you will find a bad unit test written by other software engineers. If you have time, fix it too.
Not designing
Photo by Med Badr Chemmaoui on Unsplash
A good software engineer will design first, execute later. Before you code or start a project, you need to know how your product will interact with other products. A product in this context could be services, a service, an API, or even a method.
Designing your code before you code might feel like a waste of time. But it might be something that saves you from refactoring lines of code or introducing tech debt you need to fix.
Why is it important?
The bigger the project is, the more complicated and the longer the time needed to create the design, also the more critical it is. If your project is big, it might cost more time not designing it well than making a thorough design, because the bigger the project is, the more it is prone to fault.
Save you from code refactoring
The first fault that might happen if you don’t design a project well is you notice that something won’t work at the end of the project, to fix it, you will need to refactor a lot of codes, or worse you need to scrap and restart the project. If this happens, it might cost you more time than going through a design phase.
Save you from tech debts
The second fault is that, even if your project is running smoothly, it might introduce tech debts that need to be fixed later. If you keep compounding tech debts, you might need to rewrite the services affected if it’s already too much. Rewriting a service will take a lot of time because you need to design everything from the beginning.
How to improve
Think about the interactions between component before you code. It’s best if you also create a documentation like diagrams and a readme, it will help a lot with integration and future projects that use your code.
Making a complex code
Photo by Christine Sandu on Unsplash
KISS (Keep it Simple, Stupid) is how an experienced software engineer codes. Code readability most of the time is the number one priority when coding after security.
Avoid showing off your capability with complex code
This is one of the typical mistake of someone who just started coding. Usually a software engineer will think many ways to solve a coding problem. A good software engineer will take the simplest approach, making the code readable. But, a new software engineer tends to use the more complex approach to show the more senior software engineers that he/she can understand and use a complex code.
Showing that you’re capable is not wrong, but you’re destroying the code base for it. Remember that your codes won’t be untouched forever. Another software engineer will look at it and need to understand it too. Create a simpler code for them.
Readability of the codes most of the time is more important than performance
It depends on the need of each project. But a software engineer lacking of experience most likely won’t be assigned to a task that focuses on performance.
You can make a complex code which only you can understand that runs faster by 50 milliseconds compared to the more readable code. But, when other person works on your code, they might just refactor and delete it.
Creating a complex code with an excellent performance is often not worth it. In software engineering, time to deliver a feature is usually tight. By creating a complex code, you will spend more time coding it.
Complex code will confuse other software engineers
A complex code uses hard to read and understand, it will confuse other software engineers. When other software engineers read your complex code, they might just give up and rewrite your entire codes. If they do this, then the time you spent coding the complex code will be lost.
How to improve
If you have many ways to solve a coding problem, always use the simplest one. Using a simpler code will improve readability and maintainability of a project. If you want to show that you’re capable, you can create a simple code, I’m sure your superior and coworkers that review your pull request prefer that too.
Not Documenting
Photo by Bernd Klutsch on Unsplash
Documenting is boring, but, is necessary. The more responsibility you have, the more you document. The people that want to change your code might use the documentation. Another team that wants to create a feature that uses your API will also need to look to the documentation.
You can start at least by adding a documentation of a project if you’re creating it. If you’re making a complex feature, create the documentation of that method. If you’re working in a big company, then you will also need to document how other products can interact with your product. For example, if you create a product that provides REST APIs, then you need to create an API spec.
Document your design
You read about designing before this in the previous section. When you’re designing something and produce a data flow, make sure you document it. If you want to create design diagrams, the popular tools are draw.io, confluence, and my new favorite, PUML.
Documenting your design can be your reference when you or other team member code the feature. When you or they confused with the flow, they can use the design as a reference. It will also help you later on. If you’re creating a new feature that uses the design, you will be able to easily understand the feature you made before.
Document your method
Documenting your method is especially important if you’re creating a complex function. For a simple function, most of the time you can understand the function by its name and parameter. But for a complex one which can accept many inputs and produce many outputs, create a documentation for it.
Document your APIs
If you’re creating a new API, make sure you document it. It will help the other engineers if they want to use that API. You or other engineers will also be able to create another feature that interacts with your API even if you’re not done developing your API if you created an API documentation for it. This is useful in the microservice architecture. If you’re creating a big feature, the other team can start developing the feature that interacts with your API while you’re still developing it.
How to improve
Always create a documentation if you can. Make sure the people that will read your documentation will understand what you wrote.
One thing is as important is to update the documentation. Even if you create a comprehensive documentation, it will be useless if you don’t update it when there is a change in the codes. Your documentation will be irrelevant anymore. Remember to update the documentation, even if you’re not the one that created it too.
Not working on your soft skill
Photo by Amy Hirschi on Unsplash
When you’re working as a software engineer you will always collaborate with other people. Some software engineers focus too much at increasing their technical skill and often forgot to improve their soft skill.
Doesn’t matter if you want to pursue management career or technical career, for your work to reach the other people, you will need to talk and collaborate with them. Suppose that you want to introduce a new technology to your company, you will need to present your proposed technology. A good presentation makes the audience agree with you.
Will show how capable you are
How do people know that you’re capable? The only way for people to know that you’re capable is to have a conversation with you. When you’re good at communication, you can deliver your intention and reason more easily. People agree with the people that have a good communication skill. Even if you’re very capable with your technical skill, if you can’t communicate, people won’t know about that.
How to improve
It’s okay if you’re not a talkative person, but if you think you need to talk, then you should! Giving an opinion or asking something that you don’t understand is the first step of improving your soft skills. If you’re afraid to talk in the meeting, you can start by talking to your coworkers and superior.
When you’re presenting something, create the presentation for the audience, not yourself. Think about what they might be confused with or what they are going to ask. Talk clearly and loud.
Conclusion
Those are 5 things that I noticed I lacked the most at the beginning of my software engineer career. You might have the same problem, or you might not. Every person is different in their strength and weakness, the most important thing is you realize them and try to improve yourself. I hope this article help you in realizing your own weakness. Thank you for reading until the end!
