For you do not yet know the strength of your hearts, and you cannot foresee what each may meet upon the road. Elrond

“So, who’s Justin Bailey?” you might be wondering. JUSTIN BAILEY is one of many Metroid passwords. Is he a real person? I have no idea. There are a few theories on why JUSTIN BAILEY is a Metroid password. So, fire away if you’ve ever wanted to play Metroid as Samus in a bathing suit.

“Uh, what does Metroid have to do with GAIAttack?” Well, just like Justin Bailey, “spooner” now joins the ranks of cheats putting players in bathing suits. Okay, not really. Enter “spooner” (without the quotation marks) on the start screen of GAIAttack and unlock the following cheats: during play, type “0” to go to the next level, “9” to go to the previous one, “8” to go to the next save point, or “7” to go to the previous one. Unfortunately, your score and time won’t be submitted to the leaderboard. So, cheat and have fun.

If I don’t keep working then my body will become useless. Jiro Ono

Well written code should be crafted so that it is polite. It should approach detail gradually, the way a newspaper article does. It should allow the reader to bail out early, as soon as they realize that they don’t need to understand the whole thing.

My current theory is that programming is quite literally writing. The vast majority of programming is not conceptually difficult (contrary to what a lot of people would have you believe). We only make it difficult because we suck at writing. The vast majority of programmers aren’t fluent, and don’t even have a desire to be fluent. They don’t read other people’s code. They don’t recognise or use idioms. They don’t think in the programming language. Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel. And so our programs are needlessly complex.

… Why do I call Mr. Khan dangerous? … Imagine the consequences if his videos did become the DOS or Windows of education: tens of thousands, hundreds of thousands, millions of young minds, all fed by Mr. Khan’s fizzy version of history. Not only would all students absorb the same value judgments, goofy comments, and cultural relativism, they would also conclude that Mr. Khan’s factoids constitute knowledge of history.

To which Mr. Khan replies,

I start most of [my videos] telling the listener to be skeptical of anything I tell them or anyone tells them; that no matter how footnoted something is, in the end it is dependent on people’s accounts—the people who weren’t killed—which are subject to bias (no matter how well-intentioned). Very few history books or professors do this. If anything, they create a false sense of certainty.

via

If all else fails, [working harder than anyone else] is the greatest competitive advantage of any career. John C Jay

We arrived in Chicago around 11 a.m. on Friday morning. Matt picked us up in his Mini and drove us back to his place. We talked about the weather, the 2002, Minis, moving to big cities, and the joys of childhood snow days. Our time with Matt was short-lived, but he was extremely kind. Allison was worried about buying one-way tickets, purchasing a car sight-unseen on Craigslist, and being picked up from the airport by a stranger. But, as she said, “He was wearing TOMS. So, I knew everything was going to be okay.”

We left Chicago after stopping for a pie at Giordano’s, per Jonathan Bowden’s suggestion. I’ve never met Jonathan, but it was nice of him to suggest places to eat while visiting Chicago. The pie was delicious.

Allison’s sister and brother-in-law are the innkeepers at a small bed and breakfast in Marion, Indiana. We stayed with them for two nights. We tinkered with the car, snuggled with Juniper (their brown-coated Boston Terrier), ate good food, and played Catan. Our stay was much too short; we love them dearly.

Sunday morning we began our journey home. The snowy roads caused for mixtures of enjoyment (fish-tailing is fun), anxiety (fish-tailing at fifty miles-per-hour is not fun), and slow progress (two-lane, fifty-mile-per-hour, snow-covered roads take too much time to traverse).

The little Beamer isn’t car-show-worthy. There are things I can’t wait to change about it. I’m a tinkerer at heart. It’s the programmer in me. Two things I’d like to upgrade soon are the exhaust and the suspension. The car appears to have been lowered, and we could feel every bump in the road. The exhaust, however, had never been upgraded. It’s old. It’s rusty. And is—now—being held onto the car with coat hangers.

