1. Long Method
Short methods specific to single units are bad. Try to limit the number of methods in each class. This will ensure that each method is as long as possible.
Workaround: In order to prevent long method from happening, I recommend limiting the length of your functions to 30 lines or less (40 including exceptions). Focus on keeping your functions less then one screen’s length. Try bumping up the font-size of your IDE so that a lot less code fits on the screen.
2. Out of Sync Comments
Just like you learned in college, comments are the best form of documentation. Comment blocks are better. Provide details about every line of code and include pre-conditions, post-conditions, and expected exceptions. Comments are important because they help other developers calling the code understand how it works.
/// <summary>
/// Saves data into database
/// </summary>
/// <remarks>
/// Save Data opens up a SqlCommand object and calls the
/// sp_SaveUsers stored procedure to save a user object.
/// </remarks>
/// <preconditions>
/// User object must be created. sp_SaveUsers must exist in SQL server
/// </preconditions>
public void SaveData()
{
//Get Connection String
string connectionString;
SqlConnection connection = new SqlConnection(connectionString);
//Open Connection
connection.Open();
//Create Sql Command call “sp_SaveUsers”
SqlCommand cmd = new SqlCommand();
cmd.Connection = connection;
cmd.CommandText = “INSERT INTO USERS (userId, userName) VALUES (?,?)”;
cmd.CommandType = System.Data.CommandType.TableDirect;
//Add Parameters for Stored Proc
cmd.Parameters.Add(u.ID);
cmd.Parameters.Add(u.Name);
//Execute Command
cmd.ExecuteNonQuery();
//Close connection
connection.Close();
}
Workaround: If you are going to write comments, specify the problem that your code solves, not how it solves it. Think of the last time you picked up a book at the store and read the back. Would you have wanted it to tell you what the story is about, or how the plot is laid out? If you change the implementation (bug, refactor, etc.), the comments can remain the same. Try and get away from code commenting all together by writing self-documenting code. For examples read Jeff Atwood’s Coding Without Comments.
3. Bloated Class
Enforce a limit to the number of classes allowed in the codebase. To reinforce this, place all logic into one big blob class. With this class you are the ultimate tool that can do anything. The more classes you have, the more source files you maintain. More source files increase the compile time of your project.

Workaround: Follow the Single Responsibility Principle (SRP) to keep the implementation of your class specific to its’ purpose. Classes should only have one reason to change, and no other components of that class should be affected during that change.
4. Classes that are “involved”
The more that each class knows and relies on another class, the better your code is as a single unit. New developers will need to understand every class in your solution because one change creates a ripple effect throughout the system. Dependency hell is much nicer than it sounds.

Workaround: Develop code that is loosely coupled. Loosely coupled code is attained by making each class units that do not have knowledge of how other classes work. This creates more flexible design. Do not overkill as too much can lead to unneeded code complexity.
5. Developer Ego
The smarter a developer and the better coder that they believe they are, the better the code output. The only one capable of creating awesome code is one who looks at the world as one complex problem. Try to avoid breaking it down into simple smaller problems, otherwise any regular programmer is capable of doing your job.
Workaround: Give the developer the smack-down.
* DISCLAIMER * Please note that my views are that of the Workaround type method and this article is meant to prove humor at what can go wrong when unsafe practices are used. Also keep in mind, I’ve probably done each and one of these plenty of times in my career.