Top 10 Things Every Developer Must Do

Oh wow! I am revisiting this article after six years. Things have changed quite a bit since then.
Over the 18 years of my software development career, I have seen many mistakes that developers repeat again and again. 
Here is my top 10 list and more.

1. Missing Documentation

I have seen developers who do not like to write documentation. Obviously, there are tight deadlines and deliverables but it does not take too much time to write about the functionality you are implementing. If you spend one hour for every seven hours of code you write, it will go a long way, and eventually it will save you a lot more time.
OK, let's try to understand this with an example.
In the code sample below, you can see a method called MessySample. I created two ArrayList objects and added some integer and string values to it. Once added, the code simply displays the output.

  1. private void MessySample()  
  3. {  
  4.     ArrayList obj = new ArrayList();  
  5.     obj.Add(32);  
  6.     obj.Add(21);  
  7.     obj.Add(45);  
  8.     obj.Add(11);  
  9.     obj.Add(89);  
  10.     ArrayList obj2 = new ArrayList();  
  11.     obj2.Add("Mahesh Chand");  
  12.     obj2.Add("Praveen Kumar");  
  13.     obj2.Add("Raj Kumar");  
  14.     obj2.Add("Dinesh Beniwal");  
  15.     int bs = obj2.BinarySearch("Raj Kumar");  
  16.     Console.WriteLine(bs);  
  17.     foreach (object o in obj2)  
  18.     {  
  19.         Console.WriteLine(o);  
  20.     }  
  21. }  
Technically, there is nothing wrong with this code.
The only problem is, there is no proper documentation. Unless I go through the code, I don't know what this method is doing. Also proper naming conventions and readable variables can help. If another programmer writes code and uses the same name variables, obj1 and obj2, and at some point, you try to find all variable references with the same name, you may end up going through some unwanted code. Here is the same code but documented:
  1. /// <summary>  
  2. /// This is a MessySample method that shows how we can write messy code  
  3. /// </summary>  
  4. private void MessySample()  
  5. {  
  6.     // Create an ArrayList object to store integer items  
  7.     ArrayList obj = new ArrayList();  
  8.     obj.Add(32);  
  9.     obj.Add(21);  
  10.     obj.Add(45);  
  11.     obj.Add(11);  
  12.     obj.Add(89);  
  13.     // Create an ArrayList object to store string items  
  14.     ArrayList obj2 = new ArrayList();  
  15.     obj2.Add("Mahesh Chand");  
  16.     obj2.Add("Praveen Kumar");  
  17.     obj2.Add("Raj Kumar");  
  18.     obj2.Add("Dinesh Beniwal");  
  19.     // Apply binary search  
  20.     int bs = obj2.BinarySearch("Raj Kumar");  
  21.     // Display index on the console  
  22.     Console.WriteLine(bs);  
  23.     // Send ArrayList items to the console  
  24.     foreach (object o in obj2)  
  25.     {  
  26.         Console.WriteLine(o);  
  27.     }  
  28. }  

2. Messy Code

Keep it clean. Don't be messy. Writing code is an art. Make it cleaner. Make it pretty. Format it. This part is more about focusing on naming conventions and proper representation of your methods, properties, and variables.
Here is my original code sample. As you can see from the code below, I have two ArrayList objects and the code adds some integer and string values to them. 
  1. private void MessySample()  
  2. {  
  3.     ArrayList obj = new ArrayList();  
  4.     obj.Add(32);  
  5.     obj.Add(21);  
  6.     obj.Add(45);  
  7.     obj.Add(11);  
  8.     obj.Add(89);  
  9.     ArrayList obj2 = new ArrayList();  
  10.     obj2.Add("Mahesh Chand");  
  11.     obj2.Add("Praveen Kumar");  
  12.     obj2.Add("Raj Kumar");  
  13.     obj2.Add("Dinesh Beniwal");  
  15.     int bs = obj2.BinarySearch("Raj Kumar");  
  16.     Console.WriteLine(bs);  
  18.     foreach (object o in obj2)  
  19.     {  
  20.         Console.WriteLine(o);  
  21.     }  
  22. }  