West Virginia’s Turnpike is… well… “shitty” would be putting it nicely. The entirety of the toll road consisted of kah-chunk-kah-chunk-kah-chunk, interspersed with a few did-we-lose-the-muffler? thunks. I won’t sugar-coat it; it was awful. Twenty miles north of Beckley is when camel’s back was finally broken. I heard a horrible metal-on-asphalt sound and saw the trail of sparks flying from underneath the car in my rearview mirror. I pulled over as quickly as I could. Thankfully a rest area was nearby.

I didn’t bring any tools with me on the trip. Who knows what the TSA would do if I lugged a case of tools onto a plane. I didn’t want to find out. So, I opened the trunk at the rest area, scratched my head in that motion-picture-defining way, and began to dig through the nuts and bolts scattered about. I found a rubber tow strap with an s-hook. I dismembered the tow strap and laid down in the parking lot against the tail of the car, s-hook in hand. I surveyed the damage. It wasn’t too bad, and I was able to rig the muffler to its clamp with the s-hook. I hopped back in the car, delighted with my own ingenuity. Allison’s tone was normal but her face said otherwise. We set out again, but a new sound joined us as we got up to speed on the highway. It was the rat-a-tat-tat of a drive shaft hitting a muffler. I drove on for a bit hoping it would pass as the drive shaft bent the muffler. I was wrong.

Frustrated and running out of options, I stopped at the next exit. There was a gas station, and inside my best hope laid in a fly swatters’s twisted metal handle. I stared at the fly swatter for a few minutes trying to envision it walking with me to the car and hugging the muffler as if in a Pixar film. Finally, from behind the counter I heard, “Can I help you, sweetie?” The cashier probably wondered what was so fascinating about a fly swatter. I explained my situation to her, and she had an alternative. A friend of hers, someone who lived nearby, was in the station, and she suggested I explain my predicament to him as he was a mechanic.

Finally, a glimmer of hope.

We never exchanged names. I told him my problem. We both got on the ground to look at the dangling muffler, as if staring would help. He hopped up, ran to his truck, rummaged in the tool chest, then asked his wife to run home and get some hangers. He used pliers to bend and snip the hangers as if he’d done it a hundred times. The sling he fashioned fit my muffler like a charm, and I thanked him more times than I can count. He handed me two more hangers, a pair of pliers, and a box of hand wipes for the rode. I told him he didn’t have to, but he insisted and I accepted. I offered him a drink and a pack of smokes, but he declined. The, he followed me twenty miles down the highway to make sure it was going to hold. He knew as well as I West Virginia’s roads would be the best stress test.

Those hangers held my muffler in place the rest of the way home.

I don’t know his name. I doubt I ever will. We live in a world where the internet affords easy bitching-and-moaning. We complain when a web site isn’t what we expect, when a site redesigns and it’s not to our liking, about the ninety-nine cents we have to pay for an app we don’t need from a phone that costs four hundred dollars. We’re a spoiled bunch. This stranger sacrificed his time and knowledge to help another human being. Sure, it was a few hangers, some pliers, some hand wipes, and a few minutes, but it was not his problem. He only wanted to help me get home. It’s an encounter I’ll never forget and a lesson I’ve taken to heart.

Self-Control

First up is self-control. Self-control doesn’t get much airtime these days. It ranks right up there with personal responsibility and doing the right thing. We tend not to like these terms because they place emphasis on our ability, and oftentimes we fail. Self-control in getting things done is convincing yourself to not look for distractions when you reach a tough spot. Push through those difficult spots and finish victoriously.

Focus

Focus is another key ingredient for productivity. It’s self-control’s close relative. What good is focus if it’s being used on the wrong thing, or worse, some form of time-waster? Focus means turning off the distractions, hopefully without the aid of a tool. It means employing self-control. It’s the tunnel vision needed for getting things done, on-time with excellence.

Knocking out a stringent todo list is a piece of cake when wielding these two tools. The best part is they’re free, but they’re not cheap. We are creatures of habit, and breaking a habit is hard to do. Ask anyone who’s ever tried to quit smoking—my uncle is on his fifth try. Maybe you’re used to browsing the internet on the clock, or maybe worse. Maybe you’ve convinced yourself it’s normal. You may need some sort of hack in place to rewire your brain. I did. Ultimately it’s on you. You’ve got to want to be productive. You’ve got to want to create. It will start when you see the joys of accomplishing something rather than absorbing others’ creations.

