Top 10 Things Every Developer Must Do

Mahesh Chand

Over the 22 years of my software development career, I have seen many mistakes that developers repeat again and again. I made these mistakes too. I learned from my mistakes.

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.

private void MessySample()
{
ArrayList obj = new ArrayList();
obj.Add(32);
obj.Add(21);
obj.Add(45);
obj.Add(11);
obj.Add(89);
ArrayList obj2 = new ArrayList();
obj2.Add("Mahesh Chand");
obj2.Add("Praveen Kumar");
obj2.Add("Raj Kumar");
obj2.Add("Dinesh Beniwal");
int bs = obj2.BinarySearch("Raj Kumar");
Console.WriteLine(bs);
foreach (object o in obj2)
{
Console.WriteLine(o);
}
}

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:

/// <summary>
/// This is a MessySample method that shows how we can write messy code
/// </summary>
private void MessySample()
{
// Create an ArrayList object to store integer items
ArrayList obj = new ArrayList();
obj.Add(32);
obj.Add(21);
obj.Add(45);
obj.Add(11);
obj.Add(89);
// Create an ArrayList object to store string items
ArrayList obj2 = new ArrayList();
obj2.Add("Mahesh Chand");
obj2.Add("Praveen Kumar");
obj2.Add("Raj Kumar");
obj2.Add("Dinesh Beniwal");
// Apply binary search
int bs = obj2.BinarySearch("Raj Kumar");
// Display index on the console
Console.WriteLine(bs);
// Send ArrayList items to the console
foreach (object o in obj2)
{
Console.WriteLine(o);
}
}

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.

private void MessySample()
{
ArrayList obj = new ArrayList();
obj.Add(32);
obj.Add(21);
obj.Add(45);
obj.Add(11);
obj.Add(89);
ArrayList obj2 = new ArrayList();
obj2.Add("Mahesh Chand");
obj2.Add("Praveen Kumar");
obj2.Add("Raj Kumar");
obj2.Add("Dinesh Beniwal");
int bs = obj2.BinarySearch("Raj Kumar");
Console.WriteLine(bs);
foreach (object o in obj2)
{
Console.WriteLine(o);
}
}

40 Comments

Join the conversation! Your thoughts help the community grow.

Sourav Kumar Das6y ago
Nice useful article sir.
Rathpanha Sarun9y ago
I just started my first career like 3 months ago. I am continue developing project from another developer that just left the job. My problem is when my boss came up with something I did not do, I don't know what to say. Do I have to understand everything that the last developer did or just wait until the problem come and look around? To understand everything what the last developer did is hard for me and take time, because I have to work with new feature. Any advices with that?
Suthish Nair10y ago
Communications, Strategic Thinking, Customer Focus etc.. must have
Amatya Agyey10y ago
I do not do documentation. I know that is important, but its not in my practice. Test Cases is also Iam not maintaining. Hope i will try to practice but it will require time and patience.
Mahesh Chand10y ago
Thank you all for comments and feedback. I am really interested in learning what mistakes you guys made or other guys made. Sharing your experience helps rest of us. Cheers!
Ajeet Mishra10y ago
nice
Vipin Tyagi10y ago
It is a good article.Every developer/Programmer must follow this.
Prakash Tripathi10y ago
Also regarding point#1, I would say that you may avoid obvious comments and keep it at places where it make sense. Keeping meaningful name of methods and variables is a good strategy to avoid comments at obvious places.
Prakash Tripathi10y ago
Good article sir. Regarding point#14, I would say that seting the right expectations is very important in long run as at times doing 110% is not feasible.
Manas Mohapatra10y ago
Very Informative blog Mahesh Sir.
Anil Kumar Murmu10y ago
Thank you for listing the most common mistakes done by developer. I do agree i fall into few of the category listed in the article. Hope to focus more on them with the appropriate approach.
- Mahesh Chand10y ago
  I am glad you learn something today.
