It’s no secret that there are two types of coders out there. The first went out and got a CS degree because someone once told him that there’s a good future in anything having to do with computers. We’ll call him the Line Worker. The second has a passion for coding. His degree might not be in CS. He may not even have a degree (oh, the humanity!), but he loves to code. He’s an Artist. It’s not just a day job for him. Companies who don’t seek out and retain Artists are doomed.

Why?

Line Workers build widgets. Someone hands them a blueprint1 for a widget. The blueprint tells them how tall and how wide the widget should be. It tells them that the widget should rotate in a counter-clockwise direction and be made of a material strong enough to withstand 25 pounds of pressure. The Line Worker diligently creates the widget that is requested of him, applying design patterns as appropriate (if his employer is lucky). Enterprisey companies looove Line Workers, because they churn out lines of code like nobody’s business.

Artists find widget building tedious and repetitive. They push back when the blueprint they receive makes no sense, and they recognize the similarities between that blueprint and 10 others just like it in the past 2 months. Instead of building widgets, they build a widget builder, so that they never have to build another widget. As a result, they churn out less lines of code. The enterprisey company sees them as difficult, unproductive primadonnas. They fail to recognize the value proposition of a coder who wants to code himself out of a boring job.

The result? Companies that hire Line Workers assume creativity is the realm of someone in another department, someone who often doesn’t even know what might be possible via code, unless it’s shown to them. They’re building a house, and they hire an architect who doesn’t understand structural integrity and a color-blind interior designer.

So, how does a company attract and nurture Artists?

Getting Started

For starters, Artists need room for creative expression. If the only place your Artist can get creative is in his code comments, because everything else about the application has already been rigidly defined, then prepare yourself for some scathing comments. Bring him in early, while the ideas for your application are still being fleshed out. Besides showing the Artist that you value what he brings to the table, this will also benefit the project in tangible ways:

1. The Artist will give your client more bang for his project’s budget. He’ll identify when something that seems simple is anything but, and he’ll identify when something adds a lot of value for very little effort. He will educate your clients and your sales team while simultaneously showcasing your in-house talent.
2. Letting your Artist in on these early meetings will help him better understand what the project pipeline looks like. This will allow him to more effectively prioritize tasks, and identify upcoming cases for code reuse, letting him know when it will pay off to create those widget-builders he’s known for. You are hiring managers of one, aren’t you?

Ongoing Process

The term “Agile Development” has been overused and abused. Many companies are “agile” in word but not deed, and still others embrace the term as synonymous with “our developers do code sprints” but still go about defining project requirements the same old waterfall way they always have. I prefer to describe the ideal development process as “Common Sense.”

Example: If you’ve spent 40 hours (remember, when meetings are involved, attendees x duration = hours) describing functionality without at least having some wireframes and some proof-of-concept functionality, you’re doing it wrong. Don’t keep your Artist in the dark. In particular, as your designers (if the Artist isn’t also your designer) build out those wireframes, they should work closely with the Artist. He will quickly recognize the patterns they’re repeating over and over, and save them hours of effort by writing code to do it for them.

Tools

Choose a language and framework which gives your Artist the most joy. An Artist will put in extra hours working when work feels more like play.

I’ve tried my hand at at many languages over the past 26 years, and a nice helping of frameworks as well. I’ve never enjoyed development more than since I started working with Ruby and, by extension, Ruby on Rails. When possible, I approach projects using these tools because I find they bring me the most joy. Why? Because Ruby’s flexible metaprogramming capabilities allow me to make boring projects interesting. If it’s boring and repetitive to write certain code, there’s a high probability that writing code to write that code is a more interesting (and reusable) problem to solve.

Now, Ruby might not be a good fit for your typical project, or your Artists. I’m not suggesting that you use a screwdriver to drive in nails. Just find a screwdriver that makes your Artist happy, and when someone asks you to hang a picture on the wall, prefer screws to nails if given the choice.

One final note: choose a language that gives your Artist enough rope to hang himself, and trust your Artist not to end up a piñata. Make sure your tool of choice provides enough flexibility for your Artist to really express himself, and you (and your Artist) will be glad you did.

1 In our industry they’re called “functional specifications.” Why, I don’t know, because they’re about as dysfunctional a concept as I’ve ever seen.