When it comes to hierarchical boundary crossing, it’s most often not reluctance that stops people from doing it. It’s ability. Programmer geeks can’t lead, and leaders can’t hack. It’s rare to find someone who’s even decent at both. Chad Fowler

One of the many fantastic features in Safari 5 is called Safari Reader—it’s based on Readability. If you’re reading this in Safari 5, go to View > Enter Reader or press cmd+shift+R (⌘+⇧+R) to try it out. Pretty spiffy, huh?

While Safari Reader is extremely handy, I’m not happy with the default typography:

So, I started looking for ways to adjust the type. Thankfully, the internet is full of like-minded individuals, and I found an article on how to modify the look of the Safari 5 Reader. They recommend creating a backup of the original Reader.html file, and so do I. One thing they don’t mention is you’ll need to restart Safari anytime you want to see your changes. I spent a few minutes hacking away at the CSS and arrived at something I’m happy with:

Here’s the CSS if you’re interested (“»” denotes a continuation on the same line):

<style>
* {
   -webkit-font-smoothing: »
      antialiased;
   font-family: "Helvetica Neue", »
      Helvetica, sans-serif !important;
   color: #444;
}
a {
   border-bottom: 1px dotted #65a2ef;
   color: #0064e5 !important;
}
a:visited { border: 0; }
a:hover {
   border-color: #cfe2fa;
   color: #4c9bff !important;
}
p, li {
   font-size: 14px;
   line-height: 21px;
}
#article { width: 619px; }
#background { background-color: »
   rgba(0, 0, 0, 0.9); }
#container { margin-left: -333px; }
#drop-shadow { width: 600px; }
.page {
   background: #F6F6F6;
   width: 458px;
}
</style>

These styles are down and dirty. So, use them at your own risk. The easiest way to add them to Reader.html without disturbing the default styles is by appending the above code below the last </style> tag and above the first (and only) <script> tag within the document’s <head>.

The Anchor gets the ball rolling, discussing the current state of The Project. But you’re not interested in the current state. You’ve got some game-changing ideas that are winners, the kind of ideas where God and everyone in the room will bow down and worship your ingenuity.

The brainstorming sessions are orderly, going around the room starting on The Anchor’s right. That’s why you chose to sit on her left. You want to be last because you have the best idea, but guess what… You’re probably wrong.

“You’re probably wrong,” is the number one tool I walk into any meeting with. It’s not about self-abasement, it’s about humility. Walking into a meeting with the cocksure attitude of, “my ideas are the best,” is a surefire way to ignore what everyone else has to offer because you’ve thought through their idea, apparently, and know it’s flawed. The truth is the odds are against you. Very few ideas reach The Best Idea status and people rarely recognize them when they are The Best Idea—remember when Twitter first came out? Few people understood its importance.

So, walk into your next meeting equipped with, “I’m probably wrong.” It will allow you to table your idea and focus on what everyone else has to offer. Who knows, you may learn something new.

Of course, I’m probably wrong.

There’s one prerequisite for managing styles and scripts using the following method: the LG .htaccess Generator. It’s possible to use a different approach, but this method assumes you’re using Mr. Graham’s extension.

First, if you haven’t already, enable gzip compression from within EE(ExpressionEngine)’s control panel. Go to Admin > System Preferences > Output and Debugging Preferences and select “Yes” under “Enable GZIP Output?” Click “Update” to save your settings.

Next, create a new template group for your style sheets. I generally name mine “styles”, but name yours whatever you’d like. Don’t duplicate a group. Click “Submit” to create the group. Within this new group, create a few templates with a type of “CSS Stylesheet”. I generally create a style sheet template for each logical group of styles: a style reset, some typographic styles, default styles, some hacks, etc. Put corresponding styles in each of these templates. I save all templates as files and use EE(ExpressionEngine)’s built-in template revision system. You should see a checkbox with the label “Save Template as File” just above the “Update” and “Update and Finished” buttons on the template editing page. You’ll need to allow templates to be saved as files if you don’t. Go to Templates > Global Template Preferences > and select “Yes” under “Allow Templates to be Saved as Files?” While you’re there, select “Yes” under “Save Template Revisions”. Click “Update” to save your settings. This is simply an added safety net since you’re using some sort of version control for your site, right? Right.