Narasimha Reddy Chennupalli11y ago
Good Article Sir
Leslie McCutcheon11y ago
I have to disagree with point 1. (Not the concept but the example), That code does not need to be documented but have clear names & separated into components (Its doing too much). With that done it should be readable and understandable enough to get away without documentation. Bad documentation can be worse than no documentation at all, keep it simple, and only document what is not apparent :) @Jitendra Sampathirao Leaving "developer stamps" in code is what source control is for (if used correctly). Leaving comments like that in the code creates noise and if the code undergoes 4/5 change requests (not uncommon for UI components, your screen will be swamped with comments.
- Mahesh Chand10y ago
  Yes if code is clean enough, you don't need to comment all but personally I would like to know what exactly a method is doing and its purpose.
Praveen Kumar11y ago
Really! If we follow these ten things only, we could be a stable developer!
knights15y ago
Hi Sharrangas, Bugs are vital part of development without which a developer cant grow.Timming is good on one hand and its but rushing for timeline just because someone is responsible for it and missing all the points discussed in this article will never produce fruitful results, in my point of view.Thanks
Sharrangas15y ago
Thanks for sharing the excellent points. One more thing I want to add in to this, Keep up the Timing of Deliverables: The Developers should remember about the timing to complete each task … It’s their responsible also to complete the task on time without bugs :)
Bensyl Domingo15y ago
Thank you...i will not let this advice go to waste...
Mahesh Chand15y ago
The only advice I can give you Bensyl is, hard and continous work. Software field changes so rapidly. You can start with C# language. Check out Beginners link on the header of this site's home page. Then you can move to ASP.NET and so on. Good luck!
Bensyl Domingo15y ago
Im just graduate of IT, and "wow"... i really want to be like Mahesh Chand... Its feel so great of being a software developers like you.. Do you have any suggestions to me where should i start?... I mean, what program should i learn first???... vb.net? C#?, asp.net...etc...etc.... Please need your help...wish you where my mentor...thanks you.
Amit Choudhary15y ago
I like the point no. 10.... We had faced bugs migrated to production and not caught in testing.. so its all up to developer to find all bugs and fix them. A buddy approach for testing will be good.
Mahesh Chand15y ago
Yes! As Jitendra said, add comments with a date and what you have changed/updated/fix in the code. Also if new code breaks anything, you will know what code you changed. If I need to work on existing code, I comment the previous code. Add my comments starts and end with "mcb" with a date so I exactly know where is my code and what date I added it and what problem is fixed.
Jiteendra Sampathirao15y ago
One more thing is if you are involved in a project that was already developed by some other developers and you need to do some modifications in that page mention about what your code actually do's and your name and date. Every one can easily understand about particulars......
Jiteendra Sampathirao15y ago
To every developer Domain knowledge is so important. If you are new to one domain(ex: Finance, banking etc) know the Height and width of that domain from your colleagues. It will definitely helps you when you are started coding.
Ibrahim Ersoy15y ago
Being a social developer cant hurt! Join Meetings,Sessions or Talks to meet some people and enlarge your network.Drink with them and enjoy the moment.Talk about your previous development experiences.Always smile and be happy.It gives positive energy in the area and finally If you have a card,give them.It might return as consulting job :) Then after that day,add them on Social Media Sites(FB,Twitter,Linkedin)
rupali sawant15y ago
hey vry nice it is
Mahesh Chand15y ago
Thanks guys! Next in the list are - Top 10 for Architects, Top 10 for testers, Top 10 for BAs, Top 10 for Project Managers, Top 10 for CIO/CTOs :)
Sivaraman Dhamodaran15y ago
Very Nice Mahesh. I definitely work on #6 and#10. Good that My mamanger don't know about it :))
Jean Paul15y ago
It is really worth. I liked the 1"4. Be Ahead. Give 110%" especially.. because I have seen those developers doing the same are more efficient as well as they gain more knowledge and their future is bright than others. It i like a win-win deal. Also i like the statement "Writing code is an art.". Actually I wanted developers/architects to improve much on that (including me). Because when they talk they will be ambitious about oops and design patterns, but when they code that will be not as good as former.
Mahesh Chand15y ago
from all of your feedback, added few more points.
Mahesh Chand15y ago
Yes both Team work and revision controls are good suggestions. I have also noticed this in my career, some guys are really smart coders/developers but they are not good team players. As a company (CTO or CIO), I would rather have a less smart developer but better team player than otherwise. Building a software is all about Team. Also, if you are an expert in an area, sharing with other developer does not harm. It actually adds your value/reputation/respect among them. They respect you more. So don't be afraid to discuss what you know with the team.
knights15y ago
Slightly disagree with Sutish,to write better one must see better code, at times people write efficient and clean code.Surely agree not writing code and copying the it never helps discover your style. Mahesh you have brought everyone's attention to an important outline and wouldnt it be cool to rename # 1 to something like Documentation??? as this article enlists the to do's. For # 11, I suggest developers must take into consideration if at all possible to use Version control softwares.
Ibrahim Ersoy15y ago
Dont forget Team-Work.Sometimes you need to lend hand from fellow developers in the same company.If they have no more work to do,they are willing to help.But of course in the end you will need to buy a coffee or two for them :)
Suthish Nair15y ago
#1 - I sometime miss this part, dont do daily documentations but kept it for weekdays. Sure sometimes i miss some important points. I dont mind sayin this here. :).... Another point better you dont use Google/bing during development cycle. This will kill you, every time doing a copy paste. Do only if you dont find a solution.
Mahesh Chand15y ago
I agree Subhendu. But you are talking about the architecture of an application. Perhaps, we should have a blog on "Top 10 things every Software Architect should Do".
Mike Gold15y ago
If only more coders would adhere to point #1 .....
Subhendu De15y ago
Adding one point in the list. Design your code in a loosely coupled way so that you can test your code in more better way. Use run time polymorphism, Dependency Injection, Inversion Of Control, Abstract Factory pattern. The main point is to maintain "SEPARATION OF CONCERN" principle for your code so that you can unit test each functionality by mock implementation.
Mahesh Chand15y ago
Please don't call me "Sir". I feel 80 years old :)
Destin Joy15y ago
Great observation Mahesh Sir. surely need to salute your vast experience in the industry

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 an array of author names.

/// <summary>
/// This method is a clean sample that shows how to write
/// clean code.
/// </summary>
private void CleanSample()
{
// Dynamic ArrayList with no size limit
ArrayList numberList = new ArrayList();
// Add 5 Integer Items to ArrayList
numberList.Add(32);
numberList.Add(21);
numberList.Add(45);
numberList.Add(11);
numberList.Add(89);
// Create Authors Array List to store authors
ArrayList authorsArray = new ArrayList();
// Add Author names
authorsArray.Add("Mahesh Chand");
authorsArray.Add("Praveen Kumar");
authorsArray.Add("Raj Kumar");
authorsArray.Add("Dinesh Beniwal");
// Display and apply binary search
Console.WriteLine("====== Binary Search ArrayList ============");
int bs = authorsArray.BinarySearch("Raj Kumar");
Console.WriteLine(bs);
// Display authors to the console
foreach (object author in authorsArray)
{
Console.WriteLine(author);
}
}

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. 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.

12. 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.

13. 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.