I was thinking of a few different ways to do this description. Should it be a narrative to give life to the stone? Should it be a list of attributes to give some sort of unbiased description? Maybe something else? In the end, a mixture of these made the most sense. Too much of one and it is difficult to see what is important in the description. Too much of the other and you get something that is boring and difficult to read. I think that is how it goes with describing software, too.
The goal here is to practice sharing a visual observation I made in a written format. I’ll denote some places where I know clarifications could be made, measurements for example. So here goes…
The overall shape is sort of like a candy corn
The base (wide part) is not completely flat. It angles at about 45 degrees
Because of this angle, one long side is about 1/2 inch longer (or shorter, respectively) than the other
The length is about 2 inches, maybe 2.5 (measurement could be taken)
At the widest point (base of the candy corn), it is maybe 1 inch across (measurement could be taken)
The stone is made mostly of a grayish material but there are small lighter flecks that appear in the surface
The color is a deep gray, maybe slate colored
Color is not consistent, there are some darker spots
The stone is smooth to the touch but not to the extent of feeling glassy
About 2/3 up the stone from the base near an edge, there is a deep, angled gouge in the stone. The gouge almost reminds me of a meteor strike that came from an angle
There is a shallow gouge on the same edge as the deep gouge. This is almost like a small chip in the surface of the stone
The stone feels pretty heavy for its size. It may weigh a quarter of a pound or so (measurement could be taken)
The stone feels very hard. I wonder what it would take to break or shatter it. I may use it in a bonsai pot eventually, so won’t try that out now
There is a hole at the top of the stone that is shaped like a snowman. (difficult to make out in the picture)
Edges of the stone are inconsistent. One long edge is rounded smooth, the other long edge is part rounded and part smooth, and the base edge is rounded at one end and gradually comes to a point at the other end
After describing this stone, I was thinking about how descriptions of software are often used to draw some sort of relationship. A relationship between software and the environment it runs in or maybe a relationship between software and a person. I think I could use this description and some liberal assumptions to talk about the relationship between the stone and its environment. This stone seems like it came from a body of water. Probably a body of moving water. Have you ever gone to a river front that was lined with small stones? Did you notice how smooth some of them were? This stone has similar characteristics so maybe it has origins in a river or lake.
Exhibit A: The stone
7 thoughts on “Deliberate Practice: describe a stone”
I am having trouble putting the deliberate practice concept to use in my job as a tester. I can see the value of the idea. It seems to make sense.
However, are the observational skills you are practicing here really transferrable to the software testing domain? My (limited) understanding of the literature on experts and deliberate practice is that expert skills are very specific and domain dependent, e.g. a chess master is great at analyzing chess games, but not at analyzing things in general. Please help me out here, because I would really like this to make sense and improve my game as a tester…
Reply ↓
Nick,
Regarding your question about whether the type of observation I have practiced here is applicable to software, I think that it is. I chose this exercise for a few reasons: James and Jon Back have a video of them describing a stone and it seemed very difficult, and the natural world is distinctly different from software. It is entirely possible to hone your craft in domains outside of software. To better pose the question (using a Weinberg / Kaner technique), can you think of three reasons practicing observation without using software would be detrimental or not useful to a software tester. What are some other ways you would develop your observational proficiency?
My understanding is that expert application of skill is context dependent, meaning the skill you apply and the manner you apply it may very depending on your context.
–J Rohrman
Reply ↓
I appreciate the thoughtfulness of your reply.
Three reasons why practicing observation without software could be detrimental or not useful:
1. You may be fooled into believing you have developed observational superpowers, whereas in fact you are only getting better at observing stones (great if you are a geologist)
2. You may be wasting time that could be more productively spent elsewhere, or rather to the detriment of other practice/work.
3. The exercise does not make the skill automatic, because the cues for applying it in a work environment are not there. This could mean you learn how to do it, but don’t apply the skill.
Ideally observational proficiency practice should have the character of a drill, so that it I can repeat it to become quick and automatic. The focus is also narrow. Also the context is software testing, i.e. I sit down behind a computer in my office, so that all the cues to apply it are there.
To use a musical analogy, being able to play scales is a very useful skill. Knowing the scales on a piano certainly helps you learn scales on a guitar, because you know what they should sound like, and can use your knowledge of theory to work out them out slowly and deliberately, but it still a lot of effort to learn it on a different instrument and by no means automatic.
Maybe the analogy is wrong…
Reply ↓
I like your music analogy but come to a slightly different conclusion with it. The ability to play scales for a musician is foundational. Understanding of scales will make it much easier to read sheet music and understand music in general. Not understanding scales makes it more difficult to read sheet music and understand music in general. Sometimes there may be direct carry over to an instrument, sometimes the carryover may be more indirect. In either case, the understanding of a scale is beneficial.
To circle back, I think observation and description are foundational skills of software testing. I do not think there is a problem with developing skills used in software testing outside of software despite the fact that carryover into software may not be entirely direct. All testers use this skill, though what and how you observe and describe will vary from project to project.
Reply ↓
Sticking with observation then, I think you would agree it is a foundational skill for driving a car. Yet, I don’t think you will improve your ability to driving a car by observing a stone, or anything else than traffic, more particularly from behind a wheel of a moving car.
Reply ↓
Well, maybe not from the wheel of a moving car… The essence of deliberate practice is to work on a skill without distractions.
I am questioning how transferrable the stone observation/description skill is to observing/describing software.
Reply ↓
Perhaps you can write a blog entry or send me an email explaining why skill sets are not transferable in the sense that my post implies.
Reply ↓
Leave a Reply Cancel reply
Your email address will not be published. Required fields are marked *
You may use these HTML tags and attributes: <a class="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
7 thoughts on “Deliberate Practice: describe a stone”
I am having trouble putting the deliberate practice concept to use in my job as a tester. I can see the value of the idea. It seems to make sense.
However, are the observational skills you are practicing here really transferrable to the software testing domain? My (limited) understanding of the literature on experts and deliberate practice is that expert skills are very specific and domain dependent, e.g. a chess master is great at analyzing chess games, but not at analyzing things in general. Please help me out here, because I would really like this to make sense and improve my game as a tester…
Nick,
Regarding your question about whether the type of observation I have practiced here is applicable to software, I think that it is. I chose this exercise for a few reasons: James and Jon Back have a video of them describing a stone and it seemed very difficult, and the natural world is distinctly different from software. It is entirely possible to hone your craft in domains outside of software. To better pose the question (using a Weinberg / Kaner technique), can you think of three reasons practicing observation without using software would be detrimental or not useful to a software tester. What are some other ways you would develop your observational proficiency?
My understanding is that expert application of skill is context dependent, meaning the skill you apply and the manner you apply it may very depending on your context.
–J Rohrman
I appreciate the thoughtfulness of your reply.
Three reasons why practicing observation without software could be detrimental or not useful:
1. You may be fooled into believing you have developed observational superpowers, whereas in fact you are only getting better at observing stones (great if you are a geologist)
2. You may be wasting time that could be more productively spent elsewhere, or rather to the detriment of other practice/work.
3. The exercise does not make the skill automatic, because the cues for applying it in a work environment are not there. This could mean you learn how to do it, but don’t apply the skill.
Ideally observational proficiency practice should have the character of a drill, so that it I can repeat it to become quick and automatic. The focus is also narrow. Also the context is software testing, i.e. I sit down behind a computer in my office, so that all the cues to apply it are there.
To use a musical analogy, being able to play scales is a very useful skill. Knowing the scales on a piano certainly helps you learn scales on a guitar, because you know what they should sound like, and can use your knowledge of theory to work out them out slowly and deliberately, but it still a lot of effort to learn it on a different instrument and by no means automatic.
Maybe the analogy is wrong…
I like your music analogy but come to a slightly different conclusion with it. The ability to play scales for a musician is foundational. Understanding of scales will make it much easier to read sheet music and understand music in general. Not understanding scales makes it more difficult to read sheet music and understand music in general. Sometimes there may be direct carry over to an instrument, sometimes the carryover may be more indirect. In either case, the understanding of a scale is beneficial.
To circle back, I think observation and description are foundational skills of software testing. I do not think there is a problem with developing skills used in software testing outside of software despite the fact that carryover into software may not be entirely direct. All testers use this skill, though what and how you observe and describe will vary from project to project.
Sticking with observation then, I think you would agree it is a foundational skill for driving a car. Yet, I don’t think you will improve your ability to driving a car by observing a stone, or anything else than traffic, more particularly from behind a wheel of a moving car.
Well, maybe not from the wheel of a moving car… The essence of deliberate practice is to work on a skill without distractions.
I am questioning how transferrable the stone observation/description skill is to observing/describing software.
Perhaps you can write a blog entry or send me an email explaining why skill sets are not transferable in the sense that my post implies.