Tech Book Face Off: Prioritizing Web Usability Vs. Don't Make Me Think

According to Netcraft.com, there are over 185 million active websites using over 630 million hostnames on the internet as of March 2013. That is a lot of websites, and I would be willing to bet that the vast majority of them are poorly designed and not very user friendly. I've definitely seen my fair share of them. When I find especially well designed sites, they can be a pleasure to use. Some of them are truly entertaining while others have such an elegant user interface that you hardly even notice the complexity they contain. A well designed site will take no more than seconds to figure out, with everything you would like to do on the site being intuitively obvious. You would think such great designs would be more common, seeing as they are in plain sight for every web user to see, but alas, it would seem that a lot of web designers out there are not paying very close attention. It's not too difficult to make some big improvements in your web design, and there are a number of books out there that can point out the obvious, some better than others. Here are two:

VS.

Prioritizing Web Usability

Dr. Jakob Nielsen is the guru of web usability. He has been studying, writing, and advocating for better web usability for decades, and his advice is generally accepted as truth when it comes to improving websites. If he is anything, he is thorough. At 432 pages, Prioritizing Web Usability is essentially the reference on website user interface design. I actually made the mistake of also reading his Designing Web Usability as well, but you shouldn't. It's another 432 page reference (is there some meaning in 432?), only from 7 years earlier, and it's pretty much obsolete.

Dr. Nielsen does cover a lot of ground, including a very interesting review of how the web has improved since Designing Web Usability, but I couldn't help but feel like his explanations were excessively drawn out. By the time I reached the chapter on "Writing for the Web" that contained the advice of cutting down the prose on websites to the bare necessities, I was thinking a fair amount of cutting might have improved the readability of this book. The authors did try to make the argument that the web required succinct writing while print did not because it was the nature of the medium. I was not convinced. Then I read Don't Make Me Think, with the advice to cut half the content and then cut half of what's left, and I thought even more that there's no reason that shouldn't apply to print as well. Cut anything that doesn't directly add to the reader's understanding of what you are saying. They will thank you for it!

As it stands, I ended up only reading the prose and skipping the picture captions. This method probably cut about a third of the length from the book, and a fair amount of the redundancy. After finishing, I figured I could have gotten just as much out of it by only reading the captions and skimming the prose for any other keen insights. Don't misunderstand me, this book contains a wealth of knowledge on how to build a better website, and it's all clearly explained with good examples. The problem is that the key advice is watered down with a lot of extra points and wordy arguments to back up the reasoning. A book that was half the size with more focused advice would have ended up being much stronger, as we will soon see.

Don't Make Me Think

At 216 pages, Steve Krug's book is actually exactly half the size of Prioritizing Web Usability. Now I'm wondering if that was a coincidence. Steve's writing is clear, concise, and entertaining. The layout of the book is excellent, with great examples of websites that are trimmed to show only the point that he's trying to get across. It's so well done that it will only take you a few hours to read through it, and it will open your mind. Once you are aware of the issues, you'll see them in every website you visit, good or bad. That awareness alone will make you a better designer.

Even my wife read through this book and enjoyed it, and she's not a technical person. Steve shows you what you need to know, and he does it in a way that is accessible to everyone. That is the sign of a great teacher, and a great book. My wife was so impressed with it that she went on and read Rocket Surgery Made Easy, which goes in depth on usability testing. She liked it just as much as Don't Make Me Think. I haven't read it yet, but I'm planning to. I don't have much else to say, except, you should read Don't Make Me Think. Get the print version. The layout and full color content of the book lends itself much better to print. You can also check out Steve's website for more great advice.

A Little Knowledge Is A Dangerous Thing

If I had to pick one idea from these books that could really make you a better web designer, it's that your intuitions about good web design are wrong. If you are designing websites, your technical expertise will get in the way of usability because what is obvious to you is not obvious to the majority of your users. On top of that, you know too much about your website, and you'll naturally organize it in a way that makes sense to you. But your users aren't coming to your website to learn everything you know. They're either coming to get something done, or to learn what they need to know. To help your users accomplish their goals, your site needs to be simple, clear, and obvious. These books can help, but the best way to achieve that is to get to know your users. You're designing for them, are you not?

So what to read?

If you haven't already decided, let me give one more perspective. My wife also tried reading Designing Web Usability. She couldn't get past the first 100 pages, and she was constantly asking me questions about what Dr. Nielsen was talking about, since she's a non-technical person. That experience has turned her off to reading Prioritizing Web Usability. I think she'll get around to it at some point, but she keeps putting it off. With Krug's books she could read straight through, understanding everything. Her recommendation is that everyone, whether they are design engineers at a huge corporation or Johnny down the street setting up a personal website, can gain a lot from reading Steve Krug's books. If you are a technical person with lots of time on your hands, or if you are searching for encyclopedic knowledge of web usability, then reading Nielson's book would get you there.