Next, repeat the same steps for your JavaScript files. I typically name the group holding JavaScipt files “scripts”. Each of the templates should have the type “JavaScript”. I generally store classes and frameworks (jQuery, Prototype, etc.) in separate templates with each class getting its own template.

At this point you should have two template groups: one holding a few style sheets and an index and another holding a few JavaScript files and an index (“index” is automatically created when you create a template group).

Being kind to your server means you should serve only one style sheet and one JavaScript file per page load, ostensibly. And Server Side Includes—or SSIs—allow this method to be robust and kind to our servers. SSIs are called embeds in EE(ExpressionEngine) lingo.

So, we’ll use each group’s index file to serve a single file per type. Open your style sheet group’s index file and add an embed for each of the templates in your group (minus the index, of course). Here’s my style index as a reference:

{embed="styles/reset"}
{embed="styles/type"}
{embed="styles/layout"}
{embed="styles/default"}
{embed="styles/hacks"}

Repeat the same process for your JavaScript group’s index file. Remember, the order of the embeds is important.

We need to set the content type for these index files so the browser interprets them correctly. Go to Templates > Template Preferences Manager. In the first section, select your style template group name under “Template Groups” and “index” from the list of templates. In the second section, select “CSS Stylesheet” under “Type”. Click “Update” to save your settings. Repeat the same steps for your JavaScript group’s index file, selecting “JavaScript” as its type. Don’t forget to click “Update” to save your settings.

At this point, you should be able to visit http://yourdomain/styles/ and see a single style sheet containing the files you specified in your style sheet group’s index. The same goes for your JavaScript group.

There’s a final step to make this system nearly perfect: a cache-busting system. You’re caching requests for media files on your server, right? Read Yahoo’s Best Practices for Speeding Up Your Web Site if you’re not sure what I’m talking about. So, you’ll need a way to bust the cache when you make changes to your styles and scripts after you’ve enabled caching on your server. To do this, you need to create two global template variables: one for styles and one for scripts. Go to Templates > Global Variables and “Create a New Global Variable”. Name the variable something memorable. I generally name mine CSS_VERSION and JS_VERSION. The “Variable Content” should be something that’s easy to increment. I use a three digit version number, 1.0.0. You can use whatever you’d like, but be sure to keep it simple. Also, do not input any whitespace (spaces, tabs, or line breaks). Click “Submit” to save each global variable. These global variables will need to be incremented anytime you make changes to their corresponding files. So, you’ll need to change the version number(s) if you add or change a style or piece of JavaScript. The actual number is irrelevant. Incrementing makes sense (for our linear view of time) though.

Finally, we need to add a link and script tag to our document’s head. They should look similar to this (“»” denotes a continuation on the same line):

<link rel="stylesheet" »
      href="/styles/?v={CSS_VERSION}" »
      type="text/css" media="screen" »
      charset="utf-8">
<script src="/scripts/?v={JS_VERSION}" »
      type="text/javascript" »
      charset="utf-8"></script>

Your mileage may vary.

You’ll notice after each path is a GET variable v. This is the cache-busting variable. The v= isn’t necessary. You could strip it down to just ?{CSS_VERSION}, and it would work fine. You’re probably thinking, “Why not just put the version number inline? Why store it in a global variable?” You could definitely place it inline and everything would work as described. I find storing these version numbers in global variables to be cleaner.

One final note: This method isn’t tied specifically to ExpressionEngine. It should work in any content management system. The nomenclature and syntax will be the only differences.

So, there you have it: a robust, cache-bust-able, single-serving-file method for managing style sheets and JavaScript files in ExpressionEngine. The only ingredient we’re missing to make it perfect is compression/minification, but this system should be robust enough for the majority of sites.

I’m not sure why but it seems we’ve lost the ability to mind and respect our surroundings, especially in public. It’s apparent in any restroom. The stalls are disgusting with un-flushed business, toilet paper strewn about, and piss on the seat. The locks are broken off the doors. The sinks are clogged with paper towels like the Wet Bandits struck again. Not to mention, it looks like you can get some sexual favors by calling the number(s) written on the wall.

