My learning - Part 18 - Reflections

Seven, for me, important insights

1. The hourglass model and the learning modes were both very interesting concepts I had never formalized before and both turned out to have far bigger implications than I anticipated.
       
2. Only focusing on the big lessons and basically ignoring all other content is something I've used pretty much everywhere for a very long time but after making myself more aware of it I feel less guilty of doing it and I feel like I will be able to do it in a more deliberate, effective way.
       
3. I need less stuff not more.
        
4. Over the years I've looked far and wide to improve my ability to learn. What this experience has taught me is I forgot to look in the most important place: Myself.
         
5. Sometimes I feel like my motivation is the most irrational thing in the universe. But it turned out the old saying is true:
   "To be understood you must first understand".
   These blog posts made me understand what's happening when I gain or lose motivation and this knowledge has already helped me better control it.
        
6. My old way of thinking (avoiding not being great) still haunts me and writing this blog series made me realize I'm far from done replacing it with a "better why".
         
7. I want to get back to that action-oriented learner I use to be and I think these blog posts have both inspired me and shown me how to get there.
       

Three things I'll try

1. Self-coaching in a more formal way.
        
2. Deconstruct the concept of learning.
       
3. Learn something and immediately teach it to someone else
       

How to get more action-oriented

• More and better self-coaching.
• Even more emphasis on experiments.
• Remove some passive self-education to make room for more "doing".
• Reform my "why" to create a "why" that matters to me and that truly centers around actions.
• Hang out with more action-oriented friends as well as friends who might not be very action-oriented but open to join me on this journey.
• Define and perform actions based on things I learn. Keep doing it until it becomes a habit.
      

Removing is more important than adding

I started this series assuming I needed more:

• More time
• More learning resources
• More information to process
• More people
• More models
• More everything

But now I sit here thinking I need less:

• I don't need more time
• I want to limit my learning resources to better learn from the ones I use
• I want fewer resources to create less distraction
• I want to spend more time with the people I know rather than look for new
• I want to actively forget/ignore things so what's left becomes more clear
• I want to simplify concepts and focus more on deconstruction
• I want to stop gathering information and instead use what I already have

The problem is not that I have too little information; the problem is I have so much information that what's relevant becomes hard to find.
 

How will I follow this up? 

First of all I'm pretty sure I'll get plenty of reasons to follow up these posts thanks to friends reading them and asking questions (true so far).

However, on my phone I've also scheduled a reminder to revisit each of the blog posts individually about two months after they're published. Probably not necessary but better safe than sorry.
 

Bottom line

This has been a tremendous journey which I'm happy I stuck with and I'm proud of the result!

At the same time I'm happy it's over. I've spent more hours than I want to admit writing it and it's time to catch up with friends, family and other parts of my life I've had to cut back on (sorry Louise, Jesper, Helena and others). In the end I'm more motivated than ever to learn but also more aware than ever that some things in life are more important.

From the bottom of my heart:
Thank you for joining me on this adventure and good luck on your own! ♥

My Learning - Part 13 - Reflection

Purpose

I've read a lot, listened a lot, done a lot, observed a lot and, well... experienced a lot. This means there's plenty of good stuff in my head already.

Reflection is my method to recall, refresh and retool those existing skills and ideas. Retooling in this case refers to taking a skill or piece of knowledge I already have and apply it to something new. For instance, software testing have taught me a lot about critical thinking, skills and experiences I can retool to fit e.g. coaching or parenting.

Reflection also tends to make me act.
   

Trigger

What actually makes me reflect is something I still haven't quite understood. I know I gravitate towards "new stuff" such as new books, new podcasts, new exercises etc. even when reflection probably would be my best tool. At the same time I can sometimes drop everything and sit down for days or even weeks fully committed to reflection... but I can't see the pattern or trigger that initiates my reflection sessions.

Understanding these triggers is something I need to study and experiment more with.
   

How

When I get myself to sit down and reflect, what I do is I grab my notebook and start to make a plan: What kind of information am I trying to get out of my head and why? Forcing myself to create a plan like that can sometimes help me start reflecting but it doesn't work as consistently as I'd like.

What happens after that initial plan varies but usually the process is to get as much information as possible out of my head and on paper so I can use this information to start building a skeleton. The gaps that form might be areas that need additional reflection, need more education or a sign that the model I based my skeleton on is flawed. Finally I try to summarize everything in a way that's easy to come back to and that helps me remember the most important ideas from the reflection.

Or a better structured description:

• I have a topic
• I create a big set of questions
• I try to answer these questions
• I sort and group the answers
• I prioritize and trim the groups
• I create a skeleton where the most important answers fit
• I add the other relevant answers to the skeleton
• I try to visualize the skeleton in a way that matters to me
• I trim away the last parts that just don't fit or aren't important enough
      

Example

Last summer I wanted to "relearn myself" to help me figure out what I wanted my future role and career to be like.

The result:
English | Swedish

Behind those simple images are roughly 20 pages of notes on paper, a 14 page text document on Google Docs and various drafts with different approaches on how to summarize and visualize this.
   

Deconstruction

A more specific form of reflection I use is deconstruction. What I mean with deconstruction is basically to create my own, basic model of something.

In practice I start with the question "what does <topic> mean to me?". To be able to do this I need at least some level of understanding already. After this I iterate the following approaches over and over again until I start to see a clear pattern and/or feel like screaming "Eureka!":

1. I try to form my own definition and question it relentlessly until it seems to hold true (for me)
2. I collect and look carefully at all the details that makes up this topic looking for patterns
3. I remove or group things together until I have 1-5 distinct groups which each (hopefully) describes a core concept.
4. I look at the topic and simply ask: What is actually most important here?

To give you an example of a deconstruction:
Helena Jeret-Mäe suggested we would together create our own definition of software testing. According to my memory we first tried to just modify existing definitions but that didn't work. So instead we started describing what testing meant to us in a very detailed manner. After we had done this for a while we started removing anything that didn't seem essential to these descriptions, which actually made us go down several very distinct paths of what testing might be (this particular part taught me a lot). I think we had to go back and redo the description at least twice because what was left after we had trimmed the long description just didn't make sense the first few times.

After a while we had a very rough "definition" based on the trimmed down description and started questioning the wording, tested it against different scenarios etc. After a bunch of iterations like this we ended up with something pretty close to the definitions described by many of our heroes. 

This may sound anticlimactic but the outcome is not what was important...

So why is deconstruction useful to me?

• First and foremost the deep understanding I get of the topic is unmatched!
• The core I end up with often form an excellent structure to tie future knowledge to and even if it may look similar to existing definitions or models this core is something I understand beyond the words' linguistic meaning.
• This new structure allows me to ignore large parts of e.g. frameworks since I just need their core concepts and practices and then I can map them to my own structure which also makes the frameworks easier to remember and easier to compare.
• It provides a foundation I actually understand when I try to explain the topic to someone else.
• It provides a plausible answer to "any" question (assuming my deconstruction is somewhat valid) since I can derive an answer from my model: "for my deconstruction to be correct the answer should be...".