The Evolution of a Software Program

Analogies, anecdotes, and parables are all incredibly powerful literary devices that can be used to deepen your understanding of a complex topic and increase your ability to recall more details about it when you need to. When exposed to a new idea, your brain needs something for the new idea to hold onto, otherwise it takes a lot of repetition to lodge it into your long term memory. These devices work by relating the new idea to something you already know so that you can make associations between this weird new thing that you're trying to plant in your mind and something familiar that already has strong roots in your memory. The stronger the connections, the faster you can understand the new idea, and the longer you're going to remember it.

Beyond the mental connections that they make, analogies, anecdotes, and parables all tell stories about what the writer is trying to convey to the reader, instead of droning on with technical prose that will most likely put the reader to sleep. Stories show you what the writer is conveying rather than tell you what you should know. It's a far more interesting way to learn something, and you are much more likely to stay engaged and actually absorb the ideas when you're interested in what you're reading. I felt like I got so much out of The Pragmatic Programmer, because of the authors' use of stories to make their points.

I especially like analogies for enhancing understanding because they are so easy to find in everyday objects and activities. Both of the books I talked about last week made analogies between software development and other endeavors. Andy and Dave likened it to gardening in The Pragmatic Programmer, and Steve related it to building construction in Code Complete 2. Other analogies abound; just do a Google search for what software development is like for a little light reading. I think the variety and sheer volume of associations is excellent. Anything that helps you make new insights and become a better programmer is a plus in my book.

One way to think about software development that I would like to explore is that it is like evolution. Much has been written about software evolution, as in how a software system evolves over time, or the evolutionary model of software development. Those ideas are definitely part of what I'm talking about, but I want to go further and compare software development directly with the theory of evolution. Let's start with some simple associations and see how far we can stretch this analogy.

In the beginning, the theory goes, there was the primordial soup. In it were various organic compounds that had resulted from chemical reactions in the atmosphere. Over time these compounds reacted and combined into more complex polymers and amino acids, the building blocks of life. In the same way, the building blocks of a program are the programming language, libraries, and frameworks that are used to create it. You could go really basic with the building blocks and think of them as the assembly language instructions, or even the machine code that makes up a program, but then we would be describing the evolution of software development in general from machine code to assembly language to higher level languages and abstractions. I think that's a valid association, but I want to look at the evolution of an individual program written in a particular language. It could be any language, but the language is not what's evolving.

Every program has to start somewhere. A simple little proof-of-concept program that takes some input and produces some output is like a single-celled organism, or bacterium, that consumes fuel and produces waste. Okay, maybe 'waste' isn't the best association for a program's output. How about by-product? No, that's not much better. The point is that our little bacterium takes inputs from its environment and converts them in some way to produce something that it emits back into its environment - just like a barely useful initial program does.

From this basic program, the designer can add code to increase its capabilities, either by added features or improving performance. These improvements are the mutations in the program's evolution. Some mutations will be successful and will be kept, saved in the historic record of the version control system. You are using version control, right? Other mutations won't work so well, and will be discarded as cancelled features or mutated further into bug fixes.

As the program grows and evolves, it will become increasingly complex and interconnected, with newer systems built on top of older systems, just like the human brain is built up from older nervous systems, starting with the spinal cord and brain stem, then adding the limbic system, cerebellum, and finally, the cerebrum. Often times code loses its usefulness, but it remains in the program, Or it becomes redundant, but it isn't optimized out. We see similar examples in our own evolutionary history with many redundant parts, and other parts that we can't quite explain.

The compiled code of a program is similar to an organism's DNA. It can be replicated easily, and the compiled code is an exact description of how to create an instance of a running program on a computer. The code can be copied from one computer to another through various methods, and there we have the equivalent of reproduction. Each instance of a running program can vary based on its configuration and unique inputs, which could equate to variations in an organism's DNA and the environment it grows up in.

Evolutionary history also goes through cycles of dramatic explosions of mutations and rapid evolutionary progress followed by periods of relative calm and stability that end with mass extinctions. Software development cycles follow a similar pattern with periods marked by rapid evolution of the code base followed by slower periods when programmers take a rest and hopefully go on vacation. Mass extinctions can be thought of as happening at the release of a new software version when it replaces much of the installed base of the old version, sometimes more effectively and sometimes less.

