Think for a minute about what you work on. In your work life, in your side projects. What are you going to do this upcoming week that is really, really hard? This is not a rhetorical question–it’s the kind that shouldn’t raise a null reference exception. There should be something.
Because you are a good developer. You’re way above the Fizzbuzz level–you read blog posts about programming in your spare time, because you’re here. That’s top 10% right there, which is purely the admission price of reading this article. If you have gone to a couple of meetups or learned a new language this year, you’re top 1%. If you’ve put 80 hours into a side project this year, you’re top .05%.
So why are you writing CRUD apps?
I’ll tell you why. Because CRUD is the universal application . CRUD on every platform. CRUD on the web, on iOS, on desktop, in embedded, in Microsoft Access, in Oracle, on Rails, on PHP, CRUD. CRUD at startups. CRUD at enterprises. In a box, with a fox. It’s the “Java everywhere” dream Sun failed to achieve. Every time you write a CRUD app, Jonathan Schwartz gets a nickel and Knuth dies a little inside. Take a good, hard look at what you are working on and compute your Levenshtein distance from being a Sun drone.
There are two reasons why you need to put your foot down and stop doing CRUD. The first is because CS, mathematics, engineering, and every discipline need the best and brightest people doing things that actually matter, not cranking out SQL queries. We have genuinely tough battles to fight: the power wall in hardware, computational complexity in CS, user interaction is in the dark ages, self-driving cars, biotech, SOPA and related threats, dozens of others–we’re fighting a 100-front war. Your colleagues need you. Your company needs you. Your field needs you. Humanity needs you. Why are you dodging the draft? We have wars to fight, and you are sitting at home typing SELECT in all caps.
Over on the other side of the dining hall was a chemistry table. I had worked with one of the fellows, Dave McCall; furthermore he was courting our secretary at the time. I went over and said, “Do you mind if I join you?” They can’t say no, so I started eating with them for a while. And I started asking, “What are the important problems of your field?” And after a week or so, “What important problems are you working on?” And after some more time I came in one day and said, “If what you are doing is not important, and if you don’t think it is going to lead to something important, why are you at Bell Labs working on it?” I wasn’t welcomed after that; I had to find somebody else to eat with! That was in the spring.
In the fall, Dave McCall stopped me in the hall and said, “Hamming, that remark of yours got underneath my skin. I thought about it all summer, i.e. what were the important problems in my field. I haven’t changed my research,” he says, “but I think it was well worthwhile.” And I said, “Thank you Dave,” and went on. I noticed a couple of months later he was made the head of the department. I noticed the other day he was a Member of the National Academy of Engineering. I noticed he has succeeded. I have never heard the names of any of the other fellows at that table mentioned in science and scientific circles. They were unable to ask themselves, “What are the important problems in my field?”
We have difficult problems to solve and we need our A-players on the field. When you can play at the super bowl, you don’t sit on the bench.
Although it was industry-specific, I was moved by the way Gruber phrased it:
One simple way to look at it is that there are far more people who’ve never bought an iPhone and who’ve never bought an iPad, who will in the next five years than all of us who’ve already bought at least one to this point. And I don’t see how anybody can deny that, unless something unbelievable, dramatic changes. That’s certainly the way everything is going now. If you think this app store platform is big now, you really haven’t seen anything yet. At an event last week, Tim Cook had a line – he said, ‘This is an extraordinary time to be at Apple’. And He is definitely right. But I say to you, ‘This is an extraordinary time to be an Apple developer’ .This is the right time and the right place. This is a once in a career opportunity. This is like being a Rock and roll musician in the late sixties. This is like being a film maker in the seventies following Scorsese, Coppola, Steven Spielberg, George Lucas (when he was sane). If things go right, if things go the way I think they are going to go, these next five years, we are never going to work harder, we are never going to be under more pressure, we’re never going to be more stressed, we are never going to feel like we have to work faster and we are never going to have to solve tougher problems. We’re never going to have to move this fast. But the only thing any of us are going to regret is if we don’t aim big enough. If you don’t feel that you’re now in a position to do the best work of your entire career, to look back and say, ‘This was the time, I was there, I did this, I helped make this thing a reality’, then you need to find a new position. This chance will never come again. And we are lucky, we’re so unbelievably, incredibly lucky that it even came this once.
The other reason is entirely practical–anyone can do CRUD. People working for $10/hour in Outsourceizstan can do CRUD. Maybe not well–but it doesn’t need to be done well. It just needs to be done. Cheaply, if at all possible.
So every time you look at a CRUD project, you’re competing with people in Outsourceizstan who make 20% what you do. CRUD is, quite quantitatively, a job on the same level as stocking shelves at a grocery store. Unskilled labor is a fine and noble profession, but if you have a highly marketable skill it’s probably not the career path for you.
You may say “This is all fine and good, but I’m getting paid big bucks for CRUD.” But you do not get paid big bucks in a vacuum. A company that is willing to pay you US market rates for CRUD is a temporary market aberration. You are one new boss away from being out on the street, exposed for the obscene cost center you are. At which point you will have many years of CRUD on your resume, instead of being the guy who worked in audio compression or graph theory or scalable systems. Ride the gravy train, but make the conscious effort to stay current. Winter’s coming.
As a contractor, one of the things I look for to qualify leads is “Is the project hard?” For example, a lot of people use the word “simple” when talking about the app they want to build (“I want to make a simple app that…”) which is really a kind of secret code for “easy” or “cheap”. (They are completely oblivious the fact that practically the whole mantra of Steve Jobs, and of the iPhone, is that simple is hard and expensive, and obliviousness is a very bad trait in clients.) Whenever somebody says “simple”, I know immediately that the project is going to Outsourceizstan. Often the clients do not know this themselves. Time and effort is poured into the sale. Conference rooms are stocked with cupcakes and coffee. Then, all of a sudden, they find some underappreciated undergrad to do it, and stop returning your calls.
Although I am a happy contractor, occasionally I humor job offers. In addition to a full deck of other questions I ask, I inquire “So what are you going to do if you have trouble filling the position?” Usually they look at me like I am crazy and and that they are sure the right person is in the resume pile, or that I are not the only candidate that they are talking to, or some equivalent response. Which is code for “This job is not very hard.” As soon as they say that, the jig is up–they are hiring a warm body to write a for loop or two and go to meetings twice a week, and they can fulfill those requirements a lot more cheaply than by hiring a real professional software developer. Other people can tackle that; you were born to solve real problems.
When I was starting out, I would describe what I do as “writing iPhone apps,” which was both accurate and sufficient. But as the market has matured, I’ve started to say we “write really hard iPhone apps, that are too hard for other developers to write.” It’s not that we’ve taken on projects that are much harder than what we’ve always done, but that the bottom of the market has dropped to do the floor, with a lot of things these days being cookie cutter types of code that really anybody can whip together. And the “we do really hard things” positioning turns away all of the cheap people and yields a lot of high-quality referrals from people who really are doing rocket science and as a result need somebody really good.
Of course the supply-side economics for working on hard things is good if you are a developer, because you are a big fish in a small pond. But what about the demand side? There is a limitless demand for CRUD, but only a limited demand for novel research, right?
It’s true that the demand is more limited. One thing I’ve observed, particularly in the business world, is that people seek out incremental improvements to existing tools. CRUD projects get started because it is easy for a manager to imagine how to improve upon Excel. It is a lot harder to imagine a revolution. Can you even think of what the first meeting for the iPhone project must have been like? Perhaps Steve Jobs stood up and said “We’re going to make a revolutionary, simple phone.” But what does that even mean? Where are the requirements? Perhaps you can enumerate a few disrequirements–existing phones have bad UIs and are difficult to use. But we are not within 100 miles of a single feature, or even a form factor. It’s not exactly the sort of thing you can write a spec for and bid out to ten shops.
But it turns out that the demand for iPhones is enormously huge. You just have to be willing to put in the time and effort and R&D. Which requires buy-in from the people around you; they have to be on board with breaking the chain of incremental improvement and working on the revolution. This may not be the case where you work. One of your biggest constraints for Doing Hard Things is the imaginations of those around you. If your manager is a visionary and your coworkers bank at San Serriffe, then you have a nonzero shot at working on something decent. But otherwise you will spend your days poorly re-implementing Excel. Don’t do that. We need you. We need you to push the world forward. Leave the incremental improvements to others. Find a community of bold revolutionaries.
As you are reflecting over your work this past year, think about what you have worked on that is Really Hard. Think about how you have pushed a discipline forward, an industry forward, and your customers forward. Think about how you transformed a company, made a new discovery, developed a novel algorithm, improved the runtime of code by an order of magnitude, written a better malloc, saved someone a million dollars, and added to human knowledge. If you’re not playing at this level, get it together. Do Something Hard. Do something so that you will look back a year from now and say “I was here, I did this, I made a difference.” Either that or move to Outsourceizstan.
You don’t have to suddenly quit your job and have a mid-life crisis. You can start small. Start reading an academic journal. Start that open-source project you’ve been meaning to work on. Sketch out the wireframes for that app. Just as one dollar a day through the magic of compound interest makes millions over a lifetime, 20 minutes of time invested per day pays enormous dividends over decades. Breakthroughs are made with far less. You don’t have to join a monastery and swear off HN forever. You just have to start.
git commit -a -m "Initial commit"
 When I talk about writing CRUD software in this article, I don’t mean solving a thorny business problem with an implementation that just so happens to consist of a CRUD application. Nor do I mean an application that is 90% CRUD and 10% quantum mechanics. In either example, there’s a lot of non-CRUD value. I don’t mean CRUD + [arbitrary hard thing X], I mean actually CRUD.