Have listed down few Lessons learned on the field which I found useful over a period of time.
1: Always execute every line of your code
After developing a feature one needs to obviously test it. Make sure every line of your code has been executed at least once. Many times see bugs on a certain line of code which had never been run by the developer. Kind of a condition within your code where the control never reaches during the normal flow. The code might look decent enough while reviewing, but unless you had made sure control comes to that part of your code and test it nothing is guaranteed to work.
Sounds obvious, doesn't it? Think how many times you would have faced this scenario by having used some test data which never takes you to an "else" part of the code (or) "case" of a switch statement etc.,
2: Logging, Error Handling to be part of the code from the very beginning.
While developing a new feature/module/project add logging and error handling from the beginning of the development as both of them would be really useful & help you be more productive. You always need a way to know what is happening in the program like how much time important parts of the code are taking, exceptions being thrown etc.,
Sooner you know about the issues in your code easier it is to get them fixed.
3: Always change only one thing at a time
Always make sure to do short iterations, confirm that it works, move on to the next one & repeat the same process. It is easier to identify the root cause of the failure if you had made just one feature change at a time.
I used to follow the same principle while committing changes to source control as well. So that if I need to revert back any specific feature it becomes easier.
You might think to make multiple fixes (or) adding multiple small features quickly and then add the code to source control thinking you have control over things. But that is just a good case scenario. What if something messes up in the code (or) some features were pulled out of the release at the last minute?
4: When in doubt use paper or whiteboard
Whenever I get stuck while writing a program I just stop, move away from my laptop, pick a piece of paper or a whiteboard marker and start writing the program there. Many times I had found it to be useful to recollect my thoughts, don't worry about the syntax, just think about the actual problem & solve it quickly.
5: Load test your code
Do not claim the code to be complete by just checking your code with few hundred sample data in the database. Try to simulate the load of the actual scenario of your production environment.
With just 10 or 100 records most code would run faster without many issues but maybe the table you hit in your production database might have few million records and it might take forever to return you the data. Maybe in your production environment, there might always hundreds of users using it at the same time but you had tested with just one user connection.
6: Unit Testing should be made compulsory
All code change should be accompanied by a unit test. Though it will make developing any change slightly slower it's worth it because it makes the code base scalable. Also, need to make sure automated unit testing is in place at the earliest.
7: Talk to your team frequently
If you tend to talk only to your peers, upper management over and over again there is a high possibility of you missing out on important feedbacks, suggestions which your team might have.
8: Share credit.
It's sad we have come to a level where this had to be mentioned separately.
Many times have seen leads, managers claiming that they did all the hard work to make something work. On any failure, the same folks would put the blame squarely on the team. Your team would have made 90% of the code to work and get stuck with some 10% of the tasks. You would have helped them fix it, fair enough, but you shouldn't take credit for the whole 100%.
It's very small world and in no time your team would come to know of this. One - your team would be demotivated, Second - you lose your teams trust.
Always go out of your way to mention who all contributed to this and don't ever steal somebody's credit.
1: Always execute every line of your code
After developing a feature one needs to obviously test it. Make sure every line of your code has been executed at least once. Many times see bugs on a certain line of code which had never been run by the developer. Kind of a condition within your code where the control never reaches during the normal flow. The code might look decent enough while reviewing, but unless you had made sure control comes to that part of your code and test it nothing is guaranteed to work.
Sounds obvious, doesn't it? Think how many times you would have faced this scenario by having used some test data which never takes you to an "else" part of the code (or) "case" of a switch statement etc.,
2: Logging, Error Handling to be part of the code from the very beginning.
While developing a new feature/module/project add logging and error handling from the beginning of the development as both of them would be really useful & help you be more productive. You always need a way to know what is happening in the program like how much time important parts of the code are taking, exceptions being thrown etc.,
Sooner you know about the issues in your code easier it is to get them fixed.
3: Always change only one thing at a time
Always make sure to do short iterations, confirm that it works, move on to the next one & repeat the same process. It is easier to identify the root cause of the failure if you had made just one feature change at a time.
I used to follow the same principle while committing changes to source control as well. So that if I need to revert back any specific feature it becomes easier.
You might think to make multiple fixes (or) adding multiple small features quickly and then add the code to source control thinking you have control over things. But that is just a good case scenario. What if something messes up in the code (or) some features were pulled out of the release at the last minute?
4: When in doubt use paper or whiteboard
Whenever I get stuck while writing a program I just stop, move away from my laptop, pick a piece of paper or a whiteboard marker and start writing the program there. Many times I had found it to be useful to recollect my thoughts, don't worry about the syntax, just think about the actual problem & solve it quickly.
5: Load test your code
Do not claim the code to be complete by just checking your code with few hundred sample data in the database. Try to simulate the load of the actual scenario of your production environment.
With just 10 or 100 records most code would run faster without many issues but maybe the table you hit in your production database might have few million records and it might take forever to return you the data. Maybe in your production environment, there might always hundreds of users using it at the same time but you had tested with just one user connection.
6: Unit Testing should be made compulsory
All code change should be accompanied by a unit test. Though it will make developing any change slightly slower it's worth it because it makes the code base scalable. Also, need to make sure automated unit testing is in place at the earliest.
I find that writing unit tests actually increase my programming speed - Martin Flower
7: Talk to your team frequently
If you tend to talk only to your peers, upper management over and over again there is a high possibility of you missing out on important feedbacks, suggestions which your team might have.
8: Share credit.
It's sad we have come to a level where this had to be mentioned separately.
Many times have seen leads, managers claiming that they did all the hard work to make something work. On any failure, the same folks would put the blame squarely on the team. Your team would have made 90% of the code to work and get stuck with some 10% of the tasks. You would have helped them fix it, fair enough, but you shouldn't take credit for the whole 100%.
It's very small world and in no time your team would come to know of this. One - your team would be demotivated, Second - you lose your teams trust.
Always go out of your way to mention who all contributed to this and don't ever steal somebody's credit.
"If anything goes bad, I did it. If anything goes semi-good, we did it. If anything goes really good, they did it." - Bear BryantIn life, one has to be learning all the time. How important it is to never stop growing. That being said, would love to hear your feedback on this post.
Comments