To really be a useful analogy, evolution should lead us to new insights about software development, and I think it does. Starting with a small proof-of-concept program and then building on it, growing it into something more useful and complex with each iteration, is a highly effective way to develop software. Having a working system at every step of development is extremely beneficial. It may seem like building on top of working systems results in a convoluted mess of software layers, but these systems usually have a deeper elegance that takes study and time to appreciate. And of course, these systems have the unmistakable advantage of actually working. How many times have project teams attempted to build monolithic monstrosities only to watch as they collapse under their own weight? Software that evolves incrementally from one working version to the next has a much better chance of succeeding in the long run.

Tech Book Face Off: The Pragmatic Programmer Vs. Code Complete

Once you have received your degree, accepted your first job, and started practicing software engineering, you'll start to realize that there's a lot they don't teach you in college. Many professors tend to focus on the theoretical aspects of computer science and pay little attention to the practical aspects of software engineering. They may expect you to pick up the skills you'll use to practice your craft while you're on the job, or they may not even be aware of this side of software engineering. How do we learn what we need to know in the real world of designing software and writing code? I mean the everyday stuff: writing specs, reading code, adding features, refactoring, testing, reviewing, etc. There are actually quite a few good books that can give you a head start and keep you from making plenty of amateur mistakes. Here are a couple of the most popular classics:

VS.

Even if you've been programming for decades, if you haven't read anything about the hands-on mechanics of software engineering, these books can give you expert advice on how to improve your programming practices. Alright, let's see what each of these books has to offer.

The Pragmatic Programmer: From Journeyman To Master

I thoroughly enjoyed reading this book. Andrew Hunt and David Thomas have a knack for packaging up programming wisdom into short, entertaining analogies, anecdotes, and parables that bring their points home in a memorable way. Even the titles of their chapters allow you to quickly recall the advice contained in each one. After reading through it once, you can just skim through the chapter titles to refresh your memory on their best programming practices. Here are some of my favorites:

Stone Soup and Boiled Frogs: Have you ever been on a project where you had a great idea for how to do something, but it would take too much effort to get approval for it if you asked? Try implementing a small part of the idea and present it to the team. Comment about how it would be so much better if it had this or that added to make it more robust or polished or whatever. Over time you may be able to get your idea in piecemeal, and the whole team will feel like they shared in the success, because they did. It's a win-win situation. On the other hand, don't let small changes to a project build up in a negative way, or you just might fall victim to feature creep like a frog in water being slowly heated to a boil.

Tracer Bullets: This is a great analogy for the design practice of getting a basic version working early and then iterating rapidly to improve it. They go through many of the advantages of this approach and some of the classic design mistakes that can be avoided by using it. It's an incredibly useful way to do design that every software engineer should know.

Programming by Coincidence: What happens when you start coding on a project without thinking? You plow headlong into your editor and bang out line after line of code. Then you test it out, fix a few obvious mistakes, and keep going. Eventually you start getting bugs that look a little weirder so you change code at random until the program appears to be working at a superficial level. In the end you'll have a mess of code that doesn't have a prayer of passing rigorous testing or actual customer use. This is programming by coincidence, and Andy and Dave go into it in much more entertaining detail, along with how to avoid it.

There are so many more gems just like these. I couldn't put the book down, and it was over before I knew it. I finished it wanting much more, and it totally changed the way I approach software engineering. In my mind, that's the perfect combination for a book like this. You should definitely read it. You'll get through it in a few evenings on the couch, and it will make you a better programmer. Highly recommended!

Code Complete 2

Maybe I was biased (or spoiled) from reading The Pragmatic Programmer first, but I just couldn't get into Code Complete 2. I had read many glowing recommendations for this book, and I know it is highly regarded in the software industry. But compared to Andy and Dave, Steve McConnell was kind of dry and long-winded. Now don't get me wrong, he filled this book to the brim with great coding advice, and it's almost four times longer than The Pragmatic Programmer so he covers an amazing amount of ground in 35 chapters. He goes all the way from software requirements to class organization to control structure to code layout to personal character. He covers everything having to do with code construction, hence the title.

There were certainly good things about Code Complete 2. The coding horror sections were always entertaining. If you've been reading old code - other people's and your own - for any length of time, you will definitely notice that many of the coding horror examples can conceivably happen in real code. They are pertinent examples of code gone wrong, along with explanations of why the conventions used in the bad code are confusing, error prone, and generally not a good idea.

