There are a lot of ways for you to lose focus these days. I read sad stories about people wasting hours on Twitter and Facebook in the name of staying connected. Others stop every few minutes to check their feeds for the latest-and-greatest news. We're slowly realizing our multitasking, attention-drained ways are not great for us. There are even applications geared toward helping you focus. You can use an /etc/hosts hack to block sites you frequent, something I've used in the past. But I'd like to take a few minutes to tell you about two surefire ways to become more productive both at work and home.

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.

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:

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

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.

ExpressionEngine, hereafter EE, 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'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'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'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 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.

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.

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.

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.

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

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.

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

Learning new things can be difficult. I’ve already discussed that, so I won’t dive into it again. What I’d like to talk about are a few tools that can help ease the pain as you begin your adventure in learning something new.

The most important tool for learning is the brain. That’s a given. There are, however, a few psychological tools that most of us probably don’t consider when learning that can empower our brains to learn faster and retain information better.

Curiosity is probably the most effective tool you have for learning. A curious mind doesn’t accept a simple answer. It wants to know, not only the what, by the why and the how. Walt Disney is noted for saying, We keep moving forward, opening new doors, and doing new things, because we’re curious and curiosity keeps leading us down new paths.

If curiosity is the wick of the candle, then excitement is the wax that keeps it burning. Excitement for learning a new topic will help you get through the really difficult parts. Trust me, there will be difficult parts. A lack of excitement is why you hated linear algebra—or whatever class you hated.

I quoted Aaron Hillegass’s advice for learning new topics in a previous post. What I didn’t quote was the sentence that preceded his advice, The second trick is to stop thinking about yourself. This claim doesn’t make much sense out of context, so I implore you to read the full quote. Mr. Hillegass is saying that you lose site of the goal—learning something new—when you focus on yourself. I couldn’t agree more, and that’s why I think selflessness is so important when learning something new. It’s not about you; it’s about what you’re learning.

Sleep deprivation has some really nasty side effects, although it can be used to cure depression. There is, however, a direct correlation between getting more sleep and better grades in school. That’s why sleep is the most important physiological tool at your disposal for learning.

A healthy diet has been known to result in better scores on standardized tests, greater attention spans, and less hyperactivity. I won’t go into any more detail on this. Just remember that breakfast is the most important meal of the day.

If you would know how a man treats his wife and his children, see how he treats his books, has long been one of my favorite Emerson quotes. Not just because I’m meticulous with my books but also because I love my wife. That said, it brings me physical pain to watch someone treat a book maliciously—tearing its cover, dog-earing its pages, tossing it to and fro with no concern for its well being. Okay, it doesn’t bring me physical pain, and I’m not overly concerned with how others treat their physical possessions. I am, however, a firm believer in treating books with some respect. They’ll last longer, and you’ll, therefore, be able to reference them for years to come.

Post-It flags are a great investment for more than just keeping books in pristine condition. They allow you to mark off certain sections for quick look up. It’s a better approach than dog-earing a page because you can pinpoint the exact location of what you’re marking, jot a small note on the flag, and never put the book in harm’s way.

Another extremely useful tool is a book stand. I read a lot of books about programming languages, and every author strongly suggests—as do I—that you actually implement their code. This can be quite cumbersome with a book that is prone to close when left unattended. A book stand holds the book at a good angle for reading and keeps your pages held open. There are plenty of options to choose from, ranging from inexpensive to ridiculously overpriced. I use the Easi-Reader Bookstand. It’s inexpensive, folds up for easy storage, and doesn’t get in the way of page turns. It Just Works™.

The following tools are very specific for the material I usually ingest, namely programming languages and general technology books. I like to keep notes, mark my progress, and rate what I read at Readernaut. Readernaut is the resource for bookworms. Give it a try. I’m sure you’ll enjoy it as much as I do.

Every Mac ships with a great little application called Dictionary. Chances are you don’t have the English language completely memorized, and while contextual clues are a great way to guess a word’s meaning, it’s better to know for sure.

This is by no means an exhaustive list. There are hundreds of tools that can aid you in learning. This is just a list of tools that I find extremely useful. There are a lot of different learning styles. Be pragmatic in your approach. You might find the way you were taught in school wasn’t the best fit for your brain. Learn well and enjoy.