Obviously I have to test my deconstruction carefully to see if it actually holds true (enough) or at least learn its weaknesses. This means the deconstruction I did with Helena 2014 is something I trust a lot more than for instance the deconstruction I did of coaching just about a month ago.
   

Reflection as a reaction

Most of the reflecting I do happen as an immediate reaction to something rather than as a planned activity though. For instance I might prepare a presentation and realize there's a gap in my understanding. Instead of searching for an answer online I can stop and ask "what's missing here", more often than not I have a sufficient answer myself.

Examples of activities that force me to reflect like this are:

• Exercises
• Discussions
• Explain something (teach, present etc.)
• Prepare a presentation or exercise
• Summarize
• Apply something to a new situation
• Review something
• Help someone else with something

The drawback with reflection triggered this way though is it usually only makes me answer one specific question and these answers rarely results in action, just information.
    

Self-coaching

I've used coaching questions and techniques as part of my reflection for a long time and called this self-coaching. As mentioned several times now; this blog series have made me realize though that I could use the complete coaching structure I've learned to initiate a full coaching session with myself including follow ups on my actions.

Back to the overview

     

Next step

After a colleague pointed out I'm not 29 years old anymore I had to revisit my About page. While reading the rest of the text this sentence made me stop...

Next step is to spread the knowledge I've obtained and be a thinking practitioner who can hopefully do what James once did for me.

I wrote that sentence over 4 years ago, before any tester outside Linköping knew I existed. So I took a moment just to reflect.

"Spread the knowledge I've obtained"
I've been teaching students in Software Testing at a vocational university for 1,5 years, I've given numerous lectures, presentations and workshops on various topics at conferences (national and international), meetups and at my workplaces and I'm now test coach at Verisure, a role in which I'm basically paid to share the knowledge I've acquired so far. Finally I've, for most of the period, been a fairly active blogger.

"Be a thinking practitioner"
Transpection Tuesday, my blog, my peer conference appearances, my many dinner discussions with top notch testers (most recently Göran Bakken), my (former) activity on Twitter all add to the "thinking" part while my testing and test related experiments at Ericsson, Verisure and Zenterio, as well as my effort during Software Testing World Cup all add to the "practitioner" part.

Most important though: The two are not separate processes. The best example of this is probably Transpection Tuesday. During Transpection Tuesday, Helena and I often discuss a challenge one or both of us have, together we work out potential solutions or experiments to run, we go back to work to try these solutions/run the experiments and finally we share/ask for help to evaluate the results at a second Transpection Tuesday. Like I said, one process.

"Who can hopefully do what James once did for me"
After graduation I got emails from two former students, both made me feel I've accomplished exactly this...

... hmm, is it raining inside or why are my eyes moist all of a sudden...

On top of that other former students, testers and other colleagues (most recently a developer) have all helped me understand my efforts to inspire, guide and mentor have actually made a difference.

It's not without pride I say: In four years I've wildly exceeded my own expectations based on my memories of what I hoped to achieve 2012. Not just my expectations for the next four years but potentially for my whole career. Shit... I need a break.

... pause music...

What's my "next step"

Took quite a bit of thinking but here's my updated "next step", or mission if you prefer that:

I've presented to, spoken with, inspired, coached and mentored testers in testing and quality. I want to continue this but to a broader audience, in ways different from what has been done before and inspire others to present, speak, inspire, coach and mentor as well.

Clarification:
Broader audience refers to e.g. developers, students (not studying testing), managers etc.

If you happen to read this in few years, do remind me to report my status, please.

What's your "next step"

Enough about me, what's your next step?

Why we need realism in testing

I was sitting on the train. As the train attendant passed a woman right behind me called out "Excuse me, is that ticket reader from 2013?".

- I'm not sure, why do you ask?, responded the train attendant
- Well, this morning I noticed the train attendant's ticket reader seemed very bulky so I called the railway company and they rudely told me it wasn't a problem anymore since they had upgraded the model in 2013. So I was wondering if that's the new or old model.
- Well, I don't think there's a newer model but honestly I don't know, what I do know is this one is at least not built for me.

They started talking about various problems the train attendant and her colleagues had experienced. Of those these seemed to be the biggest ones:

• The device was made for much bigger hands than most train attendants'.
• The device was way too heavy.
• The device was tough to get a grip around and maneuver, probably even if you had "right sized hands".

The most alarming result was the amount of people on sick leave had grown notably since the current ticket reader was introduced, according to the train attendant, and the main reason was reportedly over-stretched arms.

The biggest issue with the current ticket reader seemed to be the humongous battery on the back. At this point I had curiously joined the conversation and commented that the battery's size seemed unreasonable knowing even several years old, cheap, small smartphones had batteries lasting for days doing much more complex tasks. The response to that was quite telling:

- The one we had before was much easier to carry but the battery didn't last long enough.

At this point I suspected two things:

1. Someone was informed: "We need to improve the battery on our ticket readers". Armed with that information, this someone wrote a spec saying "same functionality but better battery" and the humongous battery was the quick fix, a seemingly identical device but with more power. Implicit requirements such as "it should weight a maximum of ... grams" or "it should fit the hands of our train attendants" was most likely not considered.
    
2. Whoever tested this didn't test it under realistic conditions such as for many hours, trying to reach over other passengers, walking long distances carrying it and so forth. Another possibility is the casing and hardware was "just an ordered standard third-party device" (probably not built for this specific purpose) and all focus was on the software. A third option would be no testing was done since it was "just a change of battery, which will not change anything to the device, only improve it".

I'm still very curious if any acceptance testing was done by the railway company. If so, under which conditions, for how long and by who, actual train attendants? If not, why not? (I can list many plausible answers but still curious)

Continuing the conversation the woman initiating it started to list a few simple ideas, just from the top of her head, that could had eased/solved the problem. My personal favorite was: "Why don't design it so that the battery pack is in the belt". That seemed like a minimum effort, low cost solution to both the old and new problem. Knowing the current state though I suspect the manufacturer would probably had delivered a too short power cord.

I thanked this wonderful women who asked the question, as well as the train attendant. I got a valuable reminder of how important "dogfooding" and testing a product under realistic conditions are, as well as a good reminder of how much you can learn from just being curious.

My message with this story: Yes, it's often inconvenient to figure out and set up realistic conditions when testing but failing to do so can be catastrophic. As the train attendant pointed out: "Some days when my arm is aching I just look at the tickets and assume they are valid".

Update

Here's an image of the ticket reader. Notice the battery (bottom left) and how it obstructs a "natural grip" around the device. This train attendant also had notably larger hands than the train attendant mentioned in the original post (two different train attendants) to further emphasize the problem.

Finally, when I snapped this picture the train attendant immediately responded: "Are you gonna get us a better ticket reader?". Pretty telling comment.

The year I became a passionate tester, part VI

December
The only (but really cool) event that occurred was Securitas Direct/Verisure's christmas party. It was hosted in their beautiful office in Malmö. Can't say I'm jealous, I mean, who wants a workspace with ocean view in three directions? Well, maybe, at least I got over it and had a great time with future colleagues, including one of the two guys who'll be on my dream team in Linköping (not putting pressure on anyone). The only new year's resolution I'll make by the way is coming dressed up next year (costume party).

