Tag: Craftmanship

Craftmanship

The Number One Trait of a Great Developer

JudgementAfter reading this article that I saw on Hacker News some time ago, it really got me thinking. The gist of the post is that “Great Judgement” is the number one trait of a great developer.

There are a lot of developers who only want to do the “latest and greatest” thing. They practice what I like to refer to as RDD, which stands for Resume Driven Development. Every project is just a way to make their resume that much more enviable. It is even a little hard to fault these people at first blush because in the IT industry, if you aren’t pressing your skills forward, you are quickly becoming irrelevant. However, sometimes developers forget that they are being paid to deliver a solution for a client or employer. The client’s needs should always come first.

Are you doing work for a PHP and MySql shop? Could Ruby or Node or Cassandra help them solve their problem? Sure, but their existing code is in PHP, their on-staff developers know PHP, and finding PHP developers to hire is easier than finding a good developer who knows Node or Cassandra. You may very well be doing them a huge disservice by building them a “blazing fast web scale” solution.

That’s where Great Judgement comes in. New technologies may offer benefits, but there are always trade-offs in technology. The first is your own knowledge. If you are very familiar with C# and .Net and don’t know Ruby, but you try to put together a Ruby on Rails solution for a client that isn’t mandating Ruby, you are very likely going to cost them time and money while you deliver more slowly, let alone any mistakes you are sure to make or hard-to-maintain patterns you might leave behind because of your inexperience.

The second trade-off is the number of available developers to maintain and build upon your code. The system may really hum when you write it in Brainf*ck, but you just pretty much made sure that there are maybe 30 people in the world who could help that company maintain or grow it. Larger companies aren’t as susceptible to this as smaller companies because they usually have rigid standards in place, but the “market” for your code – be it the language, the framework, or even your patterns – should be at the forefront of your mind as you plan.

The third trade-off is not to over-engineer. Some developers want to create a highly robust and scalable system with a caching layer, failover clusters, and load balancing for every one of their solutions. They want a pluggable architecture and a side of fries with that. The problem is that they are making a small inventory application for the secretary to maintain her office supply levels for a staff of 9. Sad to say, but a simple Access database that would take an hour of your time to create may be all that they need.

I haven’t thought enough to actually assign Great Judgement as the number ONE trait of a great developer, but I definitely have to agree with the author, Tammer Saleh, on many of his points. If Great Judgement isn’t number one, it is certainly in the team picture. If you use Great Judgement, you are a long way to delivering valuable solutions to your clients and that may improve your resume way more than buzzwords.

Craftmanship

Programming Language “Skills”

I just read a post over at The Hundred Minute Hack called Do Programming Language Skills Exist?. The basic premise is that you don’t have Java Skills or Python Skills or Ruby Skills, you have object oriented skills, functional skills, etc. These languages are just tools.

If we keep the “Software Developer As Craftsman” metaphor, a carpenter might have 10 years of general carpentry skills, or 20 years at furniture making. What a carpenter would never really need to put on a resume is:

  • Hammer – 20 years experience
  • Manual Saw – 20 years experience
  • Table Saw – 18 years experience
  • Router – 14 years experience
  • Clamp – 20 years experience
  • Sandpaper – 20 years experience
  • Belt Sander – 19 years experience

For an experienced carpenter, it very rarely matters what his toolset is, it matters what skills he possesses. The tool often just offers an easier or faster way to do something he already knows how to do.

With so many things changing so quickly in software development, it really is the skills that matter. It is possible to have almost 30 years of object oriented programming skills. You can have 15 years of skills with the web. You can’t have 5 years of experience with .Net 4 or 10 years of experience with Rails.

As “new and better” things are constantly released, it really is the skill that is transcendant, while the tools come and go. The proven ability to learn the tool is even a skill, but the act of knowing the tool alone is not. I am great with a hammer, but I couldn’t build you anything from scratch. In that same way, someone who only knows the C# language isn’t necessarily going to be any good in some enterprise shop or someone who only knows Ruby isn’t necessarily going to be the person you want to have as the only employee at your start up.

I think that I’ve almost always agreed with Phil, but I never really had the idea codified in my head so succinctly. I’m not saying the tools are worthless (obviously, a carpenter becomes very familiar with his tools – as should we), but I do think that we as programmers are almost worthless if we don’t hone the things that are transcendent skills.