Low and High Intensity Learning

Paul Graham in his essay Wealth says startups are a way of compressing a whole working life into a few years. You work at a very high intensity for a short period of time (say four years) instead of the normal low intensity for a long period of time (say forty years), in other words startups are a way of increasing your productivity exponentially. In my experience there is a correlation between high intensity working and high intensity learning.

The potential relationships between high-intensity work and learning have a lot of appeal because it provides a chance to leapfrog our understanding of several domains in a short period of time.

In his essay Startup = Growth Graham defines a startup as “… a company designed to grow fast”. My last company was small, we considered ourselves a startup (although according to Graham’s definition we were not) but we worked considerably faster (higher intensity) than a larger company would have. I can say that with some certainty now because a 15,000-person company acquired our small (maybe 10-person) company and the differences are pretty dramatic.

To be fair there is a difference between the learning that occurs when a person is working for a high intensity company as opposed to doing their own high intensity work. With a high intensity company people learn whatever they have to in order to solve the problems in front of them, then they move on. A person working intensely on their own has the freedom to focus on what they want but they run the risk of never finding focus.

I’m struggling with the second part. I’m back to a low-intensity company but I don’t want to be pulled into a low-intensity learning situation. Part of me says that won’t happen because of my own internal drive but another part of me is worried the low-intensity rhythm of the company will make it hard to find focus. (I’m not saying my small company was a good example of a high intensity work / learning environment but as of right now it seems better than the corporate world.)

One solution is to create my own startup – something designed to grow fast which would force fast learning. It would be amazing for many reasons including getting back to a higher-intensity learning situation but I don’t know where to start. Another solution is to find a person or person(s) with the same interests or goals as I have and work together to learn. Maybe the small team size would have the effect of pushing each other into a higher intensity work and learning environment? Now where do I begin?

Taking the RTI Online

In February I attended an online training course where participants test a software product using the Rapid Testing methodology called Rapid Testing Intensive (RTI) Online taught by James Bach. I found it to be a great way to test a product, get feedback on your work, build a software testing portfolio and learn about the Rapid Testing methodology.

Last July I took a similar in person training course appropriately called Rapid Testing Intensive Onsite. I meant to write about my experience but never did so allow me to describe it now:
The onsite version was an intense four and a half days of lecture, learning, testing and other team activities. From survey testing, to group stand up presentations, to the occasional after hours (with beer in hand) dice game it was a week of mental challenges with quite a bit of fun mixed in. After some encouragement from a few twitterers I shared my notes in the form of a live blog: (day 1, day 2, day 3, day 4, day 5).
During that time I was the “lone tester” in my company and taking a week to work on a team with other testers from around the world was a welcome change and an enjoyable experience. When a team member found something interesting or became confused the rest of the team became involved in the discussions which lead to new ideas about where to test. If someone didn’t clearly understand something someone else in the group could help. All this team work lead to some exciting discoveries.
Coming back to my original story I can do a little bit of comparison:


The online version was much more concentrated than its onsite counterpart but maintained all of the important aspects with an opening lecture, followed by a 90 minute testing assignment and then a break. During the break James would do the assignment himself and when the participants were back he’d show what he did, explain his approach and then review the work of those who were brave enough to ask for it.

Asking for your work to be reviewed live (webcast) can be a little intimidating. I remember doing the stand up presentation for my group onsite and I made a lot of mistakes in front of others but the result was I learned about safety language. This time around I knew mistakes would mean I’d learn more so I didn’t hesitate to ask. After the feedback session there was a little more lecture and then the day is done. This was the schedule for the rest of the course except with each day the assignments build off of one another and get deeper into the product.
Having essentially taking this course twice (first onsite, second online) my approach was to focus on understanding the assignments while also building examples of my work that I would be proud to share afterwards.  I used James Bach’s Heuristic Test Strategy Model to generate ideas for covering the product we were testing that would go into my Product Coverage Outline. Through both experiences I got new inspiration / ideas on how to organize and document my deep / combination testing. I played around with the way I take notes and continued to experiment with a method James calls concise documentation (however I prefer the catchier term “lean documentation”) which means there should be no fluff in your documentation, just the important parts.
Perhaps the most visible output from the RTI online are the work examples you build while documenting your testing – the Product Coverage Outline, deep testing matrices, testing notes, etc. These documents, after some cleaning and framing, will become the basis for my software testing portfolio – a public example of the work I’ve done and am capable of doing.
Not so visible are the truly important parts from the RTI online: learning about testing and deliberate practice. After all you can only get better at something if you practice it. Rapid Testing teaches us how productive and exciting testing can be by focusing on personal skill and the thinking part of testing. In my experience testing has always been about documentation (think test cases) and not about thinking / questioning what needs to be done. Every time I’ve taken a course in modern software testing practices (like RST) I feel like I start to understand more of the things that effect what I do and I start to question the assumptions involve. With the RTI I get to learn and practice which makes me feel like I’m growing and getting better.
I’ve found the product of those learning experiences, of the direct feedback to my work has improved how I test at work and how I view my product and the value of my labor. I’m not satisfied with where I’m at now, I might never be, but I do understand how far I’ve come and how far I have to go. See you at the next RTI.