Apart from that, December was mainly a month of reflection, Twitter and family life. Via Twitter I started to get in contact with some really cool testers like Jari Laakso, Kristoffer Nordström and Jean-Paul Varwijk. Via reflections I started to grasp/understand/better appreciate my progress as a tester this year (reason for this blog post series) as well as wrap up the work done by me and my colleague at Ericsson. Cool things that need separate post(s) to really do them justice.

Wrap up of 2012
So, 2012 was an amazing year, when it started I considered testing being an activity that mainly demanded endurance, patience and the ability very rigorously read technical documents (all skills/traits/knowledges I'm definitely not famous for, at least not in a good way). Now when 2012 has come to an end I value a whole bunch of other skills/traits/knowledges instead like observation, creativity, general system knowledge, analysis and communication. I now find testing adventurous and exciting rather than a repetitive routine work.

I've also met a ton of amazing people! Some have been thanked already but of course there are tons of you who I've not even mentioned. I will not attempt to list you all, instead THANKS TO ALL OF YOU WHO, IN ONE WAY OR ANOTHER, HAVE HELPED ME ON MY JOURNEY!

Some special mentions left to do:

EAST
EAST is a local open network (Linköping area) for testers, started by Johan Jonasson and Johan Åtting. When I started to look at its role in all this I realized:

• EAST was the place there I got convinced I needed to attend RST.
• EAST was the reason I picked up LinkedIn and without LinkedIn I would not had come in contact with Maria Kedemo (new job).
• Speaking about job, I met Johan Åtting via EAST, that was the other amazing job offer this year.
• EAST was one of the big reasons I started blogging (first test related post is about my first EAST meetup).
• Johan Jonasson, Johan Åtting, Joel Rydén and other EAST participants have all been role models and sources of inspiration, key to last year's events.
• EAST became the crucial link between the testing world existing at my work and the testing world existing in the rest of the world.

I could go on but let's just say I'm forever grateful for EAST and I hope I can inspire/help other participants to start similar journeys. Thanks to all who have participated or in other ways contributed!

Blogging
Starting 2012, blogging to me it was more or less just a poor narcissistic attempt to make something hopelessly uninteresting, interesting or it was something used by the top elite within a business to share their ultimate knowledge about something. At the end of 2012 I tell everyone who wants to progress to blog, not for anyone else's sake (that day will hopefully come) but for their own personal development. Blogging has taught me the value of reflection, greatly improved my ability to put thoughts into words (which is essential to understand, analyse and explain something), it has generated new perspectives, changed priorities or given me a more sensible view on some things, it has improved my English, my writing skills and my "technical storytelling".

Later when some of my blog posts became interesting to other testers it became a great way of getting in contact with other testers, getting feedback and acting as a portfolio. From my heart I urge you to try it out, not, to repeat myself, to become famous but to develop yourself!

Work
I undertook an amazing adventure at work that just didn't fit the format of this series. It didn't include dragons, fairies and elves but, considering how we traditionally have worked with testing, it sometimes felt just as exotic. Some day I'll blog about it but for now I just want to thank my other partner in crime, Saam Eriksson, a passionate, smart tester I hope will continue and further improve our work now when I leave Ericsson (3 working days left). You've meant a lot to me and my development this year Saam, thank you!

Everything comes with a price, dearie
24 hours a day, that's one of few hard constraints we have in life. During these hours we should rest, eat, take care of family and friends, work, take care of ourselves, develop/follow dreams, follow through on commitments, manage everyday activities (pay bills, clean up, get to and from work etc.)... and probably other things I've missed. This constrain is a huge pain in the butt, especially if you, like me, have very many things you love and want to explore.

A few thoughts and lessons from 2012 about managing this puzzle:

• If you have kids, make sure you put them in the center of the puzzle.
• The puzzle won't (in a good way) solve itself when there is an overflow of activities.
• Each piece can be optimized (value/quality per time unit) by observing, reflecting, analyzing and prioritizing, but you need a balance there as well (premature optimization is the root of all evil, you know).
• The usually extrovert me quickly becomes introvert (not in the positive way) when I don't feel I have enough "me-time" and that affects all parts of my life.
• It's easy to be blinded by your own passion but don't forget there are other things in life like friends, family and yourself.

I survived the end of the world, here I come 2013!
This year couldn't have come to a better start as my two fantastic boys got the most amazing little sister 11:10pm, January 1st.

Things I know will happen 2013:

• New amazing job at Securitas Direct/Verisure!
• Let's Test 2013!

Things I feel motivated to do now and thus might do during 2013:

• BBST Foundation course
• Reclaim my presentational skills
• Connect with more testers on Skype
• Figure out how to get more out of reading (or start prioritizing other learning activities over reading)
• Be a speaker at some testing conference
• Try Skype coaching (as a student, had a taste of it thanks to Peksi)

Things I aim to continue with:

• Be an active blogger
• Be active in EAST
• Practice/play/experiment with testing
• Experiment with my learning
• Meet more testers in person

Finally, and foremost, I will continue enjoying my life as a dad!

Blog series wrap up
Thank you for reading this, if nothing else it has inspired and taught me a lot! If you want to start a similar journey like mine, feel free to contact me for help, tips or mentoring using comments on this blog, Twitter (@brickuz) or any other way you figure out.

Finally there are two more people I need to thank:

First, my fiancée. Among the million reasons I have for that; thanks for supporting me, inspiring me and being an awesome mom to my kids! Thank you, thank you and thank you!

Second, myself. This was at times a rough ride where I had to stand up and take responsibility for my actions to be able to continue, make sacrifices, take risks and really challenge both my ego and fears to succeed. Thank... me... for this journey!

2013, here i come!

Previous (part V)
First (part I)

The year I became a passionate tester, part V

November 1st
Worth a special mention. The day was crazy for several reasons but three highlights:

1. Securitas Direct asked for a second interview
2. Invited to SWET 4
3. My note taking post was retweeted by Michael Bolton (may sound silly but it was huge to me at that point)

RST (Rapid Software Testing)
RST started great, I was on top of my game, asking relevant questions, thinking, observing, reacting... all until the first break. I don't know exactly why but I lost track after that (had a great time anyway but was not happy with my own contribution to that).

When apologizing to James he responded:

I was going to say you should talk more.
First thing tomorrow you'll see something you haven't seen.
...
Well, don't worry about... or worry if you want, because I'm going to have you do the Mysterious Sphere problem.

I immediately scanned google, RST blog posts and other resources but found nothing.

A good ten hours of sleep made the trick and day 2 I was on top of my game again! Just before lunch James turned to me and said something like:

After the break we'll see Erik here, test the Mysterious Sphere, the only exercise that has made anyone cry during my class.

It was amazing! I still go "Ohhhh! That's why... I should have... what if... now I get it!" when I think about it. I'm forever grateful I got the chance despite my bad start!

Day 3 wrapped up an amazing experience! I left RST with my precious blue pouch (RST graduates will understand), new contacts, a raised confidence in myself as a tester and 21 pages of sketches, ideas and epiphanies. Thanks James Bach, Tobbe Ryber, Robert, Niklas, Per, Tiago, Layer10 and all the others that made this experience possible/invaluable! If you haven't participated yet I suggest you check out David Greenlees post on how he got to RST and schedule a meeting with your your boss!

Get the most out of RST:

• Get there well rested (important!), the course will demand a lot of you.
• Look up the word heuristic to make sure you understand it.
• Show you want to be challenged (be active), it'll make the course even better.
• Check out the RST slides before, I think that helped me stay focused on the discussions.
• Don't care to print the slides and bring them to the course though, as slides will be skipped, order changed and the exercise slides are hidden anyway.
• Faking will only lead to problems.
• Read up on the Socratic Method (a low pressure example, expect more "pressure" in class)
• Make sure you know how to get to the facility, have travel tickets in place etc.
• Ask questions!
• Drop the idea of finding the ultimate answer to the questions asked (important!). Most questions will not have one! Accepting that will help you both learn and contribute more.
• Don't worry, things will just happen and you'll do great!

Thanks to Johan Jonasson, Joel Fridfjäll, Joel Rydén, David Månsson for contributing to the list together with James Bach, Michael Bolton and Paul Holland.

SWET 4: Intro
Please read Johan Jonasson's great post on SWET 4 for details on the event. Maria Kedemo has also shared some thoughts, especially check out the "what happens now" section, great reading!

After receiving my invitation I called Johan Jonasson:
- Am I really qualified for this?
- Go there and find out!

It was amazing! The presentations were interesting, the following discussions even more so, the lightning talks were cool and the people inspiring, I had the time of my life!

A funny thing: Maria Kedemo was presenting "Model based exploratory interviewing" or, in other words, her interviewing model when recruiting testers for Securitas Direct.

On the topic of switching roles: SWET started 2 days after RST ended, felt a bit weired to go from being James "unknown student" at RST to become his "peer" at SWET. Weired as in a good, interesting way I should add.

Want a quick reason why I think Securitas Direct and Sectra are two great companies for testers by the way? Both companies' test managers were among the 15 invited to SWET 4 (Johan Åtting couldn't come though and sent Joakim Thorsten instead).