I am currently learning how to program in Objective-C and Cocoa, and as any Mac developer would tell you, the best book to start with is Aaron Hillegass’s Cocoa Programming for Mac OS X.

The first chapter ends with some advice on learning that should be emblazoned at the beginning of all books and the entryway to every school,

When learning something new, many students will think, ‘Damn, this is hard for me. I wonder if I am stupid.’ Because stupidity is such an unthinkably terrible thing in our culture, the students will then spend hours constructing arguments that explain why they are intelligent yet are having difficulties. The moment you start down this path, you have lost your focus.

According to a recent study by Professor Timothy Salthouse, our brain power begins to lessen at age 27, and our ability to remember starts dwindling at age 37. I just turned 27 this year, and I feel like I can learn new subjects quickly. So I must be to the right of the bell curve.

Regardless of where you fall on Professor Salthouse’s bell curve, learning new things can be just plain difficult.

I urge you to burn Mr. Hillegass’s advice into your memory—I find sticky notes to be helpful. Some things are hard to learn. You’re not stupid. If you get stuck, stop, break the problem down into simpler steps, and try again. Still too hard? Rinse and repeat. This is when patience really pays off.

As technology progresses at a rate faster than Moore’s Law, we, as a species, are trying to keep up. Those passionate about learning new technologies will be tempted to cut corners, and that’s what I’d like to address.

In the late 1940s Percy Spencer accidentally invented the first microwave oven. This was one of the first technologies to forever warp our idea of time needed until consumption. It’s true the wheel, the automobile, the airplane, et cetera are all inventions that help us get what we want faster, but the microwave is something that most of us can relate to. It’s a device that gets food from the shelf to our mouths in the shortest amount of time. I say this has warped the idea of time needed until consumption because the same meal that used to take about thirty minutes can now be ready in about three.

There are numerous health concerns associated with microwavable meals. They’re usually saturated in sodium, partially hydrogenated vegetable oils, and food additives that wreak havoc on our bodies.

Preparing a warm, healthy meal the old-fashioned way—with a conventional oven and range—can take thirty minutes or more. We have to plan the meal, pick out the ingredients, think about each spice and its effect on the taste, and orchestrate it all by dinner time. Odds are you won’t get this right on the first try. Cooking the old-fashioned way takes practice. It takes patience. It requires a few subpar meals before getting it just right. But the benefits of a home-cooked meal are priceless. You have the satisfaction of knowing what you’re eating, the therapeutic side effects from creating something, and all the joys associated with a healthy diet.

The principle of least effort, herein referred to as PLE, postulates that animals, people, even well designed machines will naturally choose the path of least resistance or effort. PLE perfectly annunciates the zeitgeist in which we live. We’re a microwave society dependent on quick fixes, fast information, and doing things the easy way. Much like the microwave, this fast path to consumption isn’t always healthy.

I’m not arguing that the PLE is bad or wrong. I think it’s utterly dependent for the evolution of our species. I’m arguing that there is a time and a place for adhering to the principle and a time and place for using a conventional oven, so to speak.

I like real world examples, so here’s such an example of the PLE. Say you need to know what a ligature in typography is because you overheard someone talking about ligatures the night before at dinner and it piqued your curiosity. So, you ask a friend who’s really into typography. Your friend tells you it’s just the combination of two or more graphemes into one glyph. You smile, nod, and walk away. You’re now equipped with the basic definition of a typographic ligature. You may still have no clue what a grapheme or glyph is, but you’re okay with that limited understanding. You’ve successfully applied the principle of least effort. This is neither bad nor wrong. Alternatively, you could have purchased a book on typography and read in detail about the history of ligatures, why they’re used, etc. This would have, possibly, been the path of greatest effort, and you’d be fully equipped with not only the definition of a typographic ligature but the understanding of why they’re used, when they were first used, and what graphemes and glyphs are. Do you really need to know everything about ligatures? Probably not. So you may be asking, “What’s the benefit of having that information, and more importantly, what’s your point?”

I’m arguing that the principle of least effort is causing for a society in which knowing the bare minimum is acceptable and truly understanding a topic is going the way of the buffalo. There’s nothing wrong with knowing the bare minimum about a certain topic, but knowing more than enough has positive side effects, namely, it leads to understanding and clarity. Do you need to know assembly language in order program a for loop? Not at all. Can knowing assembly language clarify what is happening in your for loop? Definitely.

