During the 1950s, a then-unknown journalist named Hunter Thompson briefly held a job working for Time Magazine. During his tenure there, he used a typewriter to type the text, verbatim, of novels by Ernest Hemingway and F. Scott Fitzgerald in order to feel what it was like to write a novel in the literary voice of those great authors. Thompson would go on to write many articles and some books of his own, including the popular Fear and Loathing in Las Vegas, which was eventually made into a movie starring Johnny Depp and Benicio Del Toro. He is also the inventor of a wild, manic style of ‘reporting’ known as Gonzo Journalism in which the author is the story as much as he reports on the story.
If you type out A Farewell to Arms or The Great Gatsby, I think it’s pretty unlikely that you’ll be the next Hemingway, Fitzgerald, or Thompson. I mean, no offense, but the odds are against that. But what you must have is an incredible amount of appreciation for your craft as an author and an intense desire to carefully study and learn the habits of success and ingenuity. And while you may not strike the big time, I have a hard time imagining that you’ll be worse off for doing so.
In our line of work as programmers, there’s a very important difference between writing the code for an application and writing a novel. A novel is intended to be utterly unique and creative, and it serves as its own end. A program is intended to get the job done and uniqueness is neither necessary nor particularly desirable. (It’s not undesirable–it just doesn’t matter). But in both cases, someone interested in getting inside the mind of success could do a full-on emulation of a renowned practitioner. As a programmer, you could do your best Hunter Thompson and bang out an early version of the Linux kernel, emulating Linus Torvalds and his success at crafting a product.
There are certainly barriers to doing this that don’t exist when it comes to novels. A sizable chunk of software is proprietary, so you can’t see the code to emulate it. The code, language, libraries and platform might be so hopelessly dated that finding hardware on which to run it proves interesting. And if you’re on the cusp of being fired for misappropriating company time, it probably isn’t advisable. But still, imagine what that would be like…
I call this “reverential practice,” though it isn’t practice in the true sense. It’s more of an homage. If you look up practice in the dictionary (the definition we’re using here anyway), you’ll see that it requires repetition for skill acquisition. This clearly isn’t that, since you’d be doing it only once. I say “reverential practice” as a nod and distinction from a term I like that pops up in software blogs and talks: “deliberate practice.” I like the term “deliberate practice” because it distinguishes between doing your job and honing your skills via drilling and focusing deliberately on areas that need improvement. (The term does skew a little heavy toward a borderline weird equation with software development as performance art, but who am I to begrudge people literary and dramatic devices?) And now, I like the term “reverential practice” because it invokes the same connotation of specific attempts to improve, but via unusual amounts of respect for the approach another has taken.
I’m not suggesting that you go out and do this, but it would certainly be an interesting experiment. If you did it, what would you learn from it? Can you do it on a more micro-level in which you just ask someone prominent in the field for a little application they’ve written and then write it yourself? Would it work with just the finished product, or would it be better to see a screencast of them coding and type along with them, extracting methods and deleting things that maybe weren’t right after all? And, most importantly, would it help you improve at all, basking in the reflected successes of another, or would it be a pure act of quasi-religious Programmer Work Ethic?
I don’t know, and there’s a pretty good chance that I’ll never know. But hopefully that’s some interesting food for thought on this Friday. Cheers!
Creating the end-product for software is so dynamic. (Think of all the refactoring one does over a large project.) I appreciate the end result of how things are put together and also appreciate the crafting process (i.e., all the things that failed to be the end-product). For me, learning the crafting holds a lot of value.
Thanks for the thought-provoking post!
Glad you liked. And I’m with you — I think I’d be more interested in the process than the end result.