I need a separate post to describe this crazy experience in any detail but one advice: If you ever get the chance, take it! I was really intimidated by the concept and merits of the other testers but as I arrived I quickly understood why great testers love peer conferences, you (can) learn so much! Going was definitely one of the best decisions this year!

One final advice: Prepare your lightning talks, I changed topic ten mins before walking up, the result was messy.

Special thanks to Torbjörn Ryber, Henrik Emilsson and Rikard Edgren for arranging this amazing event as well as giving me the chance, and thanks to Martin Jansson, James Bach, Sigurdur Birgisson, Sandra Camilovic, Anna Elmsjö, Johan Jonasson, Maria Kedemo, Oscar Cosmo, Saam Koroorian, Simon Morley, Joakim Thorsten... and myself... for helping them make it amazing!

New job
After interesting discussions, cool exercises and talks to potential future colleagues it was time to make a decision. In the end it came down to details; both Securitas Direct and Sectra have amazing testers, culture, test managers and products. Finally I decided to go for Securitas Direct choosing, what I interpreted, as the bigger challenge over Sectra's more helpful environment (all but one tester at Securitas Direct work in Malmö, not Linköping where I work).

Anyway, I think Joel Ryden (brilliant guy, test consultat at Securitas Direct and former employee at Sectra) summarized my situation quite well: "Whatever you choose it'll be a great choice". I'm thrilled to start my new job at the end of next week, something I'll talk more about in a later post!

Jiro dreams of sushi
This documentary is great enough to mention here. Watch it!

Kids
Finally... kids can smell when you really need sleep (like the day before RST and SWET). But at least that gives you a lot of time to hug them before you leave. Jokes aside, coming back from SWET 4 having my two boys rush into my arms was by far the best of all the cool things in November. Be passionate about testing but remember what's most important!

My boys pairing up to test/hack/crash a tablet.

Summary
November was crazy, feels like I've just mentions half the cool things that happened! Anyway, three key take aways:

• Don't worry about if you're good enough or not, just get out there and learn until you are!
• RST is a mind-blowing course that I recommend to every tester!
• Practice putting thoughts into words (blog, reflect, join debates...), it's a critical skill to anyone, not just testers!

Starting level: Prepared
Finishing level: Self-recharging bomb of inspiration

Previous (part IV)
Next (part VI)

The year I became a passionate tester, part IV

October
I've covered January to September in three posts. October and November however were way too eventful to keep that tempo so this post will only cover October... just in case you're puzzled by the headings (they are not months in some ancient calender).

Work opportunities
With two days apart, immediately after I had made myself available to job offers, I was contacted by possibly the two most interesting companies I could think of (from what I could tell; great culture, interesting products, passionate testers, top notch test managers and the right location). First Maria Kedemo, test manager at Securitas Direct, asked me to consider a job opportunity they had announced several months before but not found a candidate for yet. Second, Johan Åtting, test manager at Sectra, and I had a discussion regarding my RST situation. Somewhere in that discussion he asked me to send an application. I was on cloud nine! I'll tell you how it turned out in part V...

Some thoughts on improving your chance of getting great job offers:

1. Learn to test
   Practice, practice, practice
   Explore, experiment, play
   Read, watch and listen to great testers
   Get a mentor or ask for coaching
   Ask for help when you need it
   Courses, webinars, books