I’m fairly certain your bathroom at home is clean and orderly. You pick up the toilet paper you dropped on the ground. You wipe up the counter where you splashed a gallon of water while washing your hands. You lift or clean the toilet’s seat. You flush the toilet. You don’t doodle or write your friend’s phone number on the wall.

So, where’s the disconnect? Why is it okay to treat public surroundings any differently than you would your personal surroundings?

It boils down to respect and mindfulness. We no longer respect other people’s property. Besides, someone gets paid to clean this up, right?

I implore you to mind your surroundings at all times. Clean up after yourself. Respect other people’s property. Pick up the toilet paper, paper towel, or napkin you just dropped. Lift the seat or wipe it off. Clean up the ketchup you squirted onto the table. It’s not hard. Respect for the small things in life builds into a respect for the larger things.

Work is a major portion of our lives, at least for most of us, and I’ve been mulling over what it means to be a professional. The definition most of us are probably familiar with is a professional is someone who gets paid to perform a certain task, duty, trade, or skill. The fourth edition of the American Heritage Dictionary defines a professional as, “One who earns a living in a given or implied occupation; a skilled practitioner; an expert.” That’s a pretty good definition, but I have one major problem with it: it doesn’t talk about character.

Robert Sutton’s The No Asshole Rule is a fantastic book about dealing with assholes in the workplace. It covers how to get along with these rude coworkers, prevent their existence in your company, and how to ensure you don’t become the asshole. The character of a professional is the overarching theme. It’s something we don’t talk about enough. We honor things like problem solving skills, the ability to work quickly, having original ideas, etc. If they’re not an asshole, well, that’s just a bonus.

Character stems into more areas than just how abrasive you are, which is what The No Asshole Rule focuses on. It’s more than just your moral and ethical strength. It’s more than being the nice person at work. It’s a cocktail of all these things and more. It’s about living a life you’re not ashamed to call yours. It’s about following through and keeping your word. It’s about being passionate and critical—the constructive kind, not the negative kind—while still being sensitive to others. It’s about being virtuous and courageous. I could continue, but I think you get the idea. The bottom line is this: your paycheck doesn’t make you a professional, your character does.

There is no expedient to which a man will not resort to avoid the real labor of thinking. Sir Joshua Reynolds

Follow Your Code Standards Guide

I want to be clear, before I dive into any specifics, that you should always follow the code standards or style guide for the team you’re working with. The goal in code organization for a team of any size is clarity and consistency. Your code base should look as though one person wrote it. If you don’t have a code standards guide, then I implore you to write one or adhere to someone else’s.

Use Ample White Space

White space is a key component for clarity in any aspect of design, whether it’s visual design, writing, coding, etc. White space is free, so you have no reason to be stingy. I recommend using a single line break between properties in a property list; two or more line breaks between declarations starting with the same element, id, or class; and four or more line breaks between declarations for different elements, ids, or classes. One exception is a declaration with one property-value pair; the declaration and property-value pair can inhabit the same line. There’s a nice side effect when using this style for line breaks: understandable and easily-skimmed git blame (or whichever repository flavor you use), diff, etc.

Comment Liberally

Most developers I work with shy away from comments, but I find them indispensable. Annotating your code allows others on your team to understand why you’ve chosen a certain technique. Alternatively, you could just ask why your teammate chose a certain method. This approach is fine for small teams, but it’s nearly impossible for large teams. Answering the same question multiple times is a waste of time.

A well-written annotation also helps you. Sometimes you need a reminder for why you wrote a declaration a particular way. I know comments have saved me from myself more than once. Good documentation saves time.

Comments also add clarity. As Donald Knuth said, “I still think people could be documenting what they write much better. And a comment is different than writing an essay. The way you write a program for another human being is completely different from the way you write it for a computer.” Your teammates are not computers. Write a commentary they can understand. Remember, the goal is clarity.

What About File Size?

