The Business-Personal Value Continuum

While out on a jog recently, I found myself listening to an episode of .NET Rocks, in which the discussion covered the surprising percentage of developers still using Winforms and the general topic of using licensed controls written by third parties.  This started a train of thought in my head that might end in mild controversy, but I think it’s worth exploring a bit.

Two profiles (well, more like caricatures) of developer came to mind, standing in stark contrast to one another.  First is this Winforms developer that is more or less cobbling together spare parts to build applications. He uses a WYSIWYG editor, employs some kind of “database form wizard” to bind a GUI widget directly to a table, plops a slew of obscure third party controls into the code, and ships some kind of Franken-app not actually involving much code.  The second profile rounds out the dichotomy and consists of the foundational crafter.  This person builds her own tools and controls using low level language constructs and the command line, and assembles these works of art into ever-higher layers of abstraction until shipping a hand-crafted app.

If I’m running a business, give me the first person.

Undoubtedly, the crafter harbors a better, more fundamental grasp of the principles of computer science, and she undoubtedly offers the most versatility.  If she can build a compiler, use that to build a text editor, use that to build a source control system, use that to build a web server, and use that to build the sexiest, popping-ist, UX-friendliest website you’ve ever seen, she is the most employable, most full stackable programmer ever.  The business will never encounter a situation beyond her grasp.  But who cares, if the business just needs a checkbox added to a battleship gray, outdated Windows application?

I practice test driven development.  I rail against the evils of copy and paste programming.  I counsel clients on the dangers of technical debt and feature slow down.  I advocate wholesale for clean code.  And because of all these things, I understand that every single line of code you write is an incremental business liability.  So why would I take the cobbler over the crafter?  Don’t get me wrong — if I had to pick one of the two of them to write a given module, I would take the crafter.  But for approach, I would take the cobbler because the cobbler makes most of the code someone else’s problem while the crafter makes it all my problem.

What I really want is someone with the chops of a crafter and the reluctance to write more code than necessary of a cobbler.

A Proposed Continuum

When I think about these two admittedly exaggerated archetypes, I start to think of a continuum.  On one end of the continuum lies focus on business value.  I’ll get to the other end in a bit.  The cobbler (assuming he isn’t simply lazy) exemplifies primary concern with business value.  He goes out and hunts for the quickest way to deliver features for the least cost to the business.

But his relationship with the business goes beyond simple stabs at efficiency.  He makes a sacrifice of sorts.  Putting random third party controls onto a Winforms app doesn’t net you speaking gigs or jobs at Silicon Valley outfits with open office plans, hammocks, and craft beers.  The cobbler trades personal edification and market positioning for the good of the business.  He takes one for the team.  So let’s start with this continuum and the selfless cobbler.  Then, let’s slide toward the other end of this continuum.

Getting More Versatile

Let’s come back from the caricatures a bit and look instead at a relatively inexperienced developer that could assume any sort of identity as his career progresses.  This is a person that opens a heavyweight IDE to get stuff done, making use of a lot of plugins, productivity tools, editors, GUI wizards, and all of that good stuff.  It’s a lot of conceptual black magic, but it enables the relative newbie to be productive.

But then, the newbie gets more involved in the programming community and starts to learn from people that favor a less tool dependent approach.  “You really should learn more about how everything works.  Would you even know how to build the application from the command line or how to find all the files you’re using without the integrated environment?  If not, you’re not really a heavyweight programmer.  You should fix this.  It’ll be good for your employer too — I mean, what if they need to switch IDEs or they don’t want to license one anymore?”

Armed with this, the newbie goes and lays out the case to his employer, who agrees with a bit of bemusement.  “Sure, I suppose it’d be for the best if you also got good at using a text editor and the command line.  It couldn’t hurt, and, since you’re going to stay with us a long time, we’re investing in you being better.”  And yet, you’d be hard pressed to argue that this is all about the business.  Even if the newbie dutifully learned all of this in his spare time, he still has to flub around  and actually implement it at work, yielding no immediate benefit to the business.

The Latest and Greatest