If Code Complete 2 is anything, it's comprehensive. For the novice programmer, this is a great thing. Having such an exhaustive amalgamation of programming knowledge in one book can be a great introduction to good programming practices for the new initiate to the software industry. More experienced programmers may like the book as a reference or as a starting point for establishing coding standards on their projects, but as a readable work on the craft of coding, I found it somewhat lacking.

I really wanted to like this book. Everything I read about it recommended it as the definitive work on the subject, and it definitely is. But that doesn't make it an engaging read. It had no focus. Steve alluded to that fact in the beginning of the book where he claimed that when he went looking for the same information in the literature, he could not find it all in one place, that it was dispersed among a multitude of books, papers, and articles. His goal was to collect all that knowledge for future programmers. I believe he achieved that goal, but not in an especially memorable way. I can't immediately recall hardly anything that I read in Code Complete 2, barring a few code layout guidelines. I do distinctly remember that while reading it, I was constantly feeling like I had heard most of his advice before. Maybe that lack of new insights is what really kept me from getting into this book.

So Which One Should You Read?

At this point you may think the answer is pretty cut and dried - The Pragmatic Programmer, right? Not so fast. I still think Code Complete 2 is worth reading, just not all at once. You have to pace yourself. Don't try to read it all in a week or two. Those 35 chapters can be broken up into easily digestible snippets that you can read over the course of a few months.

If you do read them both, I would definitely recommend reading The Pragmatic Programmer first. Andy and Dave do a much better job of showing you how to become a better programmer rather than telling you, with clever anecdotes like the law of Demeter, the theory of broken windows, and "select" isn't broken. You are definitely going to remember a lot of their advice. Of course, there is a lot of overlap between the two books. With Code Complete 2 covering topics in more detail and adding more topics, it's a good in-depth reference following The Pragmatic Programmer.

Since Code Complete 2 is basically a super-set of The Pragmatic Programmer, I wonder if reading Clean Code: A Handbook of Agile Software Craftsmanship and Refactoring: Improving the Design of Existing Code would cover most of what Code Complete 2 does in about the same amount of space, but in a more engaging way. I'm not sure since I haven't read them, yet, but they are on my list. At any rate, The Pragmatic Programmer will pull you in like you wouldn't believe a programming book could. You may not be able to put it down. Go read it!

Growing Up With Technology

The other day my wife told me that my son can now turn on the computer, take a DVD out of its case, put it in the DVD drive, and make the right menu selections with the mouse to start a movie. He's two. Granted, sometimes he ends up watching Tinker Bell in French, but hey, maybe he'll pick up a second language. I find it amazing that he can manipulate a mouse that well when he can hardly get a spoon full of macaroni in his mouth without getting some up his nose and the rest in his lap.

This breakthrough got me thinking about how people always say kids can learn new technologies so much faster than the rest of us. Then I started thinking that it's not so much that young kids can learn faster, as it's that they don't have a huge catalog of old interfaces stored in their heads that they have to overcome when learning a new one.

Think about all of the devices you've used throughout your lifetime. I'm young enough that people have thought that I don't know what a record is, but I definitely remember listening to my family's record player when I was growing up. I can still recall the distinct crackling sound that the stylus made while picking up all of the dust and imperfections on the record's surface. I remember how the turntable worked, how the records needed to be cleaned, and how much space they took up in our living room cabinets. That's one of the first devices I can remember. Here's another.

My dad had a hand-wound 8mm camcorder that would take short video clips. He'd have to send the film in to be developed, and then he would splice the clips together into a movie. Every once in a while he would bring out the video projector, and we would all sit around and watch the home movies while he narrated. There was no sound recorded with the movies, but my dad did a great job of making it interesting on his own. I always loved hearing his stories about what was happening on the screen, and I still remember the whir of the fan and the clack-clack-clack that the film made when the spool ran out. Sometimes he would bring out the slide projector and narrate while he flipped through those as well. The experience was fairly similar, even down to the whir of the fan and the clacking of the carousel as it changed the slides. Both of these projectors had their own interfaces as well.

That's pretty much where I picked up in the stream of technology related to movies and music. There are many other technology categories, from communication to transportation to energy, but let's keep it simple and focus on forms of media. I just missed ATRAC, and I've lived through cassette tapes, Betamax, VHS, CDs, DVDs, and now MP3s, Blu-rays, and streaming video. Every one of these formats introduced new features that changed the interfaces on the devices that played them, and the device interfaces have continued to evolve on their own as well. Now Blu-ray players have their own GUIs and internet connectivity, and almost any device with a screen smaller than 30 inches is a touch screen - or will be soon.