I often hear this argument, “Well-documented code with ample white space sounds nice in the theoretical world, but it leads to larger file sizes in the real world. And serving large files is not good.” I’ll be the first to say serving large, fully-commented, abundantly white-spaced files is bad. This sounds like a contradiction to my advice on writing team-centric CSS, but it’s not. The files your team uses and tests with should be different from the files you serve your end users. How is this possible? Minification and compression. A major component in any team’s build process should be the step where comments and white space are stripped from the production files. I use YUI’s Compressor and gzip to drastically reduce file sizes for lightweight production files.

This leads to another valid argument, “Multiple versions of the same file bloat the repository.” I agree. They do. My only counter is that having well-documented, amply white-spaced code adds clarity and consistency in a team environment. The trade-off is well worth it.

Maybe you’re a freelancer and have worked on a few different teams. Maybe you’re a one-man shop. Maybe you’re part of an in-house team. Whatever your role, I hope you found this advice helpful. I don’t claim to have the ultimate answers for code organization, and I’d love to hear how you organize your code. and share your wisdom.

find . -iname \*pattern\*

Let’s dissect it. The name of the command is find, the .—say, “dot”—means “start walking the file hierarchy from my current location”, -iname tells find to look at files names and ignore the case—case insensitive, and \*pattern\* lets find know what string or pattern we’re after.

I have a large collection of books in PDF I frequently reference. I rarely remember the name of the book, but I know it has “PHP” in its title. So, I cd to my directory of books and enter find . -iname \*php\*, and I’m given a list of books whose titles contain “PHP”. Alternatively, I could’ve entered find path/to/my/books/ -iname \*php\*.

I ride my bike to and from work everyday like a good little hippie. I’ve been seriously riding for nearly 15 years which means I ride on clipless pedals. My first experience with clipless was on a mountain bike. The trail was Salem Park in Winston Salem, NC. I was nervous, as most beginners tend to be. The course was muddy, and I was clumsy. It ended with me wrapped around a tree at the bottom of a set of whoop-de-doos. It was a learning experience: take to the trail when you’re mildly confident, not your maiden voyage.

I now ride strictly on the road and only as a mode of transportation. I’ve long since lost the joy of dodging trees, and the mere though of riding on the road for hours bores me to tears. I do, however, still ride exclusively on clipless pedals. This means I’m that guy with those funny shoes, clip-clopping through the store, seemingly afraid to put his toes on the ground. They look like reverse high heels. The soles are extremely stiff. And the cleat is cause for alarm.

Every morning, upon arriving at work, I walk up a set of rubber coated steps. My cleated riding shoes grip nicely, and the clipclop is muffled to a dull thudthump. Every evening I strap on my riding shoes and exit down a different stairwell. A stairwell with no rubber coating, just raw exposed concrete. This naked set of stairs becomes the banana peel to my Mercedes when wearing my riding shoes. And on this particular evening… Halfway down the oily slope, I slipped—bike hoisted in the air. I land hard on my ass and left elbow. My kidneys slam into the steps. I slide to a halt and my bike finds its way on top of my legs. I gasp for air like a monk grasping for faith. Nothing coming. Pain is searing through my body, and the only thought running through my head is, “I so hope I didn’t break my coccyx.”

Seconds pass and air finally finds its way back into my lungs. I kick my bike off me and pray that no one walks into the stairwell adding pride to my list of hurts. I laid there for a moment allowing the pain to wash over me, absorbing it, trying to read the pain for more than just bruises. I stand up. I’m shaking. Nothing feels broken. I walk, hesitantly and purposefully, down the second half of the stairwell. I reach the sidewalk outdoors and try to roll my bike, thinking I could somehow make it home, dazed and confused. The bike jerks a syncopated roll. I look back and the wheel is slightly bent, grabbing the brake pad awkwardly, and I realize there would be no riding in my immediate future.

I grab my phone, which was luckily unharmed in the fall, and call my wife. She was already in transit, so the wait was short—the only short wait of the night. While I’m on the phone, I notice blood dripping on the concrete. It’s coming from my elbow. On closer inspection, I see a hole in my elbow. A hole. In my elbow. I end the call, and rush upstairs with my riding shoes still on. I scurry to the sink, turn on the water, grit my teeth, and plunge my elbow into the stream. It stings, but I scrub the hole in my elbow anyways. The hole. In my elbow. I finish the scrub down and grab a few paper towels to hopefully stop the bleeding. I walk over to Joshua whose first reaction was to take a picture. Documentation is key. It’s the proof that this really happened. Well, that and the doctor’s bill I’ll soon receive.

