If you have spent some time in software development then there is a question for you…
Where do you spend most of your time?
Do you spend most of the time writing the code? (of course not)
A lot of time an experienced developer spends in thinking about the big picture or design of the software. They review the code, refactor the old code, fix the bug, read the code of other developers, or spend more time learning the new library or frameworks which are needed in their job.
In short, they write less code and spend more time thinking about good software design (here we mean ‘good’ software, not just software) and making a plan to build it.
If you have spent some time in the industry then deep down you better know that there is no perfect software, it can only be good enough depending on the deadlines. Sometimes you spend more time optimizing the things, sometimes refactoring the code or fixing the bug created by junior developers. In the end, no matter what you do, you’re always focused on building perfect software (as much as possible) within a given deadline.
There is a difference between writing the code for software and writing the code for good software. When you exhibit the quality of a developer who writes the code for good software then you might have followed best practices, engineering principles, coding standards, or some guidelines given by your senior developers.
Today in this blog we will talk about a few guidelines which are essential to learning for every junior developer (of course you want to become a great engineer, not just an engineer). These guidelines will help you to build good software and perform better in your job. Before we go ahead keep in mind one thing…
“Software never was perfect and won’t get perfect. But is that a license to create garbage? The missing ingredient is our reluctance to quantify quality.”
-Boris Beizer
1. Clever Optimization With Code Readability
As we have discussed that developers spend most of their time reading the code not writing it. Most of the time they need to debug the application, check the commits done by other developers, or reading about building a new feature they need to add to their software.
They take care of the code readability and pay attention to writing the code which is easy to understand and easy to modify even if they need to write longer variable and function names. Writing more lines of code is completely acceptable if it’s easy to understand and modify.
For example, declare a variable name ‘distanceInMeters’ instead of ‘distance’. This variable name makes more sense even if it requires a bit of extra typing. You won’t have to spend time looking around the codebase to find out the unit for the distance variable.
A lot of developers write one solution in the codebase (just to avoid adding extra lines of code or optimize the code) which sometimes becomes difficult to understand for other coders.
The above solution might be a bit difficult for other developers to understand. These one-liner solutions or these kinds of optimizations are useful when you’re the sole contributor to your project. Avoid adding it to a codebase if multiple contributors are there.
2. Code Revision
Ask a developer, and they will let you know that how revision control has saved them multiple times when something went wrong in their codebase. No matter, whether you’re a sole contributor to your small project or you’re working with multiple developers on a big project, revision control has become an essential tool to use in enterprises.
Before working on any new feature or adding some code in the codebase make sure that you take the code revision first. Who did what, what commits have been done, what has been deleted, what has been added, what has been updated, etc. In short, keep track of all the changes.
Keeping the track of various stages of development helps you to resolve the issues during the development of your application. If your application doesn’t behave as expected or the code breaks then you can go back to the stable version of the application and find out what’s causing the problem.
Revision control also allows the developers to work on a project simultaneously without disrupting the stable version which has been already released for users. Git (the most popular one), SVN, CVS Version Control, Mercurial, and a lot of version controls are available to work on your project.
3. Verify and Validate the Application
You spend several days working on an application, you keep adding the features in your application, and finally, you shipped it. How would you feel if you listen that the product doesn’t meet the specific requirement? You need to do major changes to your application because it doesn’t meet customer’s expectations. This issue is common in software development. Doing major changes in the application is also a frustrating thing for developers.
To avoid this issue verify and validate your application throughout the various stages of development and iterations. Ship your product in small releases instead of one bigger release. Do not ship the product in the end when everything is done.
Verification: Make a good practice to evaluate and verify your product at different stages of development. Check if the application meets the specified requirement or not. Check if it is aligned to the design specifications or not
Validation: Sometimes developers misunderstand the product specification and requirement. They focus on building the product and later when the product gets shipped, they hear the issues from the users that the software doesn’t meet the requirements and it’s not built as expected.
The above issue is common in software development. To avoid this issue validate your software. Validate and determine, if the product meets the user’s expectations or not? Is the product is built as per requirement or not?
Both of the above processes have a single goal…your software should be aligned with the features proposed originally. To ensure this thing experienced developers follow the V model in the software development lifecycle. V model is developed by experts that shows how verification and validation happen at different stages of software development.
V model is helpful in identifying the unnecessary requirements. Below is a quick diagram of the V model to understand both the processes in a better way.
4. Code Refactoring and TDD
Bug…the most important part of every developer’s life.
How do you fix the bug in your code (we know you hate it when testers find a lot of bugs in your code)? You might have been using different techniques, tools, and approaches to fix the bug in your code.
One of the best ways to fix the bug in your code is TDD which as introduced by Kent Beck (American Software Engineer)
Let’s take a look at the steps given below to understand the idea and process of TDD in software development.
1. When you’re going through the various stages and iterations of development, come up with the tests the could possibly break the code. Apply the tests in your code and check if the test breaks the code or not?
- If your code breaks then you need to come up with a solution that can fix the code. Write enough code to fix it.
- If your code doesn’t break then try a different test
2. Once you come up with the solution for a specific test (code that fixes the specific test), test your code.
- Your code needs to be corrected if at least one test fails.
- Move on to code refactoring if your code passes all the tests.
3. Once you’re done with the above step refactor your code. Basically in refactoring you remove the unnecessary thing from your code and you make your code more organizable. You improve the overall structure of your code without affecting the external behavior or functionality of the application.
After refactoring, repeat the same process until or unless you’re not finished with all the ‘break cases’.
5. Comments and Project Documentation
Your code should be self-explanatory with fewer comments. Add comments wherever it’s important but do not add unnecessary comments. Also, make sure that you update the comments whenever you make changes in the code (a lot of programmers neglect this thing).
Comments in your code should be about why not how. Refactor your code if in the comments you need to explain how your code works. Also understand that code alone is not always enough to explain why you chose a specific approach to solve a problem. In those cases, comments are helpful to describe it.
Coming to the project documentation part, so it’s essential to describe why and how your code is relevant for the users. Documentations are very helpful for the users and for the developers who want to contribute to your code. README file is one of the best ways to document your project. When a user interacts with your project first time, this file helps them in understanding everything about your project.
Explain what your project does, list all the dependencies, and provide detailed instruction on how to work on the project.
Final Note
We can list out many tips to perform better in your job as a software developer but being a software developer collaborate with other developers especially senior engineers. They will let you know what mistakes they did, and they will show you the right path. Don’t get hesitated to ask for help when you need it.
Being a software developer is not just about sitting for 10 hours writing a bunch of code. You will have to follow several approaches and techniques to become a good engineer (not just an engineer).
When you have a problem and you can’t solve it, walk away from your computer. You will find some of the best solutions when you’re not at the machine.