2. Create a portfolio
   Start a test blog or website
   Share your story (or CV if you're boring like me)
   Share your work and experiences in whatever way you prefer
   Create a LinkedIn profile
   Create a Software Testing Club profile
3. Broaden your network
   Be active in your local test community
   Socialize with testers on Twitter
   Start connecting with testers on Skype
   Go to a conference
   Be open to receive mentoring, help or coaching
4. Get some reputation
   Be a presenter
   Accept challenges (like testing puzzles)
   Mentor or coach testers
   Answer questions on, for instance, test forums
   Make relevant comments on blog posts and articles
   Host a meetup, conference or similar

Course
Instead of the Rapid Software Testing course, my employer sent me to a centrally purchased course, arranged by test researchers from MDH. As I didn't share the course instructors' opinions about testing it provided a great opportunity to practice challenging ideas as well as arguing for my own. Some examples of things I challenged was that a model had to be an actual simulation (James Bach would go bananas if he met the instructor for that part of the course), how exploratory testing is presented in the agile testing quadrants (see picture below) and the idea of having automation as a goal. To give the course some credit, it did teach me the theory and formal names on some stuff I already used, like equivalence partitioning.

The agile testing quadrants, I stay skeptical to this...

In the end I got a certificate which I would have received even if I had sat quiet, understanding nothing, for four days (unrightfully it wasn't in endurance).

Some thoughts on how to get more value out of a (testing) course:

• Ask questions as soon as you don't understand something or how something is relevant
• Reflect on why you disagree with ideas presented and try to express it (challenge)
• Practice constructive feedback on the instructors
• In your mind, try applying the ideas presented to your own context, does it make sense? Why not? Can you think of a context where it does?
• If you have a colleague attending the course, reflect on its content together afterwards
• Experiment with the stuff you've learned to make it stick

My first hosted local meetup
I had joined all the EAST meetups since I first heard about the group in May but, apart from calling to a pub evening, I had not hosted a meetup. That changed in October as ~20 testers gathered in a conference room at Ericsson discussing testing in an agile context, CAST 2012 and various other topics. Apart from almost having to squeeze in 20 people in a room designed for 8 and giving everyone the wrong address, it all went smooth. Definitely something I would like to do again.

Some thoughts on facilitating a (local) test meetup

• Facility: restaurant/pub, talk to your employer, check for a sponsor
• Inform: colleagues, other contacts (use consultants), LinkedIn, Twitter, flyers
• It's always nice to have at least one friend/colleague you know will show up
• Use any existing group (if no test group is available use an agile, craftsmanship, developer or other similar group) to spread the news
• Scout: attend other meetups (test related or not) and conferences
• Content: some (emergency) discussion topics are nice
• Content: watch an online presentation together is an option to a live presentation
• Don't worry about what people will think. The initiative is more than enough to please most!
• Make things interesting by experimenting!

The blog post
To prepare myself for RST I did, as I often do, experiment with a way to practice what I wanted to learn. The big difference this time was I blogged about it (Practice: Note taking). I had not anticipated the response. People retweeted it, started following me on Twitter (well, some quit after a while but anyway .) and old posts suddenly had their number of reads doubled and tripled.

Some blog tips from a newbie (most based on other blogs I like rather than my own):

• Share your experiments
• Share your experiences
• Share your mistakes
• Share your problems and ask for help
• Share your insights
• Share your ideas, but putting them into practice first will probably be more appreciated
• Be brief
• Tell a compelling story
• Don't force-feed people with your posts, especially your not so great ones
• Ask yourself: How is this relevant to someone else?
• Ask yourself: Why is this important to me?
• Use pictures/visualizations to communicate more (I'm great at this when presenting, I suck at it in my blog)... it's also more fun.
• Uptight blog posts are shot on sight, relaaaax, it's sexy to be vulnerable. 
• A blog post is an efficient tool to help reflecting (this was an amazing experience for me)
• Use headings and lists to make stuff more readable / easier to get an overview

Pekka Marjamäki
James Bach praised "Peksi" during an RST course in Finland so I looked up his work, was impressed and started following him (blog and Twitter). Soon after he found my Why I've signed up for RST instead of buying a kick ass sofa and new computer post and he contacted me asking if I would like to try an exercise as a warm up for RST.

The exercise was about him claiming something (in this case "Programmers can't test their own code") and my work was to, by only using questions, convince him he was wrong. I didn't fare that well as the mission goes (I had a strategy, that he gave me credit for, but let's just say it wasn't efficient) but I learned tonnes! I am forever grateful for his help and I hope we can do something similar soon again!

Finally I think Peksi's initiative says a bit about the context driven testing community in general. If you want to develop as a tester, just reach out and people will help you! To me there seems to be more teachers than pupils so help out by asking for help.

A few ways to get in touch with great testers

• Twitter
• LinkedIn
• Local meetups
• Conferences
• Comment on blogs
• Write interesting stuff in your own blog
• Colleagues
• Software Testing Club
• Skype

Summary

October was in a sense a preparation step for the events in November, but as you've hopefully acknowledged by now: the journey is just as important as the end goal. See you in part V!

Starting level: Committed
Finishing level: Prepared

Previous (part III)
Next (part V)

The year I became a passionate tester, part III

This is the continuation of my 2012 reflections series, reading part I and part II first is recommended.

The great adventure you will not hear about
My greatest adventure this year is the journey from a heavyweight to lightweight test process in my team at Ericsson. However, that story just doesn't play well with the month to month format so I'll save that to some rainy day in a distant future. However here is the 10 second version and I'll also provide you a few lessons learned at the end of this post:

1. I tried to introduce exploratory testing
2. I screwed up badly
3. I finally started reflecting on my work
4. I started to turn things around
5. I became we
6. We kicked ass, testing was more fun than ever
7. People (at least some) started to take note
8. We kicked ass, testing was better than ever
9. We started preaching about what we thought was amazing
10. Job finished, result was, we believe, a heck of a lot better than traditionally (talking quality of test, motivation and how much we learned).

July and August - Making promises
Mostly vacation, a lot happened but only one thing suited for this post.

After having my RST (Rapid Software Testing) course request put on hold over and over since May, with no good explanation to why (came later), I promised myself two things if the request was denied:

1. Make myself available to job opportunities
   
2. At least look into the possibility of paying the course myself.
   

September - The final no
Early in September I told my fiancée I wanted to attend RST, with or without support from my employer. She simply answered "if that's what you really want, I trust your judgement" (I love my fiancée even more sometimes).

When I finally got a no from my job I simply requested vacation and registered myself for the course and it actually felt exactly that easy. I felt ecstatic for so many reasons:

• I had signed up for RST, the course I wanted to attend so badly!
• James Bach was the person inspiring me to start this journey, having him as instructor meant tons to me!
• I had proven to myself that I was really committed to becoming a great tester!

The countdown had begun...

Insights so far
Not too much of interest in July, August and September, instead, let's look at 3 useful insights from the adventures at work.

Schedule time for reflection
Continuous reflection is key to keep you on track but I noticed the more I drifted off course the less I naturally spared time to reflect. One change that rendered great results for me was scheduling time for reflection. In my case I dedicated 1 hour per week where I dropped everything and just focused on what I was doing, issues, what my current direction/goal was and making models...

Visualize what you're doing
One of the turning points, going from chaos to success, was when I created my first visual model of what I was doing. The model was simply a timeline (for the feature/deliveries) where I started to add all the activities I was doing (without details). From that model a new one occurred; a model describing how I wanted to work. That model could easily fit on a paper and became our central tool when describing our work, discussing improvements and when reflecting in general. The model also helped me explain what I was doing better. In retrospect I think making a similar model based on how we use to work would have made the model even more powerful.
Also, the moment we could visualize our status, coverage and plan (spreadsheet with some fancy additions, can't talk about content though), our credability went through the roof.

Challenge your own ideas
One exercise I've found useful is simply to defend things I believe in against a ferocious attacker (either played by myself or, even better, a colleague). I've found it useful not only to evaluate ideas but also to improve my understanding of them, practice arguing and put thoughts into words.
Example:
- We should stop enforcing testers to document test scripts it's way to expensive.
- But what happens to traceability?
- We never use scripts when we check back on previous work, a well written title is enough. 
- But we save money each time we reuse a test case!
- That's a great idea but in reality we rarely reuse test cases since it's quicker to write new ones and also the product still changes too rapidly to make tests valid even a month later.
- But it's a great way for new testers to learn how to test!
...

Starting level: Inspired
Finishing level: Committed

Previous (part II)
Next (part IV)

The year I became a passionate tester, part II

Please read The year I became a passionate tester, part I before you read this post.

May - Reaching out
When I was young (about two years ago) I started a blog. It was in Swedish, the topic was "make me famous" and it was gaping empty. In May I decided to pick it up again so I started writing a few posts, cursed myself for not being a brilliant writer anymore and finally translated the least horrible parts to English. My hope was that writing would somehow magically improve me as a tester and make people love me (I keep presenting myself as the loneliest man on earth).

The latter didn't really work out, the former though, even with the lack of magic, was spot on!

• Putting thoughts into words is a crucial skill! I'll explain why when we get to November but for now, just shut up and believe me.
• Helps you spot gaps and problems in your reasoning.
• Helps you raise questions you previously weren't aware of.
• Great practice to become a better observer.
• Great practice to better present your results.
• The comments you get can be provide key insights.
• Helped me learn to write in a more concise way.
• When writing down a problem the solution has a tendency to just show up (a bit like when you ask someone for help and as you put the problem into words you realize the solution... but without the someone).
• A good blog is great to point at when applying for a job.
• Writing skills are always important.
• Helps you process things you've learned/experienced.
• Helps you realize you're progressing.
• Writing a post you feel really good about helps boosting motivation.
• Sharing your experiences will put you in contact with interesting testers.

A few links if you need more encouragement
Why Every Professional Should Consider Blogging
Writing a Technical Blog: Why to do it and what to write about
Why must you write a technical blog?
7 Reasons Why Blogging Is Still Important in 2012

But the blog was actually not the most important initiative in May...

I chickened out on Let's Test but thanks to that conference I started following Johan Jonasson. One day, late in May, he made a retweet that would completely change the rest of this year. The tweet was about an EAST meetup in June. I joined the LinkedIn group and signed up...

June - Meeting non-imaginary people
EAST is an open network for software testers in the region I live in (Östergötland, Sweden). Once a month they meet up to listen to presentations and discuss testing in general. Going there was amazing! For the first time I was surrounded by brilliant, passionate testers, just the kind I wanted to become myself. Even though they gave me serious Let's Test envy, not to mention Rapid Software Testing envy, I loved every second.

Taking the step to meet others weren't really intimidating to me but, since I'm aware I'm an extrovert, I imagine it would be the challenge of a lifetime to some. If it's any consolation I was greeted warmly and helped along the moment I stepped through the door and I'm sure that's what most meetups look like. If still intimidated, try getting a colleague to join as well. I can tell you, if you make it there, it will change the speed you progress and your motivation in ways you can't imagine! Even if you just go there and listen you'll pick up so many interesting insights just from how great testers talk about and approach testing. When you build confidence enough (or, as in my case, can't shut up) you'll also discover a great chance to get quality feedback on your own problems as well as the power of having your ideas tossed back an forth between smart people. Finally, making friends that have a great interest in what you do for several hours a day is kinda awesome.

... Ohh, one more thing I forgot to mention. Other testers will love to hear about what you do, what you've experienced and how you deal with testing at the company you work so don't worry about being the quiet one, no one turns attention to, people will (maybe that was more intimidating than encouraging).

Other meetups in Sweden (Please send more suggestions)
SAST, Stockholm, Göteborg, Malmö, Örebro, Värmland
Passion for testing, Gothenburg
ConTest, Malmö

Inspired by the meetup and a brilliant presentation by Tobbe Ryber (unfortunately the slides seems to have been removed from the Nordic Testing Days' homepage) I created my Skill Development List. First it was just a silly list to make me feel good about my accomplishments but soon it turned into a tremendous resource for motivation and direction. I really urge you to make a similar plan and keep it updated as you progress, it's valuable no matter what level you're currently at! (ignorant people are the only ones dumb enough to ever be done learning).

I'm kind of an eccentric person when I really put my mind into something (like that's not already obvious). So, since i couldn't wait for the summer to end, I tackled the fear of screwing up/be rejected and planned an EAST meetup myself. However I choose a pub instead of a conference room to up the odds of people forgetting any bad parts (worked by the way). It turned out just fine and was a great boost to my confidence! Most important lesson? It's not hard to arrange a meetup, it just takes some courage (the initiative itself is enough be appreciated, a great end result is just a bonus).

Mindset
Hey, mindset is not a month! Maybe not in your calender... Screw it, no it's not, but it's crucial.

My mindset about testing, learning and thinking has changed a lot during this year. Here are some key mindsets that have helped me tremendously:

• I demand certain standards and am ready to fight for and make sacrifices to uphold them. I no longer accept fake work, low quality efforts or unmotivated constraints.
• I'm responsible for the environment around me, I don't expect anyone else to fix it for me.
• I don't fake understanding. Even if a question might hurt my status I need to ask it if I don't understand, simply because I want to be a pro not make others believe I'm a pro.
• I accept challenges even when public humiliation is almost guaranteed because I know challenges can teach me so much.
• I always perform tasks the best I can, even when it's not demanded, because I want to be proud of my actions.
• I accept that, even though proud, I will never be fully satisfied with my results because I will always be on the lookout for improvements.
• I won't accept to save myself by using silly excuses, blame others or hide behind papers! When I've done a bad job I'm accountable for that.
• I will not limit myself by what's considered taboo. If I find great potential for improvement and no one can come up with a valid reasons not to I will practice "professional disobedience" if necessary (break rules, within reasonable limits, to allow going forward).
• I will not pretend I've done a good job just because someone else says so. If I feel I've faked something it's a personal failure, nothing can change that.
• I want to empower and inspire the people around me by helping out, drive ideas, be a role model, spread my knowledge and support good ethics.
• I listen to anyone interested in sharing their experiences and I try to help them build on those but the latter is secondarily to the former.

Most of them are far from second nature to me yet (I still fake understanding and make up excuses for instance) while other more or less are (most notably high standards, which I'm really proud of). When some of these start to become your most important guides all the things around like respect, knowledge, skill and motivation will come by itself and it won't even feel like you're putting in an effort, that's why this is so important.

Insights so far

• The scariest, most challenging actions often present the greatest reward.
• The initiatives you don't take are the ones that will haunt you forever (why didn't I sign up for Let's Test, why?!). Failures? If nothing else they make great stories.
• Share your experiences with others, it helps making valuable connections, get feedback/insights/new perspectives and it helps you learn to explain what you're doing.
• Blog, blog blog
• Great testers won't ignore you, they will embrace you!
• Plan a local testing meetup, it will be educational, earn you respect and is a great confidence booster.
• Passion, inspiration and motivation rubs off, meet passionate people to become passionate.
• The sooner you meet great testers the sooner you'll become one yourself.
• Mindset, mindset, mindset
• Get yourself a plan of what you want to do (Skill Development List) and how you want to act (the list of mindsets further up).
• <<all the items on the mindset list>>

Starting level: Knowledgeable but incompetent

Finishing level: Inspired

Previous (part I)
Next (part III)

The year I became a passionate tester, part I

Prologue
Once upon a time there was a man, or boy, if you want to be rude. He was called a tester but in reality he didn't feel like one. "This isn't fun, I want to go back to programming" he said but his manager just replied: "Don't worry tester, we're going agile soon, you'll get your chance...". That tester was me and this is the story about my 2012, the year I became a passionate tester.

January - The spark
Late in January my phone rang, well it had done so before but that's not relevant to this story: "We need a tester". The company was known to me and even though I wanted to move back into programming it was still an interesting offer. So I dusted off my CV, added "over 4 years of testing experience" and sent it. "We want to book an interview" they replied and I started to prepare myself.

What on earth do they ask during a tester interview I asked myself. Maybe something about test, that seems reasonable. Suddenly I froze. I just told them I have over 4 years of experience but if they ask me a single test related question I was screwed!

In desperation I started browsing the web looking for "easy answers". This kind of approach quickly turned my attention to the ISTQB syllabus and various certification training sites. I started reading and reading and reading and... thinking "Is this really it? Maybe software testing isn't for me at all".

In a last attempt I googled "Exploratory Testing". Bingo! Inspiring articles by testers who actually seemed to like their job appeared, names like James Bach, Michael Bolton and Cem Kaner was everywhere and finally, the great heureka moment, James Bach's open lecture on software testing.

February - The possibility
- We want you to be part of a pioneering cross functional team, what do you say?
- Let me think... YES!

This was my chance to change things! I started reading ferociously and watch presentations like it was IMDB top 100 items.

Some resources:
The little black book on test design
The slides from the Rapid Software Testing course
DEWT: Resources
The BBST course material
Testjutsu: New to software testing? Read this!
The Evil Tester's Guide To Evil
Publications on the Test Eye
Articles by Michael Bolton
Articles by James Bach

RSS (no particular order):
Jean-Paul Varwijk
Alan Page
Michael Kelly
Andy Glover
Maria Kedemo
Kristoffer Nordström
Michael Bolton
Ajay
Alan Richardson
Iain McCowatt
Aleksis Tulonen
Sigurdur Birgisson
Pekka Marjamäki
Huib Schoots
Ilari Henrik Aegerter
James Bach
Karen Johnson
Paul Carvalho
Johan Jonasson
Markus Gärtner
Anne-Marie Charrett
Jari Laakso
Bruce McLeod
Petteri Lyytinen
Elisabeth Hendrickson
Eric Jacobson
Jon Bach
Shmuel Gershon
Ben Kelly
Rob Lambert
The Test Eye
Torbjörn Ryber
Geir Gulbrandsen
Maaret Pyhäjärvi
Darren McMillan
Pradeep Soundararajan

March - And so it began
My phone rang again (I must be a very lonely man based on how well I keep track of this): "I'm sorry but there's a central recruitment stop issued by our headquarters in Austria". I had almost forgot about the job offer so I didn't bother too much.

Instead the new team was formed at my current work.
- Am I the only tester?
- ... for now.
- When will the other one join?
- ... soon.
- How soon?
- ... soon.

So I was on my own, armed with an unhealthy level of willingness to change. Stuff was added into the test process that I didn't understand, stuff was removed I didn't understand the consequences of and others probably looked at me and thought: "He'll be the death of this team". Despite all this code was written and testing was performed (maybe not really in March but... stop interrupting me, this is my story!). I didn't really have a plan for how to know what I covered or how far I've come or how much was left or... anything else, but faults showed up and everyone was happy.

April - All hail the Twitter bird
I started an account already the year before but it was in April I really started worshiping the Twitter bird. This was a great leap forward! Twitter was like sitting in a corner forcing really smart people to spoon feed you with great stuff (at this point I only read others' tweets, I didn't contribute). When I found out you could see other users favorites... I reached cloud nine! Now I had an almost unlimited stream of articles, presentations and epiphany quotes which all were my favorites' favorites.

Insights so far

• RSS is a great way to stay updated
• Twitter is amazing
• Browsing great testers' favorites in Twitter is amazing++
• Knowing ways to work with test is easy, understanding how to use them is complex, but necessary
• There exists tons of crappy testing articles, stay critical
• Best practices is a myth (at least in testing)
• Few testers have any formal education in testing
• Few managers know anything about testing
• "People" think they know more about testing than they do
• Too many believe testing is simple
• Years of experience tells you nothing about a tester's skill level
• A lot of test processes out there exist to provide managers (or similar) a feeling of control, not to support great testing.

Starting level: Zombie (sort of)
Finishing level: Knowledgeable but incompetent

Next (part II)

Using Fun as your guideline

This post is rewritten, please read the new guided by fun post first.

Very interesting statement from colleague after my presentation on Exploratory Testing long ago:
Documentation is generally not fun, so focusing on fun would leave us with chaos

Last spring I started on a new team as part of an organizational change. The goal was to create something less cumbersome and depressing than our current waterfall implementation. In our old way of working tester's have had time to prepare detailed test cases with instructions and god knows what information.

Things just went bad. We were standing in a situation where a poorly written strategy was all we had while code was handed to us: "Please test so we don't have to wait for months before faults are discovered and we have to dig into code we already dislike" (like we did before) plead the programmers.

So we did the only reasonable thing: We tested, we tested and we tested. Life was great! No public documentation! Success!

Time went by and the first hand over was made between me and the other tester in the team due to vacations. Chaos! I knew to some extent what was tested but I couldn't really say if anything was "done". Soon after he handed the work back to me as he went on vacation. Chaos once again. The team even started to ask us for test cases just to get some kind of idea of what was tested.

Was it fun spending all our time testing? No! Why? Because it lead to tons of frustration and a feeling (a well motivated one) of not being professional as we couldn't answer fundamental questions about our work.

Fun as guideline
Today we use fun as our main guideline in our internal test process.

These are our criterias for fun:

• More time for testing = more fun 
• Understanding what we test = more fun 
• Knowing what's been done = basic requirement for fun 
• Knowing where we're heading = basic requirement for fun 
• Being able to answer questions about our work = basic requirement for fun 

To summarize: On top of actual testing (incl. learning anything we need to learn), we put a layer of administration, as small as possible, to reach the basic requirements for fun.

In practice

• More time for testing
  Exploratory testing, removing anything that does not provide value to us, asking stakeholders what questions why want us to answer rather than what documents they want.
• Understanding what we test
  Experience database, ask questions, ask for presentations, involve programmers in testing discussions, read, discuss, pair testing 
• Knowing what's been done
  Test matrix (I'll explain that in a later blog post), SBTM inspired team internal test management (still have a lot to learn about SBTM though) and (at least) weekly test discussions
• Knowing what's next to test
  Compact test strategy, test matrix  and (at least) weekly test discussions
• Being able to answer questions about our testing
  Test matrix, bug tracker, backlog, test strategy

Things we fell we've achieved

• We are more motivated than before 
• We are a lot more efficient than before 
• We know what we're doing to a much higher degree (surprising result!) 
• We constantly learn things about testing and our product (= more fun) 
• Less frustration 
• We understand the code better and can write our own corrections / add testability ourselves more often (in our case this is a bit special since our product supports injecting assember instructions in runtime). 
• The test matrix creates more interesting questions than the test case progress reports ever did (once again: I'll write a post on our Test Matrix later) 
• Minimal waste upon changes. This makes it far easier to work in an iterative way 
• More lightweight administration makes test more available to programmers 
• Quicker feedback to programmers 
• So far we think we've found more important bugs this way, especially important bugs that are indirectly a consequence of what we've implemented (impacts we could not had anticipated) 
• We take responsibility for our testing to a much higher degree ("we probably triggered that case" is not enough anymore, instead we learn how to do it, implement the necessary testability or admit it's not tested and explains why). 
• We've stopped considering issues as something we need to "revert from"/work around and rather consider them as a chance to learn and improve. We've also learned that we can't really know for sure what we actually need before we've lost it a valueable lesson.

Lessons from a one year old - a reflection about reflecting

Some time ago I watched my one year old play with one of those shape sorter toys (put the block through the equally shaped hole to get it into the box). The problem is he's a bit too young so he pretty much tried to bang all the four shapes into the circular hole (which actually worked once for the star shape but that's another story) getting more and more frustrated, especially when all the circular blocks were already in the box. So with a stroke of genius he removed the lid and started filling (and emptying) the box with ease looking up at me to recognize his success. My reaction? "No no no, put the lid back on". A few seconds later I started reflecting upon my reaction. This is the result of that reflection.

Lesson: It's not the receiver's fault when you are unclear
In this case it's hard to know exactly how my son was thinking but looking at his action/reaction my guess is he saw the mission as getting the blocks into the box while my idea was to find the right hole for each block, the getting it in the box was just a proof of correct behavior. So I failed at communicating my model and when he acted according to his interpretation (finding a better solution to my problem) I rejected his solution and more or less degraded him by correcting an error he wasn't even aware of.

Lesson: When someone finds a flaw in what you've communicated, that's creativity, not cheating.
I found this very often to be the case in school. If you are creative, finding a solution not thought of/intended (mostly known as "cheats") you are often rejected. Real example:
In one course we were split into groups and built an autonomous robot. In the spec it said "when hit, the robot must continue straight forward for 3 seconds". So we simply made the robot go forward in 3 seconds (the goal was to send all enemy robots of the arena) but also turned down the speed by a factor of 10 when doing so. My idea of a good reaction reaction from the teacher would've been something like, "Well, you pointed out a flaw in my spec, I'll make a positive note about it but please change back to regular speed forward". His reaction? Something like "Well, now you're just trying to cheat, you know very well what I mean!".

Lesson: You need to monitor if the receiver has actually understood you
When I tried to communicate my view, in this case a very simple one, I failed. Since I just assumed we had the same view I didn't really notice that my kid got happy when the darn block was in the box not when he found the right hole. In retrospect waiting expectantly when he actually found the hole and cheering when the block was in box was not very helpful. Of course my intention was to not reveal the solution but all and all it was just a good intention not good communication.

Lesson: It's important to share the same view
Let's pretend I was in my son's position and could speak. In that case I should have asked a whole bunch of questions, mainly: "Why on earth did you put this stupid lid on the box?", that would have saved both me (him) and the dad (me) the frustration.

Lesson: Models limit our creativity
If someone would have told me to, as quickly as possible, get the blocks in the box I would probably not have removed the lid simply because my model is "blocks go into the box through the holes in the lid". The same task given to my kid would have rendered him removing the lid and hence, beating me. Beaten by a one year old?! Just because I'm too stupid to look beyond my assumptions? And I make big money on my thinking skills every month while he is officially a cost!

Lesson: What's obvious to me is not obvious to everybody else
I didn't even think of the fact that my kid might not share the idea of "how to play with a shape sorter", to me it was too obvious. Of course all, or at least a vast majority, of my colleagues share this view but in that case it could instead be "of course they've thought of handling negative values as input". I think you would go mental if you never were to trust anyone about anything but at least question you assumptions.

Lesson: Assumptions must be under constant review
To ensure we don't end up doing bad assumptions and inefficient problem solving we need to constantly question and review the usefulness and relevant context for the assumptions we make. Since assumptions are shortcuts we fall back on to save us from constant tedious repetitive thinking I guess it's in their nature to be hard to monitor. One thing I find helpful is lateral thinking puzzles, since they by design challenge your assumptions.

Lesson: Courage to question is an important skill
Instead of just going with my idea of putting the blocks through the holes in the lid my kid continued to try to remove the lid. That might not always be the best solution, but at the same time I guess you can excuse a one year old for not starting a sophisticated discussion about our different views on the shape sorter. Anyway, the skill to question someone else's assumptions (and therefore uncovering what might be interpreted as facts rather than assumptions) is an important skill to anyone, one that might get you into trouble in the wrong environment but make you a hero in the right one. If you're in an environment where questioning isn't appreciated you might need to question what you're doing there by the way...

Lesson: Being too helpful is not helpful
I had my best intentions when I corrected my kid and in this particular case it might be useful for him to listen. However helping people too much can lead to less thinking, making them scared to go with their own idea or even stop evolution (as in how solutions to problems can evolve over time). Let people think, let people think and before correcting them, ask why they've gone a certain route, maybe we're more right than you?

Lesson: You need to spot assumptions
Finding assumptions require constant observation. At work I recently uncovered that you could actually simulate a certain type of hardware in our system simply by not just accepting "it doesn't work". Once again, of course you can't spend all your life with trying to question every little aspect of every little statement but to challenge common propositions you've not seen/heard any proof of is, to me, a very healthy behavior.

Lesson: Questions is a tool
Well, I've already touched upon this several times but I think it's important enough to highlight again. Questions are an essential tool that you need to use to clear any uncertainty or ambiguity in whatever someone tries to communicate. "Are you sure that..." is often a good start or, if you really want to be considered a genius pain in the butt, go for "why", "why doesn't it work". Never accept something that seems unclear just because you're too afraid to question or afraid that you'll look stupid (hmm, really nice that I write this as a exhortation to you when I'm one of those who really need to work on this).

The most important lesson...?
"You can learn an awful lot from a one year old"? Well, to put it in a more general context: "You can learn an awful lot by just reflecting on an everyday event". I could have come away with tons of lessons like this from reflecting about virtually anything, how I act when I'm cooking, how me and my girlfriend share work at home, how a colleague react to my bug report etc. You could argue some of this is just associations from associations (not immediately related to the example I reflected from) but I guess that pretty much sums up what thinking is (going from one interesting idea to another). You could also argue that a lot of this is just common knowledge and well, it is, just like it's common knowledge not to eat crappy food, don't make up apologies and go to bed in time, sometimes we need reminders, at least I do.

One final question: What else could you learn from this? Well I didn't even start on the psychosocial aspects, parenting in general, I had a lot more interesting associations to school that I didn't bring up, you could question the toy or how it could be redesigned to better set the rules or challenge the user's creativity... well I guess I need to stop otherwise I won't be able to sleep tonight but there you have some more aspects in case you want to continue .)

So to sum it up: Reflect! It's not just a valuable skill to practice, it can also lead to very interesting results.