What makes a Developer?

Thanks to Twitter, I’ve just found the interesting blog over at agilefaqs. One of Naresh’s posts, “Who is a Developer?” struck a chord with me.

Naresh wrote:

A lot of people think, if they can write some code, they qualify as a software developer.

I too have met a lot of people who think the ability to write a simple Excel macro or to craft a couple of SQL statements makes them a developer.

They’re dead wrong.

Being a developer involves a whole lot more than just writing a couple of lines of code - just as being a professional racing driver (like Scott Dixon) involves more than pushing a Matchbox car around the living room floor.

So what’s involved with being a developer, a real developer?

Here’s a list of some of what’s necessary to consider if you want to be a real developer …

• Readability - code layout, naming conventions, good comments

• Maintainability - ease of change, the DRY principle

• Error Modes - when it goes wrong, how easy is dignosis

• Monitoring - what’s “normal”, and how do we know it if we see it

• Versioning - what happens when data formats need to change

• Performance - what’s going to happen to performance over time, as datasets grow

• Structure - how does someone find the right bit of code

• Platform conventions - are you doing things the “common way”? If not, do you have a good reason?

• Testability - how can someone easily verify the code (still) works?

• Good Practices - are you avoiding known pitfalls?

• Supportability - will it be supported by the professionals hired to do so, or will it require your personal intervention every time?

• Documentation - is there any at all?

There’s twelve things straight off the top of my head - what else would you add?