Now that the newbie has spent some time mastering the new tooling and is now “bilingual” in IDE and text editor, in IDE build and command line build.  Life is good, the company is marginally insulated against changing IDEs, and the newbie is not so much a newbie any longer.  After all, he’s beginning to understand his tool set at a much richer level.

But now he’s hearing from the community that he’s falling behind.  “That tech stack that you’re using is definitely aging, and it reflects a bit poorly on you and your company.  If you can’t bring the application up to  the latest language version and use the latest frameworks, that’s a smell about your code.  And, on top of all that, you should really know a second and even a third programming language if you want to understand software development at a deep level.  You’re getting pigeon-holed where you are.”

Uh oh.  This business case gets a little harder to make, and management receives it a lot more skeptically.  Our hero tells them that it’s “a smell” not to be able to move to the latest and greatest, but is not really able to articulate what business problem this presents.  After thinking long and hard, he’s able to say, “well, it’s going to make it hard for us to attract and keep talent.”  Management perceives this as a subtle threat, rather than a business case.

But they need the developer and aren’t inclined to go out looking for people anymore than they must.  They agree to let the developer spend evenings upgrading the code to the latest and greatest as a compromise.  Our hero is now satisfied to be able to incorporate newer frameworks and even write the odd module in another language.  His cred is at an all time high.  The business is glad to keep him, and continues to hope that they’re investing in his personal growth.  Nobody outside of the devs care that they’ve adopted language vNext.

Comfort is for Cowards

Our hero is now making a name for himself in earnest.  He’s been with the company for a number of years and he knows his way around the application code, the build, and the command line quite well.  He commands several languages and is in a position of influence within the group, and rightfully so.  He’s productive.

He is also now, increasingly, a student of the craft, and he’s definitely developed some preferences and opinions.  Recently, he’s come to look upon syntax highlighting and Intellisense with disdain.  “These things rot your brain, and I really prefer not to use them.  You get too dependent on Intellisense — it’s like driving to work when you get a much better workout biking.  It’s better for you.”  He favors instead tools that are purely open source, don’t require touching the mouse, and really only if they’re contributed to by folks with a lot of cachet.

On top of that, he has developed an aversion to using anything whose construction he doesn’t entirely understand.  If the company is to adopt a library, control, or third party utility of any kind, he pushes back heavily unless he gets source code access and can vet it 6 ways from Sunday.  “Only an amateur uses a tool he doesn’t fully understand.”

He writes truly impressive code, knows what he’s doing, and has even developed himself a following of people that respect his opinions, inside and outside of the company.  He’s marketable and he knows it.  And, when he’s had enough of having to use the company approved, sell-out technologies, he quits to go somewhere that he’s free to build things from scratch, using only the very best of tools.

Understand What You Do

If you’re familiar with my blog and writing in general, this probably seems a bit out of place to you.  After all, I tend to err on the side of developer populism and not management sympathy.  But here’s the thing.  This post represents neither.  I’m not saying that you shouldn’t look after yourself; I’m saying that you should be self-aware as to your motivations.

I’m writing a book whose thesis is that the traditional corporate workplace is not well-suited for software developers.  It forces developers into a situation where the company and the individual are in an adversarial relationship.  The organization has an interest in you being a cobbler — in you continuing to add features to an application with as little risk and as little expense as possible.  Your interest is in maximizing your marketability and keeping your options open.  And nobody’s interest is in getting caught up in vanity propositions of, “I want to be the kind of developer that believes X and only uses tools Y and Z.”

The best possible situation for everyone is for you to wind up in situations where business value and personal interests align.  Usually this doesn’t happen for a very long period of time, which is why talented developers tend to be predisposed to job hopping.  Job hopping, after all, puts them in situations where they and the business are both interested in them learning new things.  But whether your interests align with those of your company or clients, it’s important to understand where both interests fall.

I offer this not so much as a hard piece of advice, but as something to stick in the back of your mind and try not to lose track of.  When you think about the techs you ‘should’ use and the techniques you ‘should’ employ, always be asking yourself whether it is you that benefits from doing so, or those paying you.