Allison arrives and I ask, “How would you like to spend the evening in the emergency room?”

We’re admitted to the emergency room by a portly woman slowly chewing gum. She sees the hole in my elbow and asks me to fill out some paperwork. Thankfully Allison was there and filled it out as holding a wad of paper towels over an elbow isn’t conducive to writing. We hand the paperwork back to our friend at the desk, and the waiting begins.

Everyone knows that hospital waiting rooms contain the world’s most unique people. Take advantage of this. Soak in the sights and sounds … and smells. You won’t get this again for a long time, hopefully.

We sit. We wait.

A couple across from us argues about their parent’s farm. I see no injuries on either of them. They both seem relatively healthy. So, I’m led to believe that a parent is in the emergency room. Maybe they’re fighting over who gets what when father kicks the bucket.

We sit. We wait.

“Spooner,” is shouted. We’re overjoyed; it’s only been twenty minutes. The nurse looks me up and down and asks how I’m doing. My response is that I’m fine other than my elbow and my back. She takes a second look up and down and pauses at my feet. I’m still wearing my riding shoes. She says nothing. We follow her back into a tiny office where she asks me the usual: have I been using drugs, have I had sex with a man since 1978, etc. She takes us to our next waiting room. It’s a smaller room with a few more people.

We sit. We wait.

Allison isn’t keen on sitting still for extended periods of time. She won’t admit it, but I think it’s because she teaches the kids with ADD. She can’t take the waiting anymore and asks if I want some dinner. I decline. She decides to leave and eat. So, I’m left in this second waiting room, staring at my new friends.

There’s a woman three rows over with frizzy hair. Her head hangs between her knees and she’s hugging herself. There are three men next to me—two larger men surrounding a tiny, frail looking thing. I notice handcuffs on the two slices of bread and wonder why they’re escorting this gentleman about the hospital. Click plays on the two televisions, and both officers are watching it intently. How ironic. A movie about a man who wants to fast forward his humdrum life is playing as we all sit and wait.

We sit. We wait.

Another couple enters the room, the woman clutches a baby. The man is pacing the room while she sits down. I imagine he’s scoping out the place, checking for monsters. A smile spreads across my face, but I quickly dismiss it as I notice Officer CHiPs is staring at me. He knows we’re not allowed to have fun in waiting rooms. So, we sit and we wait.

We sit. We wait.

Allison returns from dinner in time for my name to be called. The wait count is up to nearly two hours.

Our nurse leads us back to an emergency room. You know, the kind where you’re put on a bed enclosed by a curtain that doesn’t close all the way and doesn’t reach the ground. So, I sit on the bed. Allison takes the chair. Our nurse asks a few questions about what happened. I explain as succinctly as possible because by now my arm is throbbing and I’d just like to go home. She asks me, “On a scale of 1 to 10, how badly does it hurt.” I say, “3,” and we both have a chuckle at how people usually say, “12 or 13.” Seriously, the scale doesn’t go that high. Stop it. She lets us know a doctor will be with us shortly. What she really said was, “you’re about to sit and wait.” So, we sit and wait.

We sit. We wait.

I pull out my phone and continue reading Chris Anderson’s Free. Allison pulls out her phone and plays Scrabble. She’s an addict.

There’s a woman across the hall from us in a glass-faced room, like the kind Milla Jovovich would be trapped behind in Resident Evil. The woman coughs and moans, incessantly—a hacking, nasty, lung’s-about-to-come-up cough. We’re afraid something is terribly wrong, like and advanced case of pneumonia or lung cancer or … something really bad. Thirty minutes pass by and a doctor comes to visit the coughing woman. He enters, greets her, and informs her that there’s nothing wrong with her. The coughing and moaning stopped instantly and she asked where her shoes were. I wish I shared her diagnoses. All the while, I can’t help thinking that my coccyx is royally chipped.

The doctor arrives. My elbow is scrubbed and bandaged. I’m given a shot. I get to piss in one of those funny looking milk jugs, and then we’re sent on our way.

