My Learning - Part 11 - Doing

       
"You always know enough to get started"

//Christer Olsson
    

Doing

"Doing" in this case refers to actually do whatever I'm trying to learn, e.g. to actually coach someone or test software rather than read about coaching or discuss testing with experts. "Do" (as a learning tool) can include a variety of activities such as:

• Conduct experiments
  Do something in a specific way and evaluate a particular outcome.
      
• Practice
  Do something in a specific way to learn how to do it that particular way better. In this case the process of doing it is important, not the actual outcome normally.
      
• Act and reflect
  Do something as well as possible while consciously monitoring what's happening and analyzing why.
        
• Repetition
  Repeat something over and over, as well as I can, without "wasting" time monitoring it too much simply to make it stick.

... and what I'm trying to achieve in my learning is to make "doing" one of the first steps in my learning process rather than waiting until the end.

Example: Instead of reading everything there is to read about coaching before I try it for myself I might learn the absolute basics and then start to look for someone willing to let me practice on them (preferably someone who can give relevant feedback as well).

A couple of key reasons why I find "doing" so important to me are:

• Actually doing something teaches me what else I need to learn/what I need to focus my learning on much more effectively and precisely than e.g. reflection does.
       
• When I have actual experience of something I can relate new information to this experience making it easier to understand and easier to remember.

This doesn't happen naturally for me though. I'll come back to this in much more detail in a later part but long story short: I don't like to not look good... which sometimes sucks because it means I want to learn something reeeeeeally well before I go out and actually display my skills in it (including displaying it to myself, I get frustrated to see myself do things in a way that's not "good enough").

This makes me prone to becoming "an intellectual" and while some like being that I don't, so I'm trying hard to change my own approach.

... and I actually have a history of very effective "doing" in my learning so I know it's something I can get back to...

     

Becoming a doer

