Who/what, according to you, is a programmer’s best friend? Some say coffee, others say keyboard shortcuts but I think it is Stack Overflow.
It's always there to help, through thick and thin. Doesn’t matter if the problems are small or big; it is always there.
But sometimes the answers you seek aren’t there and you have to just grind it out until it works. I guarantee that you have been in that place many times. Sometimes that grind can be hours, and all the motivation flies out the window.
There are a few things that I have learned working on several projects. Apart from the new technology/language/framework is the need for documentation and the ability to see the holistic view of the system.
This may sound very simple and obvious, but not very common among developers. I have seen several times that the problems that pop up during development are quite similar. And even if you have solved them in the past, you tend to Google and find the exact same solution.
This approach works every time but there is a lot of searching and scrolling, as not all solutions are simple. You have to scroll through various posts and various answers on Stack Overflow just to reach the one that solves your problem. It can be frustrating at times.
These three habits will help you reduce the turnaround time for a problem and will enhance your understanding overall.
A lot of times during development, we stumble upon a lot of issues with the libraries and frameworks that we use. It is more apparent while using new technologies like Spring Boot with Kotlin instead of Java.
We generally have all the context and understanding of the problem at hand when we are developing the feature. And naturally, that becomes the best time to document the problem.
Recently I was working with Hibernate with Kotlin and I bumped into a problem where it was not possible to use data classes to create entities. I struggled for sometime before actually finding a nice article that explains the problem and the possible solution. I saved that link.
And instead of jumping quickly to the solution and implementing it to my problem, I started digging deeper. I observed that there are a lot of libraries that have similar problems because of the compatibility issues with Kotlin. Next time when I see something like that I can quickly go through that article to refresh my memory and be done with the solution.
Don’t try to quickly finish the task that you have on your plate, instead try to learn and document as much as you can!
This one is very important for all the developers out there. No matter what level you are. You should be good at looking at the bigger picture of any software system. When you start creating the architecture diagrams, you start realizing how much you do not know about the system. This gives you an opportunity to dig deeper and understand the system well.
I generally try to understand the complete picture of a software system. I start by looking at the backend server, understanding how the infrastructure is configured, and third-party dependencies. Getting a quick view of the complete system helps me understand what are the moving components in the system, regardless of whether I would be working on that directly.
The next thing I do is to draw a rough diagram of my understanding. I miss a lot of important information during the first version but I get better by iterating and asking questions to relevant people. A diagram much like a picture is worth a thousand words. Refer to this link to understand various types of architecture diagrams.
Very simple and very effective. Maintain a daily log of the work that you do. Try to highlight the most important things that you do on a particular day. It will not take more than 5 minutes.
Writing about the problem you stumbled on a particular day would be the first thing to document. Try to be detailed and mention relevant information. Also, make sure to note the things that are pending on you or the things that you need from other team members. It could be either new designs from the design team or scope of a particular feature from the product owners.
This will help you make sure that you are not forgetting anything. You will be proactive in approaching people and able to finish things quickly. This is one of the things which can differentiate you from the rest of the crowd.
A developer’s day can be very busy sometimes, with all the meetings and delivery pressure. And when you forget something to implement or change, no matter how tiny it is, it can lead to huge problems.
These are a few things that have worked well for me. It made a lot of difference while I was doing my daily work. It had positive impacts on my visibility in the team and made me a reliable developer. I hope this helps you become a better version of yourself.
“I’m not a great programmer; I’m just a good programmer with great habits.” ― Kent Beck
I hope you found this article useful! Please follow me on Twitter and leave a comment bellow if you have your own useful tips.
Previously published at https://levelup.gitconnected.com/3-habits-that-will-help-you-become-a-top-developer-7f310fa2c3b0