How to become a better software developer?
6 min readDec 26, 2021
I always say there are no shortcuts to success. You have to work hard and be consistent in your effort. And the results will start to show up. But there are certain hacks towards becoming a better programmer/software developer. And, interestingly, all of them were always clear to you but either ignored or procrastinated.
- Read the requirements well
One of the easiest ways to become a good programmer is to read the requirements well. When you read the requirement, do not immediately jump onto the solution. Instead, take some time to read the requirements, come up with questions, think of the edge cases, to the extent even question whether the requirement is right or not. In doing this, you have clearly identified what to test when your development is ready. And, therefore, your solution can be more complete and your manager/client will be happy to see that you have covered everything. You have now become reliable. - Consider, compare, and evaluate multiple solutions
More often than not, we read requirements and draft/code solutions in a way that matches something that we have done in the past. You must consider more solutions for your requirements than one. And you need to compare them on different aspects like security, performance, and scalability before taking the final call. Your ability to think and compare more solutions gives you the confidence to solve complex problems. - Write unit test cases
Most developers hate it, but all of them need it. When you write the unit test cases, you plan for the solution, you think of all the atomic level needs, you ask more questions, and you cover more edge cases. And when you are done with your implementation, you check the code with all your unit tests, and then you are happy with your implementation. A developer should not only write unit test cases but also learn from them. When the QA reports issues, the developer should also understand what kind of unit tests should have been part of their plan, but they missed them. It is not just about reducing the QA effort, but we need to understand that when we write these test cases, we also understand the requirement better, and we ensure that the right questions are put forward before the final solution is defined. - Learn to use Google effectively
One of the key skills as a developer, that no one talks about during any study, is the ability to effectively search for a solution to a problem or error. You are not supposed to remember every syntax, solve every problem immediately, know all the pros and cons of using different technologies. You should be able to look for the right keywords and frame the right queries. If you have mastered the art of Googling well, then I think most issues are solved. The biggest challenge in learning to use Google effectively are “seniors”. If you go to a senior, they will tell you a solution, and then you won’t look for it yourself. Before seeking help from any senior/colleague, always make sure to Google yourself and spend a good 30 mins to 1 hr before giving up and reaching out for help. - Use a good IDE along with debugging capabilities
Throughout the process of writing, creating, and testing software, developers employ a variety of tools. Text editors, code libraries, bug tracking software, compilers, and test platforms are among the most common development tools. A developer who does not use an IDE has to choose, deploy, integrate, and monitor these tools individually. Over the last few years, IDEs have evolved so much that they can prevent you from using deprecated code, ensure proper coding standards of whatever programming language or framework that you use, and debug the issues by digging as deep into the code as possible. If you are not yet using an IDE, it will make for one of the best weapons as a software developer. - Follow the best practices
The agile world is moving very fast. Customers are demanding more and more features, and that too within very difficult to sometimes impossible deadlines. Even the best developers end up using shortcuts to meet these stringent deadlines. Eventually, these shortcuts only lead to poor quality, wasted effort, and, perhaps, worst of all, bad coding habits. There are coding standards that make your code more readable (much like poetry). You shouldn’t reinvent the wheel and make your code more reusable and modular. Document, document, and document. I know it's a terrible feeling for a developer to write documentation, but I also know that whenever a developer is asked to get any KT, they first look at the documentation. I usually give a lot of stress to the nomenclature of variables and functions. And while it is very obvious, but I feel that using version control in the best possible way is a must when working in teams. - Ask a technical architect to review your code
“To err is human.” You could be the best developer, but you could still produce errors in your code. When you are aware that someone in your team will review your code, you are definitely going to give your best effort and ensure that there are no or very fewer issues. When your code is reviewed, you are going to see some very minor and sometimes major issues highlighted, which are great for your learning. And when you have fewer issues in the code, the overall time for QA and going live reduces and, thus, the quality of your delivery becomes better and more reliable. It helps in future estimations as well. The only problem with adding code review to your project flow is that it takes time. And the biggest advantage of code reviews is that eventually, it saves a lot of time and makes the entire team more quality conscious and effective. - Start contributing to the open-source (make your code public)
Open-source projects give you an opportunity to improve your coding skills and learn from others. Open source contribution can help you to a) find mistakes in your code, b) receive feedback and, therefore, inspiration from professionals in the same domain, and, c) develop good habits for structuring your code. You start writing cleaner code because you know that the entire world could be using it. You are proud of the recognition that you get from the community. A lot of us might be using open source in our regular work, but we are probably not contributing. This should change for your own good. You will have to see the glitter in your eyes when your first code gets inside a publicly used open-source software. And then you get into a habit of it. - Do pair programming with juniors and seniors
Pair programming is a common software practice where 2 developers work on the same code, together, on the same machine. One developer takes the role of a ‘driver’ i.e. writes the code. And the other developer is the ‘navigator’ i.e. monitors the direction of the code, reviewing and advising any changes needed. You learn a lot by working as a pair. There are a lot of benefits that can be seen when you try it. I feel that one should do pair programming with both seniors and juniors for the best output. You don’t necessarily learn from seniors only, sometimes, you learn so much more from your juniors. And I believe that your critical thinking improves when you work as a pair. - When in doubt, ask!
No questions are stupid, only answers are. We are in doubt many a time in the cycle of software development — be it with the client in understanding requirements, or in being sure about a solution, or writing a test case if it makes sense or not. But we are worried if asking will make us look stupid or not. Here is the thing, you will end up looking more stupid later if you do not ask them now. I believe that from top to bottom if everyone asks more questions, the product will be far more complete and effective than without these questions. Your unit test cases will improve, your code will improve, and overall your delivery will massively improve if you ask when you are in doubt.
Final Thoughts
I always believe that small things make big differences. All the things that I have mentioned are not necessarily big changes, but when you do them, I am very confident that you are going to become a better developer. If you want it enough, you will become one.
