July 11, 2010

How I Learn

In the 11th episode of the 37signals Podcast, a listener asks a question of Jason Fried and David Heinemeier Hansson (at the 15:30 mark):
Q: Michael Hopkins would like to hear about what your team does to learn.
A: [Jason] Some people go to conferences, other people just pay attention and observe things. I think that's the best way to learn, just to stay focused on your industry in some ways and see what everyone else is doing and pay attention to the right news sources and learn stuff that way, and to just try it out. That's really the best way to learn anything, to try it and to experiment with stuff. 
A: [David] My approach is basically... Whenever I get annoyed about something, that's when I learn. So, I'm annoyed about how a technical process works or something else works, and I don't necessarily know right now how to fix this, so I gotta find out how to fix it. So I gotta learn whatever skills I need to pick up or patterns or whatever else, what have you, to fix things that bug me.
Hearing their answers sparked the question in me ... what do I do to learn?

I really identify with Jason's answer. In many respects, I'm an observer. I like listening, watching, observing, being aware. Taking the time to reason things out. Seeing how others reason. It's how I absorb facts and ideas.

Really learning a topic requires more than one type of observation style, though. Simply reading a book isn't enough. My best learning comes when I combine different observation styles. So, I've developed a multi-pronged learning attack:


There's no shortage of informative, thoughtful, quality reading material out there. Lately I've found myself on a sort of reading renaissance, renewing my childhood love of reading. In the past year or two I've made a concerted effort to maintain a constant reading schedule. I've tried to keep a good mix of fiction and non-fiction, technical and non-technical, purposeful and frivolous. I find that the mere act of reading helps keep the mind engaged. The library is my friend (Remember libraries? Yes, they still exist.)

As for software development, there are a ton of good books out there, from classics like Code Complete, Structure and Interpretation of Computer Programs, and Design Patterns: Elements of Reusable Object-Oriented Software, to new(er) gems like The Pragmatic ProgrammerClean Code: A Handbook of Agile Software Craftsmanship, and The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life). For more inspiration, there's a good list of must-read programming books on stackoverflow.

But books aren't the only thing to read. I can't think of a better way to keep up-to-date with the software development industry than a good RSS feed reader and a good list of technical blogs. Develop a reading schedule and maintain some discipline, or else productive reading can quickly turn to wasted time.

Lastly, read source code. There is an abundance of good open-source software out there. Check out Google Code, Codeplex, and GitHub to start.


I've become a real fan of podcasts. There's no better way for a wallflower like me to listen in on conversations between interesting people discussing interesting topics. Whether it's Scott Hanselman talking about the business of social media or 37signals talking about their design process or Jeff and Joel shooting the breeze about StackOverflow, these are conversations that are going to happen anyway, but we are invited to listen in. You're missing out if you don't. Check out my list of favorite podcasts it you're looking for a place to start. It's a great way to make your commute productive.

Audio books are a good hybrid of the Read and Listen styles. Books that teach programming techniques probably don't translate well to the audio format, but books about the programming industry do. Again, the public library is your friend. There's a ton of content out there that won't cost you a penny to absorb.


They say sometimes a picture is worth a thousand words. I'm constantly amazed at the amount and quality of video content that's available on the Internet. Sometimes it's one man behind hundreds of video courses (Khan Academy), other times it's an Ivy League university (MIT OpenCourseWare). It might be a mind-opening talk like Seth Godin on quieting the lizard brain or Malcolm Gladwell on spaghetti sauce. There's a ton of vendor-provided how-to videos like ASP.NET MVC Video Tutorials and Ruby on Rails Screencasts. If you can't attend big conferences, many of them record their sessions and provide the content online, like Microsoft Mix and RailsConf.

Paid video learning content can also be very useful. I've recently subscribed to TekPub, which has videos on subjects ranging from ASP.NET MVC2 to Mecurial to Sinatra and more. To get a feel for what the paid content is like, check out their free Coder to Developer series.


After reading, hearing, and seeing so much great content, you're bound to have questions and ideas and opinions bounding around in your head. Let them out. Talk about them.

The most obvious place to do so is in your workplace. Strike up a conversation with your development team during your next team meeting or around the water cooler. Set up a "developer day" to get the team together and explore ways of improving processes or integrating new technologies. However you can, the important thing is to get the discussions flowing.

There are plenty of opportunities outside of work, too. Local user groups are an obvious option. But there are also online discussions available on sites like Google Groups, Yahoo! Groups,  and LinkedIn.