"Doing" came naturally when I was learning software testing. I think it was because "doing" was such a central in part in everything taught and highlighted by my heroes and peers which meant whenever I tried something new I got plenty of positive feedback simply for the effort alone. So it was easy to motivate myself to continue doing things even when it meant a great risk of "failing" publicly (which I'm unfortunately not very comfortable with as I mentioned before).
 

Stop being a doer

When I had to cut down the time I spent learning testing one of the first things I stopped doing was... doing. I'm not sure why I quit practicing testing alone (e.g. test open source applications at home) but the more public stuff is more clear to me:

1. Other testers started to surpass me which meant I thought I would not perform "as well" in public challenges as I use to which made me ignore them all together not to "humiliate myself".
       
2. I had built "a reputation" for myself and since I started feeling like I wasn't progressing as fast as some other people I kinda avoided public stuff simply to not hurt my reputation.

I understand that both are very counterproductive ways of thinking and it annoys the heck out of me that I held myself back just because of them. The good thing is thinking can be changed...
 

How do I get back?

When I transitioned into an active doer while learning software testing I had to push myself and the results and feedback made it easier and easier until it almost felt hard not doing things.

When learning coaching I have a couple of ideas on how to make "doing" happen again:

1. Simply exclude any resources that doesn't have a clear mandatory action connected to them (e.g. most books).
      
2. Make it a deliberate process to describe and perform at least one action for each resource I use before I move on.

I lean towards the second option for now because I see a risk of me losing my motivation if I exclude "easy resources" all together but that might change if I find myself skipping the required actions in option two.

An interesting coincidence in this case:

One of the primary purposes of coaching is to stimulate action... so by practicing on myself (a very light form of "doing") I can actually both get coaching practice and help me back to a more action-oriented way of learning...

Finally I love a great discussion but I need to hang out more with the doers in my network simply to be affected by their mindsets and routines. I know this was a big factor when I learned software testing...

Back to the overview

     

How to practice software testing

During open season after Erica Walker's presentation at CAST, I mentioned a few useful tools for practicing software testing or software testing related skills (rather than passively watch/read/listen). With this blog post I want to expand that a bit and share some of the applications/sources I've found useful when actually practicing to become a better software tester.

General

Bitnami provides simple installers (local install) for several well-known web applications such as Wordpress, Moodle and ExoPlatform. The installer automatically sets up a web server, database server and the application itself. This is a great sandboxed environment for you to play with and you have access to the application's code and database content allowing you to do pretty nifty stuff.

Since the applications available on Bitnami are fairly large systems you'll find opportunities to focus your testing on basically any quality characteristic or test technique no matter which one you choose. Why not try a full equivalence partitioning, value selection and variable combination testing table for the post thread as moderator form in phpBB or a usability analysis of PrestoShop?

The drawback with these big applications may be that they are a bit intimidating/take time to learn. In that case try the many software download sites like SoftPedia but be aware that some software you find this way might come with various malware.

Joining open source projects can also be a good way of practicing testing while also giving something back. Popular open source code management sites like GitHub and SourceForge are great places to look for applications in need of testers.

Database

Install XAMPP (fully preconfigured web server) and start running queries against the MySQL server. This also gives you the ability to practice writing (and running) simple scripts in e.g. PHP to manipulate/display the database content. Getting familiar with phpMyAdmin (preinstalled) is also a good idea for any web application tester.

If you want to practice online I recommend Head First Labs. You might need a MySQL reference (available online) though to solve all their exercises since they reference to pages in an O'Reilly book.

REST API

A great place to take your first few steps in API testing is predic8. They have an online REST-API available that you're free to play around with. I recommend fetching Postman and just start making simple GET requests. Use predic8's tutorial to help you progress.

Security

Tons of applications exist for the sole purpose of practicing security testing. These applications have dozens of vulnerabilities built in so that you can practice triggering and exploiting these vulnerabilities without risking to break anything. Also, many of these applications have active communities built around them where you can get help or documentation, explaining the various vulnerabilities.

WebGoat (web testing, local installation)
Have only briefly used this but from what I've understood this might be the best choice available. If you search for WebGoat on YouTube you'll find dozens of tutorials, demonstration and installation videos.

Google Gruyere (web testing, online)
I've played around in Google Gruyere quite a bit. It's a good place to start and convenient since no installation is required. Also, due to it's fame, several videos exist demonstrating vulnerabilities in Google Gruyere and explaining the thinking behind discovering them. One example is Alan Richardson's video.

bWAPP (web testing, local installation)
Only briefly used bWAPP but seemed like it had potential. bWAPP is more helpful than Google Gruyere in the sense that you're informed about what vulnerability each page has.

BodgeIt Store (web testing, local installation)
A web security practice application aimed towards beginners (if I interpreted the description correctly). Haven't tried this one myself.

Mutillidae (web testing, local installation)
One more I haven't tried myself. What I liked in the description though was it did claim to give hints which likely make it a good starting challenge to a new penetration tester.

GameOver (web testing, VirtualBox image)
I discovered GameOver as I was writing this blog post. Haven't tried it yet but it's a VirtualBox image with several penetration testing tools and web security practice applications preinstalled (such as WebGoat). Convinient!

There are also pages dedicated to learning web security by giving the visitor progressively harder challenges (puzzles) to solve. My personal favorite is HackThisSite as I think the challenges are progressing in a good pace and you can always get help if you're stuck. For a quite extensive list of practice pages, take at look at the top answer to this Stack Overflow question.

If you want to practice system level penetration testing I recommend the Metasploit Unleashed free course. Also look into Kali Linux, a Linux distribution centered around penetration testing.
(2022 addition: Got this Kali Linux Cheat Sheet recommended to me, hope it helps)

Information gathering

Information gathering is a critical skill for testers. A course I've just started that seems to have great potential is the Google's Power Searching course. The course comes with challenges making it interactive enough to fit this blog post.

Improve your skills in other common tools

You can improve your skills in many common tools by using training videos released by vendors or users and either mimic what's done in the videos or perform the challenges given. One example of a training video collection I've found useful is Microsoft's Office course.

Operating systems

I learned a lot about operating systems in general when I started playing around with Linux. It's a fun way to start and the amount of help you can get when stuck is mind-boggling. If you have some previous experience; give Arch Linux a chance. If you're new something like Sabayon might be at the right level. Popular desktop releases such as Ubuntu may be a bit hard to get "under the hood" in but for a first timer just seeing a different operating system might be enough. In that case, go with OpenSuse or any of the Ubuntu derivatives (e.g. Ubuntu itself, Linux Mint or Elementary OS).

If you don't want to tinker with partitioning; use VirtualBox.

Networks and servers

Plenty of material is available online and practicing it is generally just about tinkering with your own home network, e.g. figuring out what various router configuration options do. You don't need an expensive lab to practice network administration and server setup; two devices (e.g. a computer and smartphone) and a basic network connecting them (e.g. a router with a built in wireless switch) is enough. If you feel like you don't know where to start, use for instance the course page linked to in this chapter and try the concepts described (like port forwarding, dhcp and file servers). I personally find network monitoring to be a particularly useful topic for testers.

Conclusion

The two most important messages I want you to remember:

1. Do practice, it's important
2. ... and not that hard

Good luck and if you have additional suggestions, just share them in the comment section below!

My success story, a story about failures

I have a lot of things to say about CAST, to people who would like to speak at a test conference, about personal development and about my own presentation. But first a few stories I want to share, hopefully busting any ideas about "some people are born to speak while others aren't".

Messing up a play

My first memory of something presenter-like was in 4th grade. 4th, 5th and 6th graders were mixed together in drama groups and something like once a month each group performed a play for the other groups. My group's first play was ruined. How? Well I couldn't shut up. I interrupted the other actors, screwed up jokes by explaining even the most obvious ones and was too nervous to remember any of my lines giving everyone else a hard time... The self elected leader of the group (a 6th grader) was furious when all of us gathered afterwards to discuss the play.

My first presentation

Moving on to 7th grade and the first time I presented to a larger group of people (~30). For this presentation each of us were given a famous author to talk about, mine was Charles Dickens. I was so nervous, but I had rehearsed a lot and prepared a rather detailed script so everything should be fine. I went up on stage, took a couple of deep breaths and said... Blaghl...bl..br, which unfortunately doesn't make any more sense in Swedish. I couldn't form a single word! I couldn't even say my name! I tried several times with every failed attempt just inducing more and more panic. Finally I threw away the script and just relied on my memory, which was no problem at all since I had rehearsed sooo much. When the torture was finally over several class mates came up and said: Wow, you were really calm when presenting... I was still shaking.

At the university

I volunteered to become a university ambassador. One part of that job was to speak to groups of high school students. One time the group was rather large, about a hundred people. I froze! I froze for something like 30 seconds (felt like 10 minutes) before I started and when I finally did I think I forgot to tell them like half the stuff I was expected to present.

Improving legacy code
Moving on a few years, now as an employed software tester. I had suggested a very vague idea, basically saying we had to work with the quality of our legacy code. So I was asked to present my ideas to the rest of the department. To make matters worse I got sick a few days before and due to that I had basically no time to prepare myself. I also knew that the material was way too abstract due to the fact I didn't really understand the details. Any professional would say: "I'm very sorry but I'm not ready to give this presentation" (a question I was even asked due to my sickness)... I didn't. The result?
"We need to work with the quality of our legacy code. A few things I've thought of izzzz...", what happened after that is a bit blurry but apparently one of the managers saw I was about to pass out and caught me before I fell, while someone else grabbed a chair. I got some water and actually finished the talk sitting down, still a bit dizzy... it was a memorable talk but not for the reasons I would have liked.

CAST warmup
Let's finish with a much less dramatic story. Just a few months before CAST I presented at a local test meetup in Malmö, Sweden. I would give a short talk on security testing. I felt calm until the moment I sat down in the room. After that anxiety rapidly (and for me surprisingly) built up. I think one of the main reasons was I simply hadn't rehearsed my talk. When Henrik Andersson offered us a beer I quickly grabbed one and it was perfect to ease the anxiety (something I haven't told him). However, knowing I "needed" a beer during one of my last public presentations before CAST was not really... comforting.

CAST 2013
Let's save this one for another post but short story is it went great!

Why am I telling you this?
Long ago I had the misconception that speakers at, for instance, conferences were natural talents who just had something I didn't possess. A misconception with an interesting twist as today I often hear people call me a naturally talented speaker. What I've learned, and hope my stories help you see as well, is that that something is mostly hard work. If you decide you want to learn to present there's no exotic gene stopping you.

Why am I telling you this... 2?
You might look at the stories I shared and say: "Why not focus on your successes?", but here's something cool: The stories above are my most important events as a speaker. Without them I wouldn't be in the position I am today as a speaker and if I sound insane, let me give you some examples:

Messing up a play

• I need to sometimes stop myself and simply shut up.
• I need to think about what's interesting to the listener, not just what I want to say.
• Being well prepared (rehears) is key!

My first presentation

• I can actually present.
• I don't need a script.
• Even the worst case scenario wasn't that bad (you could argue that passing out is worse than not being able to say a word but they're pretty close).
• There are things I can't seem to learn/fully understand without actually failing first.
• There's no such thing as a failure or success, we always fail to some degree and we miss out on a lot of potential success if we don't take the opportunity to learn from these small or big failures.
• As long as I rehears, things seem to work out okay no matter what.

At the university

• Silence is actually not that bad.
• Less is more, I forgot a lot of the prepared material but in the end that seemed to make what I said, stick better (based on reactions from students after the presentation).
• You can turn a bad start or problematic presentation into something great, it's never too late. This one actually turned out as one of my better presentations as an ambassador.

Improving legacy code

• Doctors didn't find any problems with my heart, lungs or head (obviously physical health was enough). That's actually quite comforting.
• Due to all the medical tests I had to leave a whole bunch of blood samples which eased my fear of needles and hospitals.
• ... and that taught me a valuable lesson about fear: Fear is much about not knowing the outcome, not about the experience itself. Understand that and a whole lot of things stops being scary (very, very powerful insight).
• I know my limitations better.
• I know when to say no better.
• I know the possible consequences which further helps me say no when I really should.
• I've learned the value of understanding the content I'm about to present.
• I need to rehears.
• I need to rehears.
• I need to rehears.
• I've learned code quality is much more complex than I once thought it was.

CAST warmup

• I need to rehears
• I need to rehears
• I need to rehears
• Open season with K-cards is actually not that scary (I had not tried that as a speaker before)
• Beer solves a lot of problems... kinda.

You can do it!
If you feel like presenting at a major conference would be cool but you hesitate since you're not a "natural speaker", Think again!

Practice
At work, local meetups, small conferences, at home or maybe checkout Toastmasters International (Credit to whoever gave the lightning talk about Toastmasters at CAST, just found out we have a local club where I live so I'll give it a try!).

Challenge yourself
Try new things, get out and speak in front of people, record yourself, test various formats, present without slides, try drama or stand-up, present in front of more people, present in a non-native language...

Wrap up
I think I'm a talented speaker today, and that's not just based on my CAST performance. But it has little to do with my amazing genes, it has to do with practice and challenging my limits. I'm pretty sure all your favorite speakers have similar stories (or at least I hope) and that their biggest secret too is practice.

So don't wait to become a great speaker, act to become a great speaker!

Oh, I forgot!
A key inspiration for this post as well as one of the real highlights for me during CAST, was Dawn Haynes' keynote. Make sure you check it out!

Oh, I forgot... 2!
During open season, several people asked me about my failures and how I dealt with them. Hopefully this post answers some of those questions. If not, please ask your question again (Peter, Simon and Jonathan were the ones I remember, did I miss anyone?).

Thank you for your time and good luck with your presentations!

Key testing skill: Thoughts into words

Background
During SWET 4, one thing that really struck me was how amazing the other participants were at quickly and accurately turn their thoughts into words. It was probably the most striking difference I noticed between myself and these experienced testers. Since then I've kept thinking about this skill and how to improve it. This is my thoughts so far...

Why
One of the early slides in the RST material starts with: "Testing is in your head" which I think sums up why this skill is so crucial. You need it if you want anyone to understand anything about your testing. Some examples; you need it to get:

• Programmers to understand your bugs
• Stakeholders to understand why these bugs are important
• Your employer to know why (s)he needs you
• Your colleagues to know what you're doing and how it's going
• Anyone to understand your problems
• Stuff on paper (strategy, results, methodologies etc.)
• You to understand for yourself what you are doing/have done

Notice the list doesn't mainly consists of stuff only some test thinking expert needs to master, it's stuff every tester needs to master!

How can you improve this skill?

Since this skill is fundamental to testing you will practice it to some degree by just doing ordinary work but the ideas I've listed below are ways I've found more efficient either as ways to practice the skill or to get feedback on how well you're doing.

Answer the fundamental questions

For many questions the answer is far less useful than the process of getting to an answer. Some examples in testing:

• What does it mean to test something?
• Why do we need testers?
• Can't programmers test themselves?
• What's the tester's role?
• What is a bug?
• Do testers need education? Why? Why not?
• Can we find all bugs? How? Why not?
• How do you know when you're done testing?
• How can we measure efficiency of testing?
• How do we know what's important?
• Why do we run extreme tests?
• Can we on beforehand figure out what to test? How? Why not?
• If we know the status of a product shouldn't we decide whether or not to ship?

Can you answer them? Is your answer a quote from some famous tester like "a bug is something that bugs somebody who matters"? How do you know who matters? How do you know what these people think? Is it enough if one out of a million of these are bugged? Two? Five? A hundred? If we expect someone to matter later who we expect will be bugged about this, is it a bug? If people who matter don't know about something, e.g. a missing link, but would love it, and be bugged if it was later removed, is the fact that it's missing a bug?

The questions I asked above is exactly the kind of questions I want to you ask and try to answer. It's a kind of mental gymnastics that will not only help you improve your ability to put thoughts into words but it will also help you learn a lot more about testing (which will be a common theme for the rest of this blog post).

Blog

I brought up the importance of blogging way back in my 2012 refelction posts, there you can find a bunch of motivational links and tips on why to blog.

Anyway, I get two things out of blogging relevant to the topic:

1. Feedback on how well I present/explain my thoughts (if people read and react)
2. An efficient way of practicing the act of putting thoughts into words

The second point depends on that I write about my own thoughts and not just reference what other people say.

Talk about test

Talk to colleagues, speak with people on Twitter, go to conferences/meetups, present. All these things force you to practice the art of putting thoughts into words, some of them also force you to do it rapidly to keep the conversations going which adds another dimension (which, for instance, blogging doesn't).

Explain what you do to non-testers

Have you ever tried explaining what you do and why it's important/interesting to someone like, say your mom? Or boss? Or best bud? Or some programmer you know? Or maybe you from before you became a tester ("hey myself, you're going to become a software tester and you'll love it, let me explain to you why!")? Try it, it's a lot harder (at least for me) than you might think. Also it really forces you to look deep into your thoughts to find out what things really mean to someone not familiar with testing (sometimes it helps you figure out what stuff really means in a more general/other context than testing).

Ask for feedback
It's important to practice but it's also important to know if your efforts are paying off. "Am I really better at explaining what I do know?". You can ask pretty much anyone how they interpreted you explanations and/or how easy they though your explanation was to understand. Here are a few quick, general example:

• Was my last bug report clear to you? Did you miss something?
• Was my last debrief useful? What could I've done to improve it?
• Did you understand my explanation or what part was hard to understand?
• Is it clear to you why I think we need to use an exploratory approach?

Question stuff

If you walk around and accept not understanding what others try to communicate to you I believe there's a great risk you do the same about your own explanations/thoughts. Try to get out of this by questioning anything you don't believe in and ask for another explanation whenever you don't understand something. I've found this to really help me question my own believes, assumption and opinions.

Good question to ask yourself after any explanation:

Would my dumbest colleague understand this and why not?

As a recommended reading on this I really love this blog post from Tommy MacWilliam.

Mentor someone

I've just done this briefly but I find it a great way to force myself to explain in detail what I'm doing and why. It also provides me with a great possibility to get feedback, both verbally and as I monitor my pupil's improvements.

Rapid Software Testing

The Rapid Software Testing course is a lot about trying to get you to think like a top notch tester. One of the key aspects practiced during this course is explaining what you do (putting thoughts into words) and build the courage to do so. I highly recommend the class for many reasons, this is definitely one!

Summary

Putting thoughts into words is key when doing any form of testing (planning, executing, bug reporting, following up etc.). Ways I've discovered that works well for me to practice this skill is:

• Question the answers, why is this answer true? Is it really true in this context? When is it not true? Why?
• Try to come up with your own answers and refine them using questions
• Blog, or write about testing in some other way
• Talk testing whenever possible
• Ask for feedback
• Don't accept not understanding neither your own nor others explanations
• Become a mentor to force yourself to communicate your thoughts
• Rapid Software Testing is a great course to help you improve this skill

EAST meetup - Trying a new format

What is EAST
Short version: EAST is a local network for software testers in the area I live (Linköping, Sweden). About once a month we meet to share thoughts, learn and socialize/network. If you want to know more you can read my post from my first EAST meetup.

New Format / Concept
Most previous meetups have followed the format: Start with food and socializing, then 1-2 presentations, each followed by discussions. A few other formats have been used, like letting each participant shortly describe how testing is performed at his/hers company (try to get everyone involved), testing games and the pub evening with only beer and socializing. This time some hands-on testing was on the menu.

Webinar
As usual we started with food but instead of casually chatting with each other we together looked at the Six Thinking Hats for Software Testers by Julian Harty (referring to Edward de Bono's thinking hats). The webinar was interesting but I missed the social part. Maybe a 5-15 minutes long webinar would have worked better for me.

Hands on
Second part was hands on. First David, the facilitator, quickly presented the application we were to test and how to get it. The application in this case was an app for taxi drivers to help them keep track of their work (part of a full system for taxi companies). Second we would, in groups or alone, test the application using the six thinking hats in any way we saw fit.

First I and a former colleague from Ericsson started out exploring/scouting the app but soon felt we didn't get any momentum and joined another group of three. A vivid discussion on how to use each hat and what fitted where ended with us being ready to actually start generating test ideas about 5 minutes before deadline but that didn't matter, at lot of interesting stuff came out of the discussions.

Sharing results
When we were back together we started the sharing of ideas and experiences from the hands on part. Immediately it became clear the various groups had used the hats very differently.

We attacked the whole app and used the various hats from the perspective of an actual user (or rather our made up view of how it was to be a taxi driver, lesson learned: better understanding of the user; for instance its needs, knowledge and general behavior, would have helped a lot). This perspective gave us an interesting high level view but it was a bit hard to stay focused as we often drilled down too deep exposing too many details. Others focused on a smaller part of the app which, in this case, seemed a lot more efficient.

Of course how to use the hats would depend on the mission in a real life scenario but in this case the mission was not set like that, the goal was just to try out the hats and learn from each other's way to approach the hats and for this, our perspective took a little too long / became a bit too complex, at least for beginners like us.

Wrap up
To wrap things up we had a more general discussion about the hats and format.

A few thoughts about the hats:

• In this scenario we had no problem coming up with ideas quickly and the hats initially felt more limiting than helping. In a situation where we would have been stuck or at least worked with the product for a bit longer, the hats would probably had been more helpful. This might also change as we get better and better at using the hats but only time can tell how that turns out.
• Keep using the hats on items already identified would probably render interesting results. For instance first we could use the white hat to identify a data item, say cars in the Taxi app, then we could use the hats on this item to identify risks (lack of cars), opportunities (more efficient usage of cars), new data (various types of cars), feelings (lust to drive fast), "darkness" (breakage, with passenger in the car) and ideas (what if the cars were any kind of vehicle, like bicycles or trucks, what other users could then benefit from the app). Continuing to apply the hats on each new item added would help to dig really deep down.
• The hats would be interesting to use on the product elements or quality criteria categories described in the RST Appendices.
• You should be able to visualize the findings quite effectively using a mind map.
• The hats could be a great tool to help refining, populating or creating a model.
• Someone suggested it could be useful to help explaining the various parts of testing to, for instance, a programmer (not sure I understood this correctly but as I interpreted it, it could be used to help them understand the wider "find valuable information" perspective rather than the narrow "find faults" perspective of testing).
• If you're not stuck yet, starting with no particular hat and instead just add stuff wherever it fits in the beginning might be a more efficient way to start (possibly changes when you're more use to the hats).
• The hats were helpful to find more non functional aspects to test.

A few reactions to the format/execution itself:

• Generally people seemed to have liked the format a lot.
• We had some troubles understanding the app's usage/user. Using a known application (like MS paint) or object (like a chair) might had been better ways to understand the concept of the hats. On the contrary, using this app forced us to do some scouting and work with assumptions which broaden the ways the hats could be used.
• Like I said before, the webinar was a cool way to mix it up personally I missed the regular chatter while eating. Still very cool so a shorter webinar might be perfect.

Finally it was fun to just study my group during the hands-on part. Let's just say we had very different ways to attack the problem (relentless scouting, analyzing the input information or quickly getting a set of data to work with for instance).

Thanks!
Thanks to David Månsson, Aveso, who facilitated this meetup in a kick ass way! Also thanks to all the participant for sharing interesting thoughts. Looking forward to future experiments, this one was definitely a success in my book!

Practice: Note taking

Yesterday I decided I wanted to improve my note taking skills (my finance stopped trusting my memory a long time ago and it's time I do the same). I also decided books, blogs and similar was forbidden ground cause I constantly find myself reading instead of practicing when I try to learn something, which I don't think is a good thing. So I picked a presentation, in this case Elisabeth Hendrickson's keynote from Cast 2012 (The Thinking Tester, Evolved), and forced myself to take enough notes to be able to retell her key points a week later. At the bottom of this post I've added my actual notes as pictures, not very easy to read but hopefully good enough (with my handwriting when writing fast, I don't think any picture quality would make a difference though)

First a few general realizations:

• It was fun!
• It was easier than I thought! I don't know if this was because it was fun, due to the specific topic or some other reason but I guess time will tell.
• It felt efficient! I have a hard time imagining it would be possible for me to learn as much in the same amount of time by reading (for this topic I should add).
• Just like reading makes you practice other skills, like focus, this was an efficient way to practice several other useful skills for instance:
• Observation
  Both during and after I observed everything I did in a conscious way.
• Reflection
  From the observations I draw conclusions and tried to figure out what I could learn from these conclusions.
• Focus/Discipline
  This was, for me, a much more powerful way of practicing focus than reading.
• Listening
  In this particular practice I soon noticed my way of listening to what Elisabeth actually said got better and better leading me to believe this could be a powerful way of practicing listening as well.
• I feel motivated to do it again!

So what did I learn about my way of taking notes (the quick version):

• I'm not bad at taking notes when I really try, my problem is rather that I don't try
• I tend to structurally close sections (for instance adding borders) before they are really finished adding some interruption in flow when I have to fix this.
• I change style when I mentally change section. That's actually quite useful since it makes different parts easier to distinguish. Compared to my borders above it's much easier to come back to sections when style, rather than boxes, differentiate them.
• I like to headline my sections, sometimes that becomes counterproductive, for example I sometimes make up headlines before I really understand what a section is about making my final result confusing.
• In the beginning I wrote down stuff as I heard them, the more into the note taking I got the more I listened to a whole section before adding notes, this made the notes more relevant but sometimes I missed out on details. In most cases I would prioritize relevance, but I have to be aware it's not always the best choice.
• I organize my notes on paper as I organize the information in my head. I have a hard time writing down my notes in a more "reading structured way". This could sometimes be useful (I believe) so trying a similar practice with a more "live blogging" approach would be very interesting. Also, this could be an area where reading would be really helpful. I've not read so much of Markus Gärtner's work yet but I've understood from comments he's the king of live blogging so that could be one place to start...
• I believe some parts could have been better represented with visualizations. This is definitely an area to improve, maybe by doing a similar practice with just different constraints.

I'm pretty sure more lessons will be learned tonight when I sit down and look at my notes again (only did that briefly yesterday) but no matter the outcome tonight, this feels like a success! Hope it can help someone else as well.




... and by the way, right now retelling key points next week seems really within reach...