7 Golden Rules to Impress Your Project Leader

With that said, this comes from within me. If I am a client or a project leader or a technical leader, this is what I would look for.

DOS days are gone when the definition of an expert programmer correlated with your typing speed and memory. The faster you type without looking at manuals (command syntaxes), the sharper a programmer you were considered.

Those days are long gone. Welcome to the Visual world. Welcome to the RAD (Rapid Application Development) and RIA (Rich Internet Applications) world. Welcome to the Web 2.0.

Today, you do not need to memorize commands and syntaxes. Tools such as Visual Studio 2010 Intellisense, ReSharper and SQL Prompt are here for you.

So what exactly do you need to focus on?

A computer program solves a problem. First, you need to find the most efficient and effective solution to your problems. Anybody can write code. Yes, that is true. Nowadays, anybody can write code, but the winner is the one who writes the most efficient code.

Check out my blog Top 10 Things Every Developer MUST Do

Besides writing efficient code, what else should you keep in mind?

You need to know the following:

• What tools and technologies are most efficient for your project?
• What user interfaces are best suited for your application?
• Have you commented and formatted your code?
• Have you used the latest features provided by the tools and technologies?
• Have you tested your code?

So how can you improve? Here are some of the pointers I noticed from my personal experience. I have been involved with every aspect of the software development life cycle from meeting non-technical clients, understanding their needs, writing detailed specifications, writing design documents to coding, testing, installation and development. I have also managed several projects simultaneously with in-house developers, offshore teams, and a blend of both.

Here are my 7 golden rules in my book:

Rule #1 Pay attention to the minor details.

This is the most crucial rule in my book. This is the foundation in which all other rules should abide by. If you get this wrong, everything else from here is absolutely WRONG! And there is no way to fix it.

I have seen many super smart and talented programmers write very crisp and very clean code and they've done it really fast. But sometimes they miss minor details in the requirements. These minor details can be applying formatting on a field, validating a date field for proper input or formatting a table or font on the page. If I were your Project Manager or Lead, I would not be happy with you if you fail to pay attention to these minor details,. I do not like to repeat work again and again.

Rule #2 Think outside the box.

If you have been working with an older version of a product and a newer version was recently introduced, make sure you know what new features were added to the latest version. Do not just stick with what you have been doing in the past. Always keep your ears and eyes open to new things. For example, if you have been working with C# 1.0 or 2.0 and you've only now gottena chance to work with C# 4.0, you must know what new features are there and how you can take advantage of these new features. This may not only improve your productivity, but it will also give you something new to add to your belt. Also, do not forget to look for new features added to the product. For example, if you have been working with Visual Studio 2005 and now are using Visual Studio 2010, there are many new features available in this version that will improve your efficiency and productivity.

Always remember Rule #1.

Rule#3 Rethink before you deliver.

One of my bad habits is not reviewing my work. Even after I write an article, I hate to review it. But that's OK. I can do that because I do not have a boss. But if you do have a boss, that's not good for you. You must make sure to review it before you deliver it and see how you can improve it. Sometimes, it is difficult due to tight deadlines and in that case, I would hold Project Managers and Team Leaders accountable for that. If you need extra time to review it, let your boss know. If he does not give you extra time, then you do not need to worry about it.

Did you forget Rule #1?

Rule #4 Do peer code reviews.

Four eyes may notice more things than two. You review your co-worker's code and ask your co-worker to review your code. Actually, this should be a best practice implemented by your Project Manager.

Make sure to remember Rule #1.

Rule #5 User Testing tools to test your code.

Do you just assume that your code is 100% correct? Write proper test cases and make sure they don't fail. Visual Studio comes with testing tools. You can also use free tools such as NUnit.

Rule #1 is the key.

Rule #6 Open the magic mouth.

Ask! Ask! And ask again!

Do not fear your boss. If you are unsure about any of the specifications, even if it's just an ounce of doubt, simply ask. It is better to take a little extra time in the beginning than spending a lot of your time implementing the wrong functionality. Never fear about asking questions. Always remember, no question is a stupid question.

Do not forget Rule #1.

Rule #7 Share

One thing I've noticed among naïve developers is that they always think they have found a secret solution that nobody knows about and it makes them more valuable to the company. Wrong! Yes, companies are looking for personnel who can crack the code, but above it all, they always look for leadership skills and team players. Both of these skills involve sharing your work. Share and learn. This has always been my philosophy. The more you share, the more you learn.

Again! Go back to Rule #1.

So what's in your rules book? What impresses you? What annoys you? Please do share!!