By Deane Barker on September 19, 2003
I’m about to admit something odd, and perhaps career-threatening: I’m sick of learning.
There, I said it, and I feel better. It’s true: learning about new technologies and new ways of doing things is something that plays on an addiction of mine and of many other geeks, I’m sure. We just can’t help but learn about the newest way to run a content management system, develop a Web application, send data from one computer to another — it’s intoxicating to us.
The bizarre thing is that we want to learn it, even if we never do anything with it. We just want to know. When I was a kid, I used to buy board games and role-playing games just to read the manuals. I had boxes of them that I never played, I was just intellectually challenged by the game systems, and I loved to wrap my mind around them. The same thing plays here.
Jakob Nielsen just wrote a column that says much the same thing:
“Recently, investments in new technology have slowed and productivity has surged because companies are focused on making existing technology work rather than chasing the latest fads.”I’ve written about this a couple of times. Back in May, I wrote:
“You know what I think? We have enough platforms already. They keep getting faster and simpler and one day there’s going to be a platform to which I can just say, ‘Hey, platform, build me a Web app,’ and it will be done.Two months later, I wrote this about the glut of content management systems on the market:
But you know what? Most apps will still suck. Building a great Web site or app isn’t about platforms, it’s about usability and content development and interface design and program flow and all the intangibles that you have to think about. These are things that no platform is going to fix.”
“I’ve tried very hard to keep track, but there are too many. And there’s so much duplication. Every day a new system comes out that says it’s better than the last one. But is it? Has anyone really broken any new ground in content management in the last two years? We run from system to system like we have CMS attention deficit disorder.”It’s true — we learn far more than we are ever able to use. We learn just for the sake of learning. We find some new technology, read about it, then whip up a script or two just make sure we know how to do it, then we dutifully zip it up and file it away in a “Code Samples” folder somewhere for future reference. And there they sit today, like wallflowers at a school dance, waiting for the application that will likely never come.
This may seem harmless, but does it, in fact, hinder our ability to produce? Does all this learning and all the attention span we spend on new technologies detract from what we should be doing in the here and now? How many applications have gone unwritten because we think some new technology will obviate them in the next few months? How many ideas languish because we’re playing around with the new hyper-whizzbang protocol, convinced that this is the solution to our problems and will make every application fly off our keyboard with ease?
Joel Spolsky of Fog Creek Software has written a number of items that say this same thing. He recently talked about how he interviews and hires new employees. He stated there were two criteria: “Smart and Gets Things Done.”
“Gets Things Done is crucial. People who are Smart but don’t Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. They would rather mull over something academic about a problem rather than ship on time.This reminds me of a lot of the geeks I know. “Smart, but not useful.” I dearly hope it doesn’t apply to me, but every once in a while I find myself trying to make something work just to prove it can be done, and I wonder. Joel also wrote the forward to a new book “In Search of Stupidity,” in which he opines:
These kind of people can be identified because they love to point out the theoretical similarity between two widely divergent concepts. For example, they will say ‘Spreadsheets are really just a special case of programming language’ and then go off for a week and write a thrilling, brilliant white paper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful.”
“There are still scads of programmers who defend Netscape’s ground-up rewrite. ‘The old code really sucked, Joel!” Yeah, uh-huh. Such programmers should be admired for their love of clean code, but they shouldn’t be allowed within 100 feet of any business decisions, since it’s obvious that clean code is more important to them than shipping, uh, software.”More evidence, this time from NetCrucible:
“You can make lots of people happy and solve lots of real-world problems without having a very good platform, but you can go broke even with the ‘best’ platform if you are NOT making real people happy and solving real-world problems. And as far as I can tell, real-world problems that could benefit from software are infinite.”Is learning a defense mechanism? Do we keep learning so we don’t have to write code? Is learning just an easy way to avoid having to actually put ideas into practice? Is this a case of, “Those who can, do. Those who can’t just read a few more blogs and test new theories.”?
Let me summarize the two previous rants I’ve been on about this:
- Platforms will give you back what you put into them.It’s like a marriage: put the time in, overlook the faults, celebrate the benefits, and you’ll have a meaningful relationship.Take this site, for example. We run on Movable Type and there are a number of things about it that annoy me. However, I’d rather pump out content (almost 10 entries a day on average), than fiddle with it, so we live with the limitations. Consequently, this blog has been enourmously successful.
- In very few cases will the techincal underpinnings of an application be the dividing line between great and also-ran. Applications are about usability. A great application is not great because of great code. It’s great because the purpose, the interface, and the flow of the application makes the users happy. Don’t hire another programmer, hire a good interaction architect.
Then, above all, do something. Shackle youself to this technology and write something. Stop worrying about code and protocols and what Poindexter the Perfect Coder will think of your class files. Don’t look out on the horizon and worry that a new language will render your app irrelevant. Just write something. Solve a problem. Make an existing application better. Re-work an interface to remove issues users have been complaining about. Deliver some value to someone, somewhere.
And do it with the technology you have now. You’ll be a better person for it.