My kids will never have known about most of those older devices. They'll never have to learn their interfaces. They're starting with the GUIs and touchscreens, and that's all they know. I know it's becoming passé to list all of the things that young people never knew existed, but what about things they stop using before they're able to remember? My son tries to touch our computer screen because he thinks it should work like an iPod or a Kindle. He recognizes that it's a similar screen and figures it should be touchable, too. He understands the mouse because he sees us using it, but touching is much more intuitive to him. It's quite possible that our main computer could have a touchscreen in the next few years, and if he's still young enough, he'll never remember it not being that way. From his perspective, every screen would be a touchscreen, and that's just the way things always were.

Here's another example. I don't plan on getting rid of our movie collection in the next few years, but theoretically I could. Netflix, YouTube, Hulu, Amazon, and massive hard drives are certainly adequate replacements, and if I did, my son wouldn't remember having to put a disc in a player to watch a movie. They would always be available to watch anytime on any device. If you didn't have to forget the old way of watching movies and learn yet another new interface, you'd probably pick it up pretty fast, too. It's the constant forgetting that gets hard, or maybe exhausting is a better word.

Now that interfaces are almost entirely software, they are evolving and proliferating faster than ever. That means we have to forget the old to learn the new at an ever faster pace. Our kids are growing up in this environment. They are immersed in it, so they are much more comfortable with it than we are. I wonder if they will reach a point in their lives where they suffer from new interface exhaustion, or if that wouldn't happen to them because their brains are wired differently from growing up in a much more interactive, visually immersive world.

Our children are certainly growing up in an environment that has incredible learning tools for quickly developing a markedly different skill set than we did growing up. The right video games, computer applications, and high-tech toys (e.g. Lego MINDSTORMS) can greatly improve creative problem solving, logical reasoning, analytical thinking, and abstract modeling skills. Researchers have even found that people that play video games have better surgical skills. Of course, you should be selective about what type of games your kids play. World of Goo is an excellent game for learning about physics in a whimsical world for children. Call of Duty...not so much.

To succeed with these games and apps, you have to form a model of the world in your head. You need to learn the physical rules that govern what you can and can't do in the world, and if it's a 3D world, you'll also be creating a mental map of the game world so you can move through it effectively. Often times this mental model is not based in our physical universe at all. There's a lot of abstract thinking and creative problem solving going on there, and kids are learning without even realizing it because it's fun. We should definitely be encouraging that kind of learning because they are much more likely to retain the knowledge if they are so engaged in the process.

That's a powerful skill set for them to have for the creative jobs of the future. When it comes time to design the next advanced computing device or energy technology or medical delivery system, these kids' minds will be well prepared for the task. They'll be able to dream up novel solutions to these hard problems because they're wired to think in entirely different ways than we are. I'm looking forward to seeing what they come up with.

Tech Book Face-Off: Design Patterns vs Object-Oriented Design Heuristics

When learning something new, try reading books on the topic in pairs. Learning about something this way has a number of advantages, and you can consciously pick the books depending on what you're trying to achieve. Sometimes you're trying to learn a new programming language quickly. Sometimes you want to learn about different development processes, like agile vs. waterfall, for instance. Sometimes you just want to learn some new design techniques and happen to pick a couple of great books that compliment each other nicely. That would be the case with these two books:

VS.

The first, of course, is the famous Gang of Four book on design patterns. Almost every programmer has heard of it, and it is considered the definitive work on software patterns. The second is less well known, but provides great insights and is quite well-written and easy to read. Each of them stands on its own as a great book of design knowledge, but together they can really improve the way you approach software design. Let's take a look at each one and then see how they fit together.

Design Patterns: Elements of Reusable Object-Oriented Software

The basic premise of this book is that software design has a number of recurring patterns that can be systematically described and cataloged. Once you know the names of the patterns, you can easily discuss them without having to describe the design in detail, and other software engineers will know what you're talking about. Since these patterns come up again and again, there is no need to redesign them from scratch. The implementations given in the book can be applied to new designs to quickly solve common problems with known solutions. Convenient!

The bulk of the book is the catalog of 23 design patterns. The authors go through every aspect of each pattern from why you would use it, how to apply it, what are the advantages and disadvantages of it, and a concise example of it. It's all very methodical, but I really got into it. I was amazed at how many patterns applied to the code base I'm working on. Factory Method, Adapter, Facade, Command, and the infamous Singleton were all present, and learning about them greatly improved my understanding of the code I was working on. I could categorize entire sections of code based on the pattern used, and as a result, I had a much more organized picture of the code in my head.

