Habits to develop as a software engineer
Photo by ThisisEngineering RAEng on Unsplash
In this post, we are going to talk about which habits are interesting to develop as a software engineer. Habits are important in our daily lives. Developing good habits to improve as a software engineer is something that will pay off in the long term.
Be open to receiving feedback from your code.
When your code is under code review accept the changes suggested if they are valuable. Sometimes comments might seem not valuable. But, you should thank the person that has dedicated time.
People can get defensive or think that having a lot of comments in their code is like an attack on their work. If the comments are not disrespectful it’s a way to improve your code, so use that to improve.
Learn the shortcuts of your IDE.
Master the tools that you work on daily. The best shortcuts to know is to group a bunch of lines of code and create a method or rename a method, variable, class. Creating a constant from a value is also a useful shortcut to know how you can achieve it.
Read technical books.
Reading technical books will increase your knowledge of the subject. I would choose books that are not specific to any technology. What these books explain doesn’t get outdated. Clean code book, growing object oriented software guided by tests, or the pragmatic programmer are some of my favorites.
Read code from other people.
Read code from open source repositories that many people in the community use. Reading how other people structure code can help to improve your code.
Understand the technologies that you are using in projects.
If you are using a technology read something about this technology. You will increase the knowledge of it. If you are using docker
learn more about it, don’t limit your knowledge to the commands that you use.
Think before jumping into solution mode.
You are not paid to write code. Your job is to solve problems, and for solving problems sometimes you don’t need to write code. If there’s a solution that you don’t need to write code and solves a problem to your customer go for it first. It’s good to try first the cheap solution, then if it doesn’t work you can go to the next option which could be coding.
Identify code that can be removed.
If there’s a functionality in the code that nobody calls, this is a candidate to remove from the source code. Look for usages, for that might be useful to have metrics in your application to detect pattern usages.
Don’t be afraid to remove code that is not used.
After identifying the code to remove, don’t hesitate to remove it from the repository. Your unit test and your integration tests are your safety net. They will help you to ensure that you don’t remove any needed functionality. The next level of security is to release the changes only to a small percentage of your platform. This way you ensure that if there’s an issue you reduce the impact.
Write a failing test first
First write a test for the functionality that you want to put in place. Write first the specification of what you want to achieve with that code. After that you can write the code that makes the test pass.
Write code easy to read.
Always, write code thinking that different developers during time will read your code. If the only person that can understand your code is you then it means that is not well written. Use meaningful variable names, methods, classes. Reuse code as much as you can.
Document important things in the readme file.
I’m a fan of adding in the readme file the changes developed in the repository. Also, it’s important to add the steps needed to set up your application. They will help the next developer that will develop in that repository.
Teach/Share what you learn.
Once you learn something the best way to learn it is to teach other people what you have learned. It’s the best way to learn something. Be Yoda of someone or some group of people that want to learn what you can teach them.
Conclusion
We have seen in this post some interesting habits to develop as a software engineer. Do you miss any habit that you think is interesting to develop?
Comments