In this Blog Post, I share some of the things I have learned so far while working as a Software Developer.
Documenting can be classified into four types:
The tasks you need to complete: Teams use product management tools to track tasks, but maintaining a personal TODO list is extremely helpful. On a regular basis, the list can be created. In retrospect, you can mark off the tasks that you were able to complete. I usually like to maintain a daily TODO list.
Maintaining your blog: Recently, I also began this & it has helped me organize my thoughts and easily document the things I have learned. It helps you think about your problems and communicate them more effectively when you write.
The work you have done: Consider keeping a journal of your work so that you can reflect on your performance. As a result, you'll have a clearer idea of what you've learned.
Things that pop up randomly: While working, you may get some questions or find something interesting related to your work, or the approach to solving a problem may be complicated. Be sure to document it. The complicated approach becomes easier to convey when you write it for yourself.
If something doesn't work, leave it for sometime
In development, we often end up coding all the time while trying to solve a problem/bug. The brain reaches a saturation point at which it is no longer productive.
When I would get some issues in the past, I had a policy of not sleeping or taking a break until the bug was resolved. It only took me some time to realize that having some breaks reduced the time it needed to fix the bug.
Now when I get stuck on code, I take a break for 10/15 minutes, and when I returned, the code ran fine with minor adjustments.
Sleeping over an issue has also been beneficial. As soon as I awoke after sleeping, the solution that I had been unable to find after hours of research came to me in minutes. Sometimes the solution felt like a Deja Vu dream.
Not always about coding
Being a Software Developer doesn't mean you need to code daily.
It is sometimes necessary to spend hours reading the code to figure out the root cause of the bug, gain a better understanding of the issue, or find different approaches to the problem.
There have been some bugs where the actual code change was only 1-2 lines, but it took me hours to research and go through the code.
You don't have to be an expert at everything all the time. You will become proficient at it only if you practice it repeatedly.
The first time you do something similar, you will probably make mistakes. However, the next time you do it, you will already know what to do and what not to do. Your brain will follow along automatically.
You Never Stop Learning
Technology is a vast field that is advancing every day. The work you do on a daily basis will teach you things, but it usually happens in a chaotic way.
A book, course, or blog can be very helpful for learning stuff in a structured manner.
Furthermore, you can gain knowledge from other developers with different experiences & journeys. Learning is a continuous process.
Every piece of code should be run once
Whenever I make a change to code, I test it after someone reviews it and asks for a change, and before merging it to master after getting the approval.
You never know what might fail if you don't test every change. You're better off delaying a feature than pushing one that has flaws.
Whenever you write code, you should test it before you put it into production.
The process of breaking down into smaller pieces
Take each part of a problem and divide it into small achievable goals, whenever you encounter them.
My usual approach is to think about the dependencies involved in solving the problem. Then search for solutions to each of the dependencies. Your brain automatically gets motivated to tackle the larger problems as soon as you begin solving the smaller ones.
By creating a flowchart or list of smaller tasks to be completed, you have the requirements clearly in front of you. All you need to do now is think of the solution.
These are some of the things I have learned so far as a Software Developer. I hope you find these tips useful in your journey as a software developer at whatever level you find yourself.
Did you find this article valuable?
Support Shloka Shah by becoming a sponsor. Any amount is appreciated!