Taking the path of greatest effort is not for the impatient. It takes time, planning, and a lot of reading and even more time practicing. It’s the conventional oven method for learning in a microwave oven society.

Keep this in mind when you start learning a new topic. Don’t feed the temptation to cut corners by reading quick tutorials on the internet. Rather, plan your time wisely: read a lot of books and spend twice that amount of time practicing what you read.

When asked why he teaches, Milton Glaser responded,

Fundamentally I teach because it makes me feel good. It’s helped me certainly clarify my own objectives. There’s nothing more exciting than seeing someone whose life has been affected in a positive way by something you’ve said. There’s nothing more exciting than seeing somebody change from a sort of condition of inertness or inattentiveness to a mind that begins to inquire about meaning. I think if you don’t do something to project into the future that way the possibility for total self absorption and narcism becomes very much greater.

This quote was taken from a short film on the Hillman Curtis Web Site. Hillman Curtis has a plethora of great interviews in his Artist Series. Each short runs around eight or nine minutes. Take some time and watch a few; the collective wisdom of these prolific designers is well worth your time.

Daniel Jalkut and Manton Reece co-host a podcast called Core Intuition where they hold casual conversations about Mac Development and other ephemera. It’s a terrific podcast, and I highly recommend it if you enjoy podcasts, Apple, and the indie Mac developer community.

A few episodes ago, they started answering questions from users. This past episode, Episode 15: The Extra Long Episode, Mr. Reece answered a question about getting started. And I thought I should chime in since this journal is all about getting started. I mean, what better way to start a journal about starting new things than a post about getting started!?

The question posed to Mr. Jalkut and Mr. Reece was,

How do you get or stay motivated to work on your personal projects? Do you just wait for the mood to strike before putting more hours into, say, Wii Transfer? Or do you have a fixed work schedule? Or do you have something in between?

Mr. Reece paraphrases a quote—around 39:32 in the podcast—from the inimitable Ollie Johnston about thinking, thinking, thinking and then doing, doing, doing. I’m not sure if he was referring to his quote on splitting time between planning and animating or a more popular quote from his animating cohort, Frank Thomas, Observe Everything. Communicate Well. Draw, Draw, Draw. I like to think he was referring to the latter.

I like numbers, and I like words. I like to think that people appreciate both in conjunction, so let’s take a deeper, more mathematical, look at Mr. Thomas’s excellent advice. The quote is composed of seven words: five verbs, one pronoun, and one adverb. To reiterate, there are five verbs, you know, action words. That’s a little over seventy percent of the sentence focused on doing something, and sixty percent of that is in actually implementing the final product, drawing. It seems Mr. Thomas was an advocate for practicing your craft, for actually doing whatever it is that you do, for getting started.

A lot of people seem to have a fear of getting started. Maybe it’s a fear of failure brought on by perfectionism. I don’t know, but I see it all the time. People have great ideas, but they’re afraid of getting started. I have a different thought: maybe, just maybe, they’re not really all that serious about it. Maybe they’re just lazy. It really boils down to what Gary Vaynerchuk talked about at Web 2.0 Expo in New York: patience and passion. Mr. Vaynerchuk has a few priceless quotes in his talk. The first relates to passion, There is [sic] way too many people in this room doing stuff they hate. Please stop doing that. The second relates to getting started by working in your spare time, Everybody has time. Stop watching fucking Lost.

Being passionate about something is priceless. There is no barrier to entry for someone who is passionate. Mr. Vaynerchuk is dead on, stop doing what you hate and stop wasting your time. The great thing about this is that one breeds the other. You’ll sacrifice all the free time in the world when you’re passionate about something. The barrier to entry dissolves in the face of passion.

So, how would I answer the question posed to Mr. Jalkut and Mr. Reece? Be passionate. You’ll do amazing things when you’re passionate about them. Getting started won’t be a problem at all.

I’ll leave you with this: Use your free time wisely. You may have to forfeit spending time with friends. You may lose a lot of sleep. You may have to miss an episode or two of Lost. I promise it’ll be well worth the sacrifice when your product comes to fruition. So, why are you wasting time reading this journal entry? Get started, now.