There is no magic, there is only awesome (Part 4)
This is the fourth (and final) article in a series titled “There is no magic, there is only awesome.” The first article introduced the four cardinal rules of awesomeness, the second was about knowing thy tools, and the third encouraged you to know thy languages .
First off, I apologize for dragging this out. It’s really become a weight on my shoulders. I’ve been fretting and fretting about writing the last two or three posts in this series, and I just couldn’t find the inspiration to make them come out like I wanted…and they’ve been holding up other posts I’ve been wanting to write.
So I’m going to cheat. You’re going to get a braindump, more or less, of the last two rules of awesomeness. Yes, I am entirely cognizant of the irony here. Nonetheless, here goes.
Rule #3: Know thy libraries!
If you want to be awesome, know your dependencies. At the very least, understand what each plugin, library, and technique you use, does. If called on to explain why you are using a particular design pattern, could you justify it? If someone asked you to compare plugin X and plugin Y, could you explain what their different strengths and weaknesses are? If you discover a particular library behaving erratically, would you be able to dig into the library’s guts to tell the author roughly where the problem is? Or would you be one of those who has to tug on the author’s sleeve and say, metaphorically, “it hurts when I do this”?
By libraries, I mean (essentially) any bit of code that you depend on, that has a life of its own outside your application. I’m including design patterns in this, although they aren’t really code, but they do represent a “library” of possibly ways to architect code. Basically, if you’re using someone else’s code, algorithms, or techniques, know why you’re using them. Make sure you can answer the four questions:
- What does this do best?
- What does this do worst?
- Why should I use this in particular?
- When was the last time I learned something new about this?
Rule #4: Know thy communities!
The last rule says that if you want to be awesome, you can’t do it in a vacuum. By writing code, you automatically join an ecosystem, whether it be a network of coworkers who will help you write, debug, deploy, and maintain that code, or a community of hobbyists who might wish to use your code in applications of their own (or who are writing code that you want to use). Even if all you do is pop up out of your cave long enough to toss some code into the public domain, you’re still contributing to a community, and if you’re using other people’s code, then you’re a consumer as well.
Don’t be blind to those communities. Stop for a minute and think about the communities you belong to, whether explicitly (where you’re a card-carrying, due-paying member) or implicitly (where you’re passively consuming someone else’s code), or somewhere in-between.
Why is this important? Mostly because communities are resources. Each community will be good for different kinds of help, collaboration, or criticism, and if you want to make the most of those resources (which, if you’re really awesome, you will), you need to know where each shines. Again, apply the four questions. What does this community do best? What is it worst at? Why should I participate in this particular community, over all the possible alternatives? And when was the last time I learned from this community?
That last is important, and surprisingly deep. If you are no longer learning from a community, what are you still doing there? Some of you are no doubt saying “but, but, but” and eagerly pointing out that maybe someone is part of a community so that they can lift others up, but note: if you’re doing that right, you’re still learning from those you teach. You learn new ways that your craft can be confusing to people. You learn new ways of looking at things that you’ve been taking from granted. You learn new ways to rephrase concepts that have grown stale in your own mind. It keeps you fresh. If you’re doing it wrong, though, then the only reason you remain in a community that teaches you nothing is complacency. And complacency is on the opposite end of the excellence spectrum from awesomeness.
Words of caution
So, those are the four rules. There is one overriding caveat to all of this, though, and that is: use moderation. You’re not going to master all of this in a day. Or even a week, or month, or year. I don’t know anyone that is perfect at all four things (though I know many who are much, much better than I am). To sound all zen and mysterious: awesomeness is a journey, not a destination. Enjoy the trip, appreciate the view, but don’t overdo it.
When you overdo it, you risk burning out. I’ve been riding that line for a couple years now, which was frightening. When writing code is your bread and butter, paying the bills and putting food on the table for you and your family, it is scary to contemplate “what do I do when I suddenly don’t want to do what I’ve been doing”. This is a big reason why I had to let go of Capistrano and other projects, and why I’ve discovered other hobbies (like woodcarving, string figuring, and cooking) that do not involve computers. I’m trying to find the middle ground, so that I can recapture the joy of writing code.
So: be awesome. But only in moderation.
You make an excellent point about striking a balance between coding and other hobbies to achieve full awesomeness. It’s very easy to become engulfed in a sea of various technologies and projects so that they end up occupying not only your working hours but your leisure time as well, which of course becomes tiresome after a while. Thanks for the reminder.
25 Jan 2010
I agree with both of these rules, and would have liked to see you elaborate on them a bit, but I can also understand the need to just kick stuff out of your path sometimes.
I would argue that true, zen awesomeness can only come when you have that balance / moderation you’re talking about. If your entire life is code, on matter how good you are, I wouldn’t call that awesome… I’d call it a little bit pathetic.
26 Jan 2010
Hey Jamis! I enjoyed the 4 series awesomeness articles.
if I get this straight, the basic idea of your article series is the programming language and its resources [people, readable materials, libraries]; even though that you mentioned the design patterns in hurry.
I have something to add:
What about the concepts or generally the theories? for example knowing the concepts of the OOP involve more than the languages or libraries; think of UML as a tool to understand the OOP. we can consider the algorithms & math parts of this also.
another thing, you didn’t mention the programming domains. for example programming in HTTP context; is different than programming a device driver.
last thing, almost everything you talked about is somehow a tool. for me, the “four cardinal rules” should be something like:
1. Know thy tools. 1.1. Know thy languages. 1.2. Know thy libraries. 2. Know thy domains. 3. Know thy theories. 4. Know thy communities.
13 Feb 2010