By this time we’ve spent six hours in the hospital. There’s nothing wrong me other than there being a hole in my elbow that’s too small for stitches and just big enough to be annoying. I’m a patient person. I don’t mind waiting. I never have. I imagine I never will.

Some people despise sitting still. Waiting reminds them of all the things they should be doing but can’t because of some forced restraint. I highly recommend a trip to your local emergency room because hospitals are a test of patience.

Read other people’s code. This sounds like an inane task. Who wants to waste hours of time reading code with so much good literature out there and so little time to read it? Their arguments were simple: seeing someone else’s thought process is beneficial, you might learn something new, and you may learn how good—or bad—code is organized. Douglas Crockford has an interesting method for reading code. He organizes the code before reading. This allows him to focus on the content and not the organization. Others print out code to annotate it.

Learn to write well. Nearly every programmer agreed with this point: programming is more like writing than math or engineering. It’s true, there is an exorbitant amount of math, nay logic, in computer science, but writing a program others can understand is more like writing a novel than a collection of equations.

Learn one language well, then learn other languages. Learning a language well means understanding the methodologies, not just the syntax. Also, learning a language from different types of programming—procedural, object-oriented, declarative, etc.—can be beneficial as each type approaches different problems in different ways. This can influence the way you view your main language.

IDEs and debuggers are overrated. This does not mean IDEs and debuggers are bad. This simply means they are not the best tools to use when starting out. By all means, use them if you are a seasoned programmer. I am apt to agree that IDEs are bad, though. They potentially create hundreds of lines of code without your knowledge, give you far too many hints, and generally dumb down the craft of writing a well-formed program. Debuggers, on the other hand, can be extremely useful if you know how to use them. The unfortunate step is learning how to use them. Stick with a simple text editor—vim and Emacs are wonderful—and use print statements for debugging.

Practice, practice, practice. You can’t learn a craft unless you practice it often. You can’t improve unless you practice it daily. Based on some other reading, pace yourself. If you plan on practicing 5 hours a week, practice 1 hour each day. Cramming is not the same as practicing.

A deep understanding of complex math is not necessary to be a good programmer, but it may be necessary to be a great programmer. Donald Knuth describes himself as a mathematician and a computer scientist. He’s also a phenomenal programmer. Now, there are plenty of mathematicians who are lousy programmers, so the argument falls apart, but understanding discrete mathematics—or any high-level mathematics—can only improve your understanding of computer science and programming.

Read the classics. This is the same advice I’d give to anyone in any field. Read the classics if they exist. There’s a reason they’re called classics. My first thought would be, “What are the classics?” Mr. Seibel asked every programmer, except Mr. Knuth, if they’d read The Art of Computer Programming, by Donald Knuth. Also, Edsger Dijkstra’s A Discipline of Programming was frequently referenced. These two books (the first is a series) seem like a good place to start. Each programmer also listed books they’d recommend for anyone from novice to expert.

Learn C, not C++. Neither is great, but C is better than C++ simply because it’s smaller. Some programmers defamed C++ while others were ambivalent. Regardless, learning C seems like a good place to start if you’re familiar with programming. Otherwise, I’d suggest Python or Ruby as they protect you from making silly mistakes that C and C++ won’t.

Start with pencil and paper. A bad design in a new or great language is still a bad design. Think through the problem as much as you can. Start by writing it. Then take it to the machine. If you hit a snag, rinse and repeat.

Brainstorm with the hive mind; program in a vacuum. Brainstorming with a few people can turn you on to multiple solutions. No two people think exactly alike. Ambivalence was rampant on eXtreme and paired Programming. Basically they all agreed that XP(eXtreme Programming) and paired programming work well, but they usually benefit only the weaker individual.

Multicore processing is the future of programming. Start wrapping your head around it.

I’m still mulling over their advice. Some of it seems quite controversial, though most of it is quite good. One thing I’m trying to keep in mind is most of these programmers started programming at the dawn of the age. There were small systems, small languages, and small groups of like-minded people. They could keep it all—the architecture, the memory states, the language, etc.—in their heads because it was such a small set to remember. Now, the languages are larger, the machines are faster, the memory is gigantic. They were born at the right time to be demigods.