I’ve had the pleasure of working with many exceptionally talented developers over the years. Yet I’ve noticed the downfall of a few of the brightest minds is a penchant for resume’ driven development (RDD). So what’s RDD? It’s characterized by selecting the technical approach that’s best for your resume’, rather than the situation.
The signs are pretty hard to ignore. A resume’ driven developer can’t seem to use the same technology, in the same way, more than twice. He thinks in terms of patterns he wants to try implementing and technologies he wants to learn. When given a simple task, he finds a way to make it challenging by over-engineering a solution that will pad his resume’ with a fresh set of acronyms.
“Hrmm, boss says this boring ASP.Net WebForms project needs a simple contact form…”
The developer with a bad case of RDD responds by creating a UI in AngulaKnockOutQuery.js that calls a new SOAP based WCF service using an MSMQ binding that ultimately persists to a Mongo/Couch/FlavorOfTheWeek NoSQL DB. Nevermind that there’s already a PostgreSQL DB where this data ultimately needs to land. He’ll slap a shell script in cron to migrate the data over to the “legacy” db, explaining “We really need to move away from that slow old RDBMS – they’re so yesterday.”
Ding! He wins! More buzzwords have been exercised for immediate application to the ‘ol resume’. Life is good with your head in the architectural clouds.
Okay, that’s an admittedly extreme scenario. More realistic real world examples involve regularly injecting new technologies and patterns into the product, often without any up front conversation with others. This leads to applications with multiple data access strategies, competing UI frameworks, and scheduled jobs that tape together incompatible technologies.
And this is exactly why I believe in code reviews – They’re the opportunity to shine light on the problem. It may mean a rogue dev now has to explain why an afternoon project took over two weeks and produced some strange Rube Goldberg machine that no one on the team understands. This is where a technical manager is worth her weight in gold. Because if you question a resume’ driven developer’s implementation, you can count on getting an ear-full about the horrible spaghetti code in the existing project that he’s saving you from by creating this new standard. Plus, he’ll wax poetic about the clear technical advantages of his new approach.
His hope is to speak quickly enough and use enough cutting edge jargon that the rest of the team is scared to admit they don’t understand. Sidebar: Developers too often associate asking a question with weakness. There’s nothing wrong with saying “I’m confused. Why’d you do that? Talk to me like I’m four.” In fact, it’s your duty. Without deliberate questioning, the resume driven developer may continue adding unnecessary complexity unchecked.
Ultimately, resume’ driven developers rarely stay in a given job for long. Despite their apparent brilliance, they just don’t deliver enough finished work to justify their bloated salary. As Joel Spolsky said, the developers you want to hire are smart and get things done. Needless to say, the “get things done” part is rather critical to long-term success.
We’re all tempted to use shiny new technologies or patterns from time to time. That’s a healthy sign of a passionate programmer. But we must honestly ask if the choice makes sense in context. It’s a developers job to manage complexity…not create it.
Discuss on Hacker News or Reddit
I’d have to answer yes and no. At work, I tend to try and only use things that I’m familiar with. But at home I try to play around with new stuff so I can see if it makes my day job better/easier/more fun whatever.
For example, this weekend I came up with a new project that I’m going to try out Angular.js with. I don’t have a business need for it, and honestly would be surprised to use it at work anytime soon. But it sounds like a fun framework, so I want to give it a shot. I could write my app as just a normal MVC site, but if it’s on my free time, I feel like I owe it to myself to see what else is new out there.
Cory, thanks for putting the spotlight on this. I take on board the points made. I do however have sympathy for the RDD guy. He’s probably looking at the job boards. He’s probably seeing what skills are being sought out and trying to build his experience around that ever changing combination of programming languages, runtimes, programming paradigms, platforms, etc.. Basically what I’m saying is that those hiring should perhaps take some of the responsibility for this.