The following code is a clean code with proper comments and naming conventions. As one of the comments suggests, if you use the proper method, variable, and other object names, you will need very little or no documentation. From the code below, I can clearly see that numberList is an array of numbers and authorsArray is a an array of author names.

  1. /// <summary>  
  2. /// This method is a clean sample that shows how to write  
  3. /// clean code.  
  4. /// </summary>  
  5. private void CleanSample()  
  6. {  
  7.     // Dynamic ArrayList with no size limit  
  8.     ArrayList numberList = new ArrayList();  
  9.     // Add 5 Integer Items to ArrayList  
  10.     numberList.Add(32);  
  11.     numberList.Add(21);  
  12.     numberList.Add(45);  
  13.     numberList.Add(11);  
  14.     numberList.Add(89);  
  16.     // Create Authors Array List to store authors  
  17.     ArrayList authorsArray = new ArrayList();  
  18.     // Add Author names  
  19.     authorsArray.Add("Mahesh Chand");  
  20.     authorsArray.Add("Praveen Kumar");  
  21.     authorsArray.Add("Raj Kumar");  
  22.     authorsArray.Add("Dinesh Beniwal");  
  24.     // Display and apply binary search  
  25.     Console.WriteLine("====== Binary Search ArrayList ============");  
  26.     int bs = authorsArray.BinarySearch("Raj Kumar");  
  27.     Console.WriteLine(bs);  
  29.     // Display authors to the console  
  30.     foreach (object author in authorsArray)  
  31.     {  
  32.         Console.WriteLine(author);  
  33.     }  
  34. }  


3. Copy, But With Love

Code sharing, code reusability, and open source are very common practices today. Thank Google, C# Corner, MSDN, CodeProject, StackOverflow and other online websites for providing tons of free code. It would be foolish for us not to use the same code that is already written and available.

So copy, but copy with love. The first thing you need to do is understand the code and verify it. There is so much code out there. Some code is written by experts. Some code is written by amateurs. You must test your code. Once tested, you may also want to check with the terms and conditions and licensing of the code. Sometimes, you may not realize it, but a person who has shared code may want you to use his copyright terms. 

4. Think Outside of the Box

If you are involved in a project that was already developed by some other developers, do not just follow what other developers have written. Before you follow the same steps, think if the way the prior code was implemented is the right way to do it. I may have shared some code on C# Corner but that does not mean I have written the most efficient code. You may come up with better ideas.
For example, on many websites, you may find code that is written using C# 2.0. The same code is applicable today as well, but in C# 5.0, you may write the same code in an optimal way.

5. Testing! Testing! Testing!

This is one of the areas where I find most developers who are rushing to deliver their code are not testing it thoroughly. Not only must you functional test your code, but also stress test it. This I have seen over and over: When a new functionality is added to a project, there may be chances that the code may have affected other areas. You as a developer need to test that all areas are tested well before it is given to your Integration Manager or deployed on the Test Server.   

Read here: Why Every Developer Should be a Good Tester

6. Debug! Don't Guess

Don't trust yourself unless you're an experienced programmer. Don't guess what your code would do unless you have already used that code before. Always debug the code before even running it. When I write a piece of code for the first time, I go line by line, add my debug variables and use debugger to step through line-by-line and variable-by-variable to see if the values of these variables are passing my tests. You can avoid this if you use #7.

7. Write Test Cases

Visual Studio 2010 and later versions come with a very powerful tool to write test cases for your project. Use it. You can also use third-party open source products such as Nunit. 

8. One Thing at a Time

I have seen some programmers write code for one week straight and then do the testing. Write code based on a smaller unit of functionality and test it before you move to the next functionality.

9. Think Modular

I remember the days when a code file would have thousands of lines and just keep going and going. If possible, try to break down your code into chunks based on the function, and create a method or a class as applicable. Use proper Object Oriented Programming best practices. Use proper design patterns. Make a good use of libraries, classes, functions, and other modern programming language features that are available to you. 

10. Do Not Trust Your Testing Team

Do not rely on your testing team and think that they will find all the bugs. You are the one who knows code and functionality more than anybody else. You test it and then hand it over to the testing team.

11.    Why don't you add one ;).

What is your list? Please share!

12. Good Team Player

Building software is teamwork. One person can build small software, but when you work on large projects, it is a team effort. A developer must be a good team player. It does not matter how smart or expert you are, if you are not helping your team and not sharing with others, the project will suffer.
13. Ask Questions. Ask Again and Again

Some developers (I was the same in my early career) think asking questions of a client or manager will make them look foolish or stupid. This is not true at all. I would rather explain the same thing four times than get something that is not right. So make sure you get the requirements right before starting to write code.
14. Be Ahead. Give 110 Percent

This is from my personal experience. I was named the "crack programmer," "coder on crack," and other names for solving problems instantly. Most of the time, I got the requirements and they were done before the deadlines. So when my manager would come ask, "Is that feature done?" My answer would be, "Yes, it is live already."  

There are three ways to work:

1. Do what you were told to do.
2. Do less than what you were told to do and still be working on it.
3. Do more than what you were told to do.

Do not assume that your boss knows more than you. He/She may know more than you but it does not mean that you cannot give your ideas or suggestions. You may have better ideas. Even if they are not better, it does no harm to open up and let him/her know.

15. Got any advice? Share with us here . . . 
Ebook Download
View all
View all