The MSDN Australia Blog

PingBack from http://abstraction.morelyrics.co.uk/2008/07/02/top-tips-for-becoming-a-great-developer-and-your-chance-to-win/

One of the most important thing required is having a passion for developing. Unless the person has a passion for technology and thinking beyond the box, he will never excel or grow up to be a good developer. Also good practice and experimenting is one essential point. And the last is "Good knowledge and understanding of the environment in which you are going to program in".

Egoless programming..

Drop your ego, re-use other people code where possible (avoiding Not Invented Here Syndrome), and don't try to "show off" by deliberately making your complicating your code.

Stop "reformatting" other peoples code because you don't like the way they indent etc.

Ego driven development is a massive productivity killer, and helps to foster bad feelings within a team environment..

If in doubt consult the MSDN Blog.

Accept the fact that you may not understand every coding fact, but if we work as a team we can overcome our individual limitations

Nothing beats a quick Live search

Ask Questions.

Don't be afraid to admit that you don't know something.

Your code will one day be maintained by someone else.  Write the kind of code a stranger would like to read.  The kind of code that says that you take pride in making your code bullet-proof. That kind of code is like putting a final polish on a perfectly crafted item - it is a pleasure for others to work with.  Sure you won't always get the chance to do this or the time, but that's the ideal to aim for.  It's being proud of your work, but letting your work do the talking.

So when are the winners going to be notified

Always wear clean undies and develop in your own time! Great software developers come about from reading and practicing what they read.

Learn how to take advantage of existing frameworks such as Microsoft SharePoint and CRM. They will often allow you to offer much more competitive solutions to your clients.

Having all the knowledge in the world, and producing the best and fastest code, is of little value unless the end product meets the customer's needs.

Therefore I believe a GREAT developer is one who not only has the skills mentioned above, but who can determine what it is that the customer really wants/needs, and is able to build a solution that matches those requirements.

I realize that it's too late for the prize but I have two suggestions:

1) TEACH: The best way to find holes in your knowlege is to try and teach someone else.

2) DON'T WRITE CODE FOR YOUR COMPILER, WRITE FOR THE MAINTAINER: Most software products spend more than half of their lifespan in maintainence. Be nice to the guys who are maintaining your code. If you gain a 2% speed increase and it takes the maintenance team 2 extra weeks to figure out your code, have you really gained anything?

Always back up your work and comment your code. It will help you and other people working on your projects. Even though everyone knows you should be doing it not everyone does.

Program horses for courses and be flexible.

1) Dont use the latest OO Software development theory if your team consists of people with structural programming experience.  You wille creat a key person dependency - you.  

2) A lot of theory is based on the premise that 90% of a software lifecycle cost is maintenance . For large core applications this is certainly true but for 80% of the smaller application out there it is likely there will be very little maintenance done and by the time it needs significant changes it will be completely rewritten based on newer technology and ideas.  

3) For small- medium apps its hard to beat 2 Tier Rad . Get the applications out there. For larger organisations a single framework/shell with modules talking to the back end is appropriate but RAD within the modules is great.

4) Avoid distributed applications - if you do need it make it the most important part of the design - design the communication between systems early eg just after you have a conceptual domain. Communication should be in chunky messages with as much information as possible and a lot of your OO design will need to be compromised.

5) For back end systems - note there significantly  longer life and higher long term maintenance costs so design your system well. TDD is great for these systems as the extra expense is returned over the life of the system.

6) Frameworks should not be enforced except for shell and security purposes.

7) Try to develop in the same way with the same tools. This is especially hard with all the goodies that come through. Test and use these in smaller projects until most people are familiar with them . This covers things like Workflow, WCF, WPF , TDD , Dependency Injection , Frameworks , Remoting /ES , LINQ , OR mappers etc.  Try to avoid these technologies in large projects until you have quite a bit of experience.

8) Dont try to design the perfect system if it passes your tests and requirements its good enough. See next point.

9) If a change is required and the code is poorly written refactor it but ONLY if a change is required or a Bug is difficult to fix .  When you need to redesign confine it to the change in question and keep it as small as possible.

10) Modularity is more important than good code /OO principals . With modules it is easy to rewrite the modules that give trouble in the field - There are many cases of cheaply written bad code running for years with no problems.  Hence for larger systems a modular framework for the client and services for the back end have a lot going for them.

11) Code should be elegant and easy to read . If your code needs lots of comments its badly written.

12) Learn from other people never assume you know it all ( even if you do pretend you dont) .

Regards,

Ben

I am a great believer in not reinventing the wheel.

Yes learning every possible coding method, construct and style may make for a very experienced programmer however I feel I gain a significant benefit from learning from other peoples code, constructs, patterns, style etc i.e coding by Lego "blocks".

Utlising MSDN examples is very useful as well as inspecting articles like that found on www.codeproject.com.

Life is far too short and too interesting to repeat effort and also to repeat mistakes.

Take easy approach to solve the problem. Share thought with peers and try to implement solution instead for giving advise to somebody.

Ben said: "If your code needs lots of comments its badly written."

Wrong.  Good code is ALWAYS documented.  While you need to be mindful in letting/getting the language to do most of the documentation work for you (that'll save you writing needless comments!), you still need to document coding that cannot be explained using the language you intend to write your code in.

"Why are you doing this?"  "What's the basis of doing that?"  "How does this help?"  There are countless things that people write that are not documented, and that often means a good potential for that code to be scrapped because it's not understood.

Writing comments is just as important a skill as writing good code.  What code is to computers, comments are to people.