I could also see where things could be improved. After reorganizing one set of classes into the Strategy pattern, I was able to easily extend it with a ton of new functionality that was just a bunch of additional strategies. The next thing I want to tackle is the state machine that currently manages the overall execution of the program. Right now it's a giant switch statement that's just crying out to be refactored into the State pattern. It would be so much more maintainable and understandable. I love books that are immediately applicable to what I'm working on.

Object-Oriented Design Heuristics

This book addresses object-oriented design from a different angle. Instead of categorizing design problems and solutions into a set of patterns, it lays out a set of heuristics to guide you while making  the nitty-gritty choices that go into designing software. Since they're more what you'd call guidelines than actual rules, the heuristics can sometimes be contradictory, and intentionally so. Through the heuristics, Riel brings out the tension inherent in all design trade-offs in software engineering.

Bringing this tension to the forefront really helps crystallize your understanding of the reasoning behind design choices, and why you would make one choice in this situation, but take the opposite route if the requirements changed slightly. There are rarely definitive answers, only shades of gray. Sometimes it's better to encapsulate behavior into lower level classes. Other times doing so would make things messier because the necessary data is spread out among numerous classes. In that case it might be better to move that behavior up a level and just access the data from the lower-level classes.

I'm making decisions like these constantly while programming, and having a well-thought out set of heuristics is invaluable. I can see much more clearly what the design trade-offs are, and my designs are much cleaner and more elegant as a result. I certainly have a long way to go on improving as a programmer, but this book has helped me suck less in the last year.

Putting Them Together

How do these books complement each other? They attack software design from different angles. Design Patterns gives you a collection of patterns to choose from when you're trying to organize a program at a higher level, either when doing the architectural design, or more likely when refactoring after you actually know how the program works and fits together. On the other hand, Object-Oriented Design Heuristics gives you a collection of heuristics to use when deciding where to put this data or that function, and is incredibly useful while actually writing code.

Patterns help organize in larger chunks while heuristics help refine and massage the design at a finer level of detail. Their interplay is similar to how a house is constructed. The patterns would be like the foundation and frame of the house. They provide its structure and support, and the rest of the house hangs on that structure. The heuristics are like the fit and finish of the house. The shelving, trim, paint, and floor coverings that give the house its look and feel. They're both necessary, and when they're both done right, you have a beautiful, functional home.

So how do you build a better house? Reading about these patterns and heuristics isn't enough. You have to put them into practice to really understand them and see how they work. The examples in the book are nice and clean and well thought out, but they likely won't transfer exactly into your own designs. Don't be afraid to experiment and see how they can be implemented in your own projects. At the same time, don't try to force them into a design that doesn't really need it. Patterns especially can be overused and abused if you're not careful, so don't over-engineer. Simpler is almost always better. If a particular pattern doesn't provide the benefits necessary to outweigh its complexity, use a simpler pattern or none at all. How will you know? The only way to find out is to give it a try.

Learning How to Learn (Part 3): Hitting a Wall

Let's say you have a great love of learning. You have a passion for learning new things and make the time to pursue that passion. You know how you learn best, and it works quite well for you. Learning is exciting and satisfying. And then you hit a wall. What do you do now?

This very thing happened to me after I finished my Master's Degree and started working full time. Although I did not realize it was happening at the time, I let my love of learning languish for years after finishing college. A number of factors came into play during those years to distract me from learning. That is not to say that they were bad things. Some of them were wonderful life experiences, as you will see. In looking back, though, I can see there were times when I could have and should have been more thoughtful of my professional development. Here are the main reasons why my learning stagnated. Maybe some of them will be familiar to you, as I am sure many of us tend to forget about learning through the years.

1. Burnout

Towards the end of my Master's Degree, I just wanted college to be over. Don't get me wrong, I loved college. It was the most fun I had ever had in my life, but after six years, it was wearing me down. It wasn't just the six years of college, though. It was the 18 years of school. I had worked extremely hard through high school and college, including holding a part-time job as an intern at the company that I would later work for full-time, and I needed a break. 

After studying solidly for that long, the last thing I wanted to do was pick up another textbook, but I probably shouldn't have taken such a long break. A few months would have been enough time to recover, and then I could have picked up a software design book or discovered and started reading some of the excellent blogs that were popping up at that time - something to stay current and keep my mind nimble. I picked up something else instead.

2. Distractions

I had build up quite a backlog of video games that I had bought but hadn't played during college. After my freshman year, I didn't have much time to play anymore, but I still accumulated plenty of games that I figured I would get to later. Post-college was the time to relax and catch up on some great games. I probably went a bit overboard, not leaving time for much else in the evenings. That would include learning something new, like a new programming language.

3. Family

