1. Missing Documentation
I have seen developers do not like to write documentation. Obviously, there are tight deadlines and frequent deliverable but it does not take too much time to write about the functionality you are implementing. If you spend 1 hour for every 7 hours of code you write, it will go a long way and eventually will save you a lot more time.
Nothing wrong with this code. Right? WRONG!
2. Messy Code
Keep it clean brother. 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.
So here is my original sample code. As you can see from this method called MessySample, I create two ArrayList objects and add some integer and string values to them and display the contents on the console.
With additional comments and giving proper names of variables, my new code looks like this. As you can see from this code, even reading my variable names such as authorsArray makes sense and tells me, it's an array of authors.
3. Copy but with Love
You can't avoid copying code from sites like C# Corner or MSDN but you certainly can verify the code and get into it. Copy code but understand it. Dig it. Before you copy the code, understand it, change it, format it and then verify it before locking it down.
4. Think outside of 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 same steps, think if 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.
5. Testing! Testing! Testing
This is one of the areas where I find most of developers rushing to deliver their code but do not through test it. This I have seen over and over when a new functionality is added to a project, there may be chances that code may have affected other areas. You as a developer need to test all areas are tested well before it is given to your Integration Manager or deployed on the Test server.
I have seen developers do not like to write documentation. Obviously, there are tight deadlines and frequent deliverable but it does not take too much time to write about the functionality you are implementing. If you spend 1 hour for every 7 hours of code you write, it will go a long way and eventually will save you a lot more time.
OK, let's try to understand this with an example.
So here is some sample code. As you can see from this method called MessySample, I create two ArrayList objects and add some integer and string values to them and display the contents on the console.
So here is some sample code. As you can see from this method called MessySample, I create two ArrayList objects and add some integer and string values to them and display the contents on the console.
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);
}
}
Nothing wrong with this code. Right? WRONG!
Problem
with this code is, if I end up using these ArrayList objects somewhere
else or some other programmers read this code, they have no clue what
obj and obj2 are, unless the go through the code line by line. I also do
not know what this method really does and where can it be used.
OK
let's spend 2 minutes on this above sample code and apply some comments
as shown in the sample code below. As you can see from this sample
code, now if anybody reads this code, they will exactly know what this
code will do. Only thing you did is, just added some comments to the
code.
/// <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 brother. 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.
So here is my original sample code. As you can see from this method called MessySample, I create two ArrayList objects and add some integer and string values to them and display the contents on the console.
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);
}
}
With additional comments and giving proper names of variables, my new code looks like this. As you can see from this code, even reading my variable names such as authorsArray makes sense and tells me, it's an array of authors.
/// <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
You can't avoid copying code from sites like C# Corner or MSDN but you certainly can verify the code and get into it. Copy code but understand it. Dig it. Before you copy the code, understand it, change it, format it and then verify it before locking it down.
4. Think outside of 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 same steps, think if 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.
5. Testing! Testing! Testing
This is one of the areas where I find most of developers rushing to deliver their code but do not through test it. This I have seen over and over when a new functionality is added to a project, there may be chances that code may have affected other areas. You as a developer need to test all areas are tested well before it is given to your Integration Manager or deployed on the Test server.
6. Debug! Don't Guess
Don't trust yourself. 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 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 values of these variables are passing my tests. You can avoid this if you use #7.
7. Write Test Cases
Visual Studio 2010 comes 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 will 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
You can keep writing 1000s of lines of code in a single file but think modular. Think how you can break down your 1000s lines of code in few reusable classes and methods.
10. Do Not Trust Your Testing Team
Do not rely on your testing team and thinking like they will find all the bugs. You are the one who knows code and functionality more than anybody else. You test it and than hand over to the testing team.
12. Good Team Player
You must be a good team player. It does not matter how smart or expert you are, if you are not helping your team, not sharing with others, you will not be liked by the CIO or CTO. Personally, I would rather have less smart developer who is a good team player than otherwise.
13. Ask Questions. Ask again and again
Some developers (I was same in my early career) think asking questions to a client or manager will make them look bad or less experience. This is not true at all. I would rather explain same thing 4 times than get something that is not right. So keep bugging your requirement guy unless requirements are not clear.
14. Be Ahead. Give 110%
This is from my personal experienced. I was balled the "crack programmer", "coder on crack" and other names for solving problems instantly. Most of the times, I got requirements, 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 what you were told to do and still 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, it does not harm to open up and let him/her know.
15. Me, Myself, and I and whatever else
This is from my personal experience and it had happened twice. I was working on these projects where I was doing pretty much everything and knew all the ins and outs of the products and I though, Jeez, I don't think this project or even the company would survive without me. So I started talking to management and start negotiating. There is no harm in negotiating but it should be the right moment and right way. So I left that project but project still went on. Company still went on. I learned my lesson.
Don't trust yourself. 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 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 values of these variables are passing my tests. You can avoid this if you use #7.
7. Write Test Cases
Visual Studio 2010 comes 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 will 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
You can keep writing 1000s of lines of code in a single file but think modular. Think how you can break down your 1000s lines of code in few reusable classes and methods.
10. Do Not Trust Your Testing Team
Do not rely on your testing team and thinking like they will find all the bugs. You are the one who knows code and functionality more than anybody else. You test it and than hand over to the testing team.
12. Good Team Player
You must be a good team player. It does not matter how smart or expert you are, if you are not helping your team, not sharing with others, you will not be liked by the CIO or CTO. Personally, I would rather have less smart developer who is a good team player than otherwise.
13. Ask Questions. Ask again and again
Some developers (I was same in my early career) think asking questions to a client or manager will make them look bad or less experience. This is not true at all. I would rather explain same thing 4 times than get something that is not right. So keep bugging your requirement guy unless requirements are not clear.
14. Be Ahead. Give 110%
This is from my personal experienced. I was balled the "crack programmer", "coder on crack" and other names for solving problems instantly. Most of the times, I got requirements, 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 what you were told to do and still 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, it does not harm to open up and let him/her know.
15. Me, Myself, and I and whatever else
This is from my personal experience and it had happened twice. I was working on these projects where I was doing pretty much everything and knew all the ins and outs of the products and I though, Jeez, I don't think this project or even the company would survive without me. So I started talking to management and start negotiating. There is no harm in negotiating but it should be the right moment and right way. So I left that project but project still went on. Company still went on. I learned my lesson.
No comments:
Post a Comment