This is where Adam Spooner writes.

Hacking Safari 5’s Reader

Posted on

If you’re anything like me, you do a lot of reading on the web. Which probably means you care about the quality of the typography you’re staring at: the copy’s color, the page’s background, font choice, leading, etc. You may have even tried Arc90’s Readability bookmarklet or Marco Arment’s Instapaper. Readability is great for getting rid of page clutter and user comments, allowing you to focus on the article’s content. Instapaper does the same thing as a byproduct. It focuses on aggregating articles you want to read later. I use both tools religiously; I can’t recommend them enough.

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:

Safari Reader's default text styles

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:

My altered text styles

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>.

You’re Probably Wrong

Posted on

It’s Wednesday afternoon, and you’re headed to your team’s weekly brainstorming session. You’re equipped with a plethora of ideas, and these ideas aren’t cheap. You spent at least two weeks dwelling on them, trimming the fat, making sure they’re perfect. You enter the conference room early, but you’re not the only one brimming with ideas and chutzpah.

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.

Managing CSS and JS in ExpressionEngine

Posted on

ExpressionEngine, hereafter EE(ExpressionEngine), has great built-in support for managing style sheets and JavaScript. Here’s one simple way to manage your style sheets and JavaScript files with cache-busting and gzip compression using EE(ExpressionEngine)’s templating system.

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.

Piss on the Seat

Posted on

It’s happened to you as often as it’s happened to me. You’re out and about enjoying your day, and then, a grumbling of the bowels. You scan the area and your memory looking for that welcoming sign with little stick figures and the accompanying eight letters R-E-S-T-R-O-O-M. There, in the distance. BINGO! You rush toward it, trying to look as smooth as possible with a fast-and-casual, New-Yorker’s pace. You enter, slightly relieved to find the place deserted. Door number one: disgusting; it looks like someone just shared in your present grief and failed to send it to the waste water treatment plant. Door number two: piss on the seat. Door number three: no toilet paper. Back to door number two.

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.

On Professionalism

Posted on

I spend a lot of time pondering how to live a meaningful life, and lately I’ve been thinking about life at work.

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

Thoughts on Writing Team-Centric CSS

Posted on

I’ve worked on a few different front-end development teams over the past few years, and I’ve seen a range of coding practices—the good, the bad, and the ugly. What follows is a compendium on CSS organization.

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.

Quick Unix Tip: Find Files by Name

Posted on

I frequently need to find files whose name and location I only partly remember. I could use Spotlight, but I find it clunky. Besides, I’m usually at a command prompt which means this tool is only a few keystrokes away:

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\*.

Hospitals are a Test of Patience

Posted on

Last night I spent six hours of my life in a hospital, which has lead me to believe the ultimate reason hospitals exist is to increase our potential for patience. You’re confined to levels upon levels of waiting, each longer than the last. But I’m getting ahead of myself.

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.

Advice from Demigods

Posted on

Last month I read Coders at Work, a collection of Q&A interviews conducted by Peter Seibel with 15 of the top computer scientists of all time. There were some common responses that tied each of these programmers together. I like to think it’s their inadvertent advice for aspiring programmers.

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.