I met a wonderful woman in college, and we got married and started a family. I now have two incredible young children that bring me joy every day of my life. Obviously, I don't have any misgivings about the choice to start a family. I list it here because a family definitely takes time, and you should spend as much time as you can with your family because that time is short. 

So how do you make time for learning when you have a family? I've found that once the kids are in bed, there's enough time in the evening to pursue my own interests. It just takes more discipline and dedication. If the motivation is there, the energy to keep learning will be there. And once the kids are older, we can learn together. Teaching is a great way to learn. I already have plenty of fun projects in mind.

4. Home Ownership

While I have no regrets in starting a family, I cannot say the same thing about home ownership. Owning a home is a tremendous time sink. It took us years to get settled in our new house to the point where it no longer takes so much of our time, but yard maintenance is still a lot of work. If I had to pick one thing on this list that I would have done differently, I would seriously consider living in an apartment or condo instead of a house. The extra space of a house is nice, especially with children, but I'm not convinced that the trade-off is worth it. (My wife agrees.)

5. Career

This one takes a little explaining. It would seem that a career shouldn't be an impediment to learning and professional development. An engineering career should be a vehicle for learning plenty of new things. While it is true that I learned a great deal while working as a test engineer and IC designer, I wasn't learning anything new on my own. That's important. If you're not learning outside of your career, it's very easy to become complacent. To let the tide take hold of you, and just drift along. The pursuit of knowledge is an active endeavor, and I should have taken more control of what I was learning on my own time. I could have been picking up new programming languages, or understanding current development best practices, or paying more attention to where the industry was headed. Instead, I was going with the flow.

Getting Beyond the Wall

So what changed? My job disappeared. My previous company decided to close down the design center where I was located. I was given an offer to relocate overseas, but it was a difficult decision. My coworkers and I did know at some level that that day was coming. There were plenty of signs of the impending shutdown for months prior, but we were actively ignoring them. So the news came as quite a shock, and I was painfully aware of all the things that I should have been learning over the years to be more professionally valuable. There's nothing like having the blindfold whipped off while standing at the edge of a cliff. 

I didn't waste any time. I dove back into learning with a rediscovered passion that I had forgotten was there. Luckily, I found a great new job much more easily than I expected, yet the learning continued beyond getting the job. What I quickly found was that I didn't need the external motivation of losing my job to pursue learning again. That was just the spark that started the fire. My internal desire to learn was still there, buried, but easily uncovered. Once it was rekindled, it took on a life of its own. I've been devouring books like crazy since then, reading everything I can for over a year now, and I think that my software engineering abilities have dramatically improved. I certainly still have a lot to learn, but now I know where I'm going.

Cultivating a Lifelong Love of Learning

Once I had gotten into the swing of things again, I realized that learning outside of school is much different than it was before. I have total control over what I learn in my free time, and total responsibility. I need to carve out the time to study, pick out the materials I'll use, and devise my own projects to do for practice. It's entirely on me to improve my knowledge in a way that's more self-driven than even my favorite graduate courses were. That's very empowering and satisfying.

I wish I had come to this realization sooner. I could have been continuing my education all along. A little time off after college was warranted, but not years off. The technology industries move fast, especially software, and letting years of development in the software industry go by will leave your knowledge pretty obsolete. You should always be learning.

I am not advocating the pursuit of knowledge to the detriment of all else. Maintaining a lifelong love of learning requires balance. Learning how to learn involves developing an awareness of that balance between your personal, family, social, and professional lives. Without balance, the pursuit of knowledge could become meaningless, or worse, draining, instead of fulfilling. If you hit a wall, take a short break. Then find the right balance, and pace yourself.

Learning How to Learn (Part 2): How Do You Learn

Last week I developed the idea of prerequisites to learning how to learn, namely curiosity, motivation and time. All three aspects are necessary for us to be driven to learn and retain a lasting understanding of any subject, yet they only point us in the right direction for learning. They don't actually get us to our destination. To go the distance, and actually do so efficiently and effectively, you should learn the best ways that you learn, and that is a deeply personal experience.

The best way I can describe this personal awareness is to tell you how I learn, as an example. I am certainly not advocating this approach to everyone because everyone learns differently. This approach works for me, but it may not work for you. Let's say I want to learn a new programming language. How about JavaScript, for the sake of a concrete example, since I'm learning that language right now. I got a couple books on it, one moderately large, and one ridiculously large. I'll read through those, and do some more reading on the internet at w3schools.com and jQuery.com. I always read at least two different sources on a subject because different authors hit the subject from different angles, and that diverse treatment helps me make better connections in my brain. I remember things better that way. So foremost, I learn by reading. A lot.