A great place to ask programming questions is StackOverflow.


You never know how much you really understand a subject until you (try to) teach it to somebody else. Sometimes it can be humbling, but it's always rewarding. The very act of preparing to teach will lead to a higher understanding the topic.

It's not hard to get started teaching. Here are a few ideas:

  • Volunteer to give a presentation to your coworkers, or perhaps to a local user group.
  • Lead a design session that integrates a technique or tool you've just learned.
  • Log on to StackOverflow and answer some questions.
  • Teach a child how to make a simple game using Scratch or Alice.
  • Volunteer at your local school or community center to teach a beginner's programming class


Most importantly, use what you learn. Build things. There's no substitute for hands-on experience.

July 08, 2010

Improve Your Software Craftsmanship with Apprenticeship Patterns

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman
I feel that software development, at least the customer-facing business application type of development that I do, is a craft. Although my current official job title is "Software Engineer", I feel less like an engineer and more like a craftsman.

There has already been much debate about this distinction, and I won't repeat it all here. But suffice it to say that the critical difference, to me, lies in how one should go about getting better at their particular flavor of software programming. I tend to agree with this assessment of the continuum of software programming as it relates to the concepts of "art", "craft", "engineering", and "science":
Programming is rarely a science, sometimes engineering, but usually a craft. No example of programming-as-science comes to mind, but there is certainly a lot of science going into programming (codify natural laws found by science, and you have a simulator). Programming is an engineering discipline when the goal is not to add new functionality, but to make existing functionality work to certain quantitative goals. A lot of OS design and database work, for instance, is engineering. Making new functionality is usually a craft, where the result isn't getting something to work at such-and-such a speed but getting something to work at all.
If the types of programs you write tend to be farther to the engineering side of the spectrum, concentrating on speed, efficiency, scalability, interoperability and other quantitative goals, how do you improve your skills? Generally, you increase your algorithmic vocabulary by learning or inventing new algorithmic techniques, or you devise clever ways to harness existing methods in unique and powerful ways. This is mostly an academic exercise, and can be accomplished with traditional educational practices.

But what if your programs are more aligned with qualitative goals? What if the success of your software depends more on being understandable and easy to use than on being ultra-fast or efficient or (gasp) bug free? How do you get better at that? For most of the software that I write, the success of the software depends much more on the qualitative aspects than the quantitative (assuming the engineering quality is reasonable, of course). In my experience, improving one's ability to be successful with that kind of software has shown to be more about practice than about education. You improve the same way you would improve in any other craft.

I recently came across the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.
Are you doing all you can to further your career as a software developer? With today's rapidly changing and ever-expanding technologies, being successful requires more than technical expertise. To grow professionally, you also need soft skills and effective learning techniques. Honing those skills is what this book is all about. Authors Dave Hoover and Adewale Oshineye have cataloged dozens of behavior patterns to help you perfect essential aspects of your craft.
The authors recognize that the most effective way of honing a craft is through the process of apprenticeship. In lieu of a traditional apprenticeship (does anybody know of one?), it is up to you to provide one for yourself. Steps for doing so are provided in the book.

The best part, though, is that you don't even have to buy the book to see what those steps are. The entire contents are freely available through the publisher's website at http://apprenticeship-patterns.labs.oreilly.com/.

There you will find advice on how to:

  • Unleash Your Enthusiasm
  • Confront Your Ignorance
  • Retreat Into Competence
  • Nurture Your Passion
  • Find Mentors
  • Be the Worst
  • Share What You Learn
and many other patterns to follow on the road to mastery over your craft. Each pattern is presented with its relevant context, what problem the pattern solves, and specific actions you, the apprentice, can take. From the preface:
This book is written for the person who has had a taste of software development and aspires to become a great software developer. You may be a web developer or a medical device programmer, or you may be building trading applications for a financial institution. Or perhaps you have just graduated from high school or college knowing that software is your future.

Although this book was written for newcomers, more experienced developers will benefit from its content as well. People with several years of experience may find themselves nodding their heads in recognition of dilemmas they’ve already faced, and may come away with new insights or at least a new vocabulary to describe the solutions they want to apply for themselves or suggest to their colleagues. Even people with a decade or more of experience—particularly those who may be struggling to navigate their careers—will find inspiration and perspective to counter the siren call of promotion to management.
If that describes you, then you owe it to yourself to (at least) give the online version a look.