Great Hackers Make the Worst Developers

Great Hackers Make the Worst Developers

ood programmers are what make a software company. Not just good programmers, mind you, they have to be great hackers, rock stars, the best. Great hackers are three times, five times, maybe even 10 times more productive than the merely average.

At least that’s the common wisdom. Joel Spolsky founded a software company based on hiring the best programmers; Martin Fowler regularly blogs about hiring “the very top fraction of software developers” for his company ThoughtWorks; and Paul Graham?a blogger, painter, entrepreneur, and LISP hacker? loves to write about what makes “great hackers.”

The thesis that good programmers pay for themselves is true?but it hinges on the definition of a “good programmer.” Too often, we think of good programmers strictly in terms of their technical skills?how well they know object modeling, design patterns, and a particular development platform. But being a great hacker (paradoxically) takes more than just programming skills. Being smart and technically savvy adds no value to an organization without a little business sense and a lot of industry knowledge.

A Cautionary Tale
Recently I consulted for a company that prides itself on employing the best programmers. I’ll call this place WidgetSoft. WidgetSoft hosts the premiere Web-based application for its vertical market. You’ve heard of its customers. Without even knowing it, you’ve probably used this software; your name is in the WidgetSoft database.

If you’re a programmer, WidgetSoft is where you want to work. The office fairly brims with really smart people doing really smart things?and having a fun doing them. It’s a culture where technical brilliance is the primary social currency, and elegance is the core value. Management’s job, as they see it, is to hire talented people and then to get out of their way. Sounds good, right?

A year ago, WidgetSoft needed a customizable UI framework on top of its application. Because of the shortcomings of some of their legacy products, the development group was highly motivation to “do it right this time.” High-level managers (themselves former coders) couldn’t resist such an exciting opportunity. They wanted something fast and extensible, but more importantly this was a great chance to build an elegant solution.

They wanted a technically interesting and challenging problem to solve, and they got it. But they solved the wrong problem.
They met their goals: the framework is fast and extensible. It’s also localizable, configurable, and a giant albatross. Despite a great design, the product adds almost no unique net value to the organization. Here’s why: WidgetSoft is a Microsoft shop, and the release of .NET 2.0 last year included just about every feature built into the custom framework. WidgetSoft built an extensible framework using XSLT and CSS. But ASP.NET 2.0 now includes the concept of a theme, which accomplishes the same thing. WidgetSoft did a ton of work ensuring that customers can alter layout of their sites. But ASP.NET 2.0 now includes web parts, allowing users to customize sites from right within their browsers.

Great Hackers, Worthless Developers
WidgetSoft should have heeded the sage old advice of “Buy, don’t build.” To get the best return on your money, you should buy what you can and build what you can’t. It is rarely a money-making proposition to write your own compiler or Web server?unless you’re in the business of writing compilers or web servers.

The trouble is that, from a purely technical perspective, low-return code is often the most interesting to write. As Paul Graham says, “Writing a compiler is interesting because it teaches you what a compiler is.” So here’s the dilemma: Great hackers (‘great’ in the traditional sense) can be very productive at writing code that’s not worth much money to most organizations.

The great hackers at WidgetSoft wanted to build an elegant framework (which they did) with URL rewriting and XML and all kinds of other cool technologies. They wanted a technically interesting and challenging problem to solve, and they got it. But they solved the wrong problem. Not only did the development team do all this work?design, development, testing, training, consulting?all of it for nothing, but the product is actually worse than nothing because of the ongoing maintenance, and the future cost of transitioning to a more idiomatic ASP implementation. Management could have delayed the development cycle for several months to take advantage of Microsoft’s improved platform. They could have continued to patch their legacy systems for a year. But the culture of great hackers at WidgetSoft prevented them from making smart business decisions.

To be effective, developers must reframe the prevailing definition of a “technical challenge.” Figuring out how to build best UI for your clients, with your staff, on your schedule is just as technical as writing a compiler, just as much of an art and a science?and even more challenging because no one has ever done it before. To be a great developer, you need to know how to code really, really well, but you also have to know the software industry, your vertical market, your users, your organization, your competitors, and your product. The “great hacker” who writes a compiler in a week isn’t as productive as the lazy (but virtuous) developer who can expense a third-party component by 10 a.m. on Monday morning.


About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist