How to be a better developer

Rodrigo wrote an interesting list of what a developer could consider in his way towards improvement.

Since he tagged me, it's my turn. So here's my point of view as someone who developed, develops, and consults/trains/audits a lot of developers.

Agility is good for your nerves

Admit it, you just hate when your client (who may be your boss) comes in with a new functional request that induces breaking changes in your code. That's because you need to break a good architecture to fulfill this request. Or write a quick and dirty patch, which you don't like.

Let's face it: your client will always have changing needs, so it's better to learn how to face them with no cry than keep complaining each day that your client is a pain.

Well, there are precisely processes that allow to progress smoothly although there are changing needs. Agile processes, and eXtreme Programming is one of them. And believe me eXtreme Programming just works fine when facing changing requirements. If you want to know more about XP, see here.

Show it

If I'd ask you to write down what would be the ideal car for you, I'm sure you'd produce a car that you wouldn't like. Instead, if you try three different cars, you will be able to tell me exactly what you liked and disliked in each one, which will allow me to build the perfect car for you. That's because you don't know what you want until you try what can be done.

Software is no different. Your client may write tons of functional requirements, but there's no such way for him to know what he wants as when you show him what you can do. So just write a small part, showcase it, and get feedback. Your client will love you. By the way, this is part of an agile development process.

Be lazy

Part of my job as a consultant is to write with 5 lines of code what some developer wrote with 100 lines. Believe me, I do this very often.

Yes, I know that sometimes in a developer's life you just try your best to achieve something you don't really know how to do, and you then forget to clean up the mess. I'm not referring to this. But be confident that when you're writing a lot of code it's because you're missing out on something. Especially when using frameworks as the .NET Framework which can already do most of what you need to do.

You don't know it all

If you didn't know the typed DataSet in Visual Studio, you'd spend a full month to develop a disconnected data layer which can be done in one day using the typed DataSet. The pain is, there are so many technologies (even if we consider only .NET) that you don't have time to write software and know them all. Well, that's what experts are for.

If you work in a company sporting a huge development team, you may already have an expert (sometimes they are labelled as "architects" or "senior developper"). If your development team has just 5 persons in it, call a freelance expert. Hey, that's my job!