Then I'll think up a project that I can do in JavaScript, like a card game or a paint program or even a script that parses my Amazon wishlists and finds all of the publication dates and page lengths of the books and writes them out to an XML file so I can sort them by title or date or length. You know, something more useful that Amazon's lists don't already do. The important thing is to come up with a project that I'm interested in - a project that will do something significant with the language - and then do it. So I learn by reading a lot and then doing.

If I want to further solidify my understanding, I can discuss with other people what JavaScript is good for. What are its trade-offs? What features really stand out? What features should be avoided or used with caution so I don't shoot myself in the foot? Once I have a decent foundation, these discussions can take my understanding to the next level. And that's about it. I learn by reading a lot, then doing, and sometimes discussing.

This realization of my learning style came together for me after that Grey-box Systems course in graduate school. That course was all about reading and discussing and a final research project that really showed me how I learn best. I learned faster and more profoundly than I ever had before. My head was buzzing with the mental connections that were being made. The course also made me more aware of the ways that I don't learn nearly as well.

I do not learn well in lectures or training courses. In those situations, I can't go at my own pace. I can't delve into topics that I find particularly interesting. I can't stop the proceedings to work something out that I didn't fully understand. I end up getting bored and my mind wanders to what I could be doing instead. In college I could never fully grasp why most professors would constantly rehash the material that I had just read in the textbook without ever deviating or expounding on it with their own experience or insight. The best ones did do this, but they were the exception.

Training courses are even worse because they are short and trivial by design. I attended a two-day MATLAB course a couple years ago, and I didn't learn anything that I hadn't already learned in the first couple hours of reading the documentation and experimenting with the program. When the course ended without covering any of the more advanced features that I was hoping to learn, I asked the trainer what the best resources would be to pursue MATLAB in more depth. He suggested some more training courses that were offered in other major cities. That was not terribly helpful, considering my learning style, so I found some more books and online references, and that suited me much better. I actively avoid training courses now.

Even worse than training courses are online educational or training videos. I simply cannot stand these things. Sure, with a video I can pause or skip around at will, but how can I know where the interesting bits are, if they even exist. The lecturer has no idea how the audience is responding since there is no interaction whatsoever. Online videos succeed in completely removing the one aspect of lectures that I find remotely useful - asking questions to go into an interesting topic in more depth. The few times I've tried watching them, I end up watching the time tick away on the position slider while trying earnestly not to pull my hair out.

I'm sure each of these ways of learning are invaluable to other people because everyone learns differently. I'm sure there are plenty of people that can't stand reading to understand concepts and get lost when experimenting on their own. They may find lectures and guidance and coaching extremely helpful, and that is a great way for them to learn.

My wife learns in a completely different way than I do. She takes copious amounts of notes. I am astounded by the volume of notes that she can take, and she can remember where she's written stuff on any given topic. This is all entirely foreign to me. Even if I could continue to follow a lecture while taking notes, which I can't, I would never find a use for the notes after I'd taken them anyway. She has a chronological memory, though, and she can pull up old notes in her notebooks quite easily to refresh her memory on something. I bet the act of taking notes also helps her more fully understand what she's hearing. I know plenty of people learn that way, it just never worked for me.

What is even stranger to me is the way my wife learns by asking questions, and I mean a lot of questions. If it were me, I would be expending so much mental energy coming up with all of those questions that I would quickly become thoroughly confused about what we were even talking about anymore. I'm still trying to figure out how her extensive questioning works exactly, but I do know that it works well for her. She is wickedly smart when it comes to understanding human interaction and emotions, and this way of learning probably accentuates that ability. She can easily interpret underlying motives and concerns in group settings of which I am completely unaware. So her ways of learning are completely different than mine, and incredibly effective for her.

These methods are certainly not the only ways that we learn. Learning styles is its own field of pedagogical research, although studies on proving the beneficial link between learning style and student are mostly inconclusive. Learning a bit about the research may help give you ideas for how you learn best, but I pretty much came to the realization on my own. I'm sure you already have a pretty good idea of how you learn best as well. I imagine the research was running into problems with the prerequisites to learning because they would have to standardize what was being learned, likely on some mundane topic. If you aren't interested in the topic, how you learn it isn't going to make one whit of difference. However, if you really want to learn something, I'm convinced that how you learn it can mean the difference between frustratingly slow progress and quick, clear understanding. I encourage you to experiment with your learning style on something that you have been meaning to teach yourself lately. Go on and find out how you learn best. I'd love to hear about it.