First, I want to make sure everyone is aware... I'm OK.
The short story is that I have a broken leg. The slightly longer story is that I have a tib-fib fracture near my right ankle, and it resulted in my needing to have surgery to repair it. So am I really going to tell a testing story out of my accident? Absolutely :).
So how did this all happen? It happened while I was riding my skateboard from work to the CalTrain station. the stretch of roads from Folsom street to Townsend street in the south of market area is mostly flat. I decided that it would be kind of fun to break up the walk by skating to an from work. Of course, when a person skates on a sidewalk there are the cracks, and the separation points, and other irregularities that we try to navigate around or go over. To better allow for the transitions, I invested in bigger and softer skateboard wheels, and for the most part, they were doing fabulous.
Yesterday, as I was skating down the street, my board hit something. It may have been a crack, it may have been a pebble, but whatever it was, it stopped my board cold. My board stopped, but I didn't. As I found myself off balance, my natural reaction was to try to stand up and walk it out, a move I've done hundreds of times before. Well, this time, I came down at roughly a 45 degree angle onto my ankle, and the resulting velocity and pressure broke the tibia near my ankle and then broke the fibula higher up about half way between my ankle and knee.
As I tried to stand I saw the position of my leg, the tell tale angle... it's a break all right. With that, I just scooted myself back to the curb, sat down on my board, put my broken leg in the least painful position I could, and started chatting with the person who stopped to see if I was OK and who dialed 911 on my behalf. As we talked, the said that I looked remarkably calm. Was I in shock? Was I not absorbing the situation? I smiled and said "well, I'm a Scoutmaster, and as a Scoutmaster, I've taught my boys over the years how to deal with these situations. Rule #1 is remain calm. Rule number 2 is assess the damage, and do a little movement as possible so that "the professionals" can deal with the situation. In this case, the professionals were the emergency response team from a fire station South of Market. They evaluated the situation, made a quick splint to help deal with the blunt force trauma to my leg, and then away we went to the hospital.
As radiology looked at the situation, I marveled at the different techniques and methods they used. Because I couldn't keep my leg still, they had to find various ways to immobilize my foot while maneuvering the machine to get a shot (I was on a gurney and I was not moving if they had anything to say about it). The radiologist took it in stride and exemplified some of the best exploratory testing techniques I have ever seen. His charter, get the shot of my leg without me erupting into painful spasms. Radiology team for the win :).
I was brought back to the emergency waiting area, where the orthopedic surgeon had a look at my X-rays... and then told me the real severity. I'll admit it, my heart sank. they were going to have to operate and insert a plate and pins/screws. this meant general anesthetic, which outside of wisdom teeth when I was 24, I'd never dealt with before. I didn't remember much from this time as i came into the room, they introduced the anesthesia and the next thing I knew I was awake with what looked like a beach ball wrapped around my foot.
So right now, I'm dealing with the aftermath of all of this, and I'm in a thoughtful mood, so I couldn't help but explore this situation from the viewpoint of a software tester. In so many ways, this situation resembles my real work life step for step. How so? It it common to be hyper focused when it comes to the big things. Were I to be skating a bowl or a vert ramp, the odds of my getting a break like this is actually a lot less. The reason? Hyper focus keeps us safe. It keeps us conditioned and tuned up. Even though we may miss a hit or we may fall, we are primed for that fall, and so the damage is not as bad, if there is any. No, the real catastrophic situations, where the walls come tumbling down, are often from a piece of neglect, or from not paying attention, from complacency. Additionally, we tend to take the easy stuff for granted. Thus we let down our guards. We don't give those areas much though, and sure enough, they are the ones that can come back and bite you.
So in my testing world, I'm taking a closer look at the areas that I've less laser focus; the common, pedestrian areas that I feel I know so well. How well do I know them, really? Is there a piece of concrete waiting to break loose (metaphorically speaking)? Will I recognize it if I see it, or will i have to "hit" it to become aware?
I had a talk with my sister from the hospital room... this is the sister that's the professional dancer and television/movie stunt-person. As I talked about the different reactions from people (even split from "oh, what a bummer to "dude, why are you riding a skateboard at your age?!"), she said something that helped put it into perspective... this is the price we pay for an active lifestyle. We could remain perfectly safe, but then we would miss out on many of the really cool things that life has to offer. As in testing, we could also play it safe, and follow the script, and look that the features in the scripted manner that is expected and that many are accustomed to. It's safe, but it's a bit boring. Exploration and taking risks is fun, and we often learn way more in that process. While I'm certainly smarting from this recent situation, and will be for some time to come. I'd like to believe my skateboarding days are not over. They are as far as a commute option, that's for sure, but the joy of riding and getting a good velocity, carving turns on the street or a black top well away from cars and pavement cracks, there's a place that I can open up, be focused, and feel the love again. One day at at time, though, of course :).
Tuesday, August 30, 2011
Monday, August 29, 2011
Next Weekend Testing Session? That Depends on "Who’s Driving"
So I’ve been thinking about this for a while now. Weekend Testing Americas has been active and running now for 9 months. We’ve had a range of sessions running from very good to mediocre and everything in between. Some have asked me when the sessions take place, and why aren’t they more frequent (August being a notable exception; we did three sessions in August, and that’s definitely a spike that will be hard to duplicate).
Sessions truthfully happen about every three weeks, and they happen every three weeks for a very simple reason… it’s about the amount of time I can guarantee a Saturday with enough time before, during and after the event to put everything together as a facilitator. In short, the sessions happen on the days that I can actually drive the bus.
Often I get asked “so when’s the next session?” It’s obvious people enjoy the structure, they enjoy the events and they enjoy the way that the process works, even when we bicker a bit here and there about the way that the events get put together. Over the past several meetings, we’ve addressed methods for how to conduct sessions and the things that people need to know if they want to conduct them. So now it’s time to do the next thing… when’s the next Weekend Testing Session? That depends on who’s going to drive it… and for WTA-19, it will not be me.
WHAT?!! Heresy!!!
Nope, it’s a little bit of tough love and a realization that I’m trying to close the loop on a dangerous loose end. It’s soccer season. My daughter plays on Saturdays. I want to watch her play. My son’s a Boy Scout and I’m his leader, we’re heading into the peak time of scouting events before winter comes. There are several testing activities and conferences coming up that I will be participating in. In short, I can’t guarantee that regular availability I’ve had over the past several months. It would be a shame to shutter something that’s working so well for so many people, and truth be told, I don’t want to. I care enough about this program that I want to give a little EDGE love to others, so I plan to do that, and will help any and all who want the experience, but our next session will have another driver. I could pick about half a dozen people who I think would do a great job, but I’d prefer hearing from those people directly, of course.
What do I mean by “driving”? I mean that you would:
• Develop a testing mission and charter(s). Note: you need not do this alone; many WTA participants are more than happy to help develop these with you, as am I.
• Announce the session.
• Create the permanent link to the session.
• Email and Tweet session details periodically leading up to the event.
• Set up the group so that participants could chat via Skype and add users to the session.
• Announce the mission and test charter(s)
• Watch the clock and make sure that we keep on time.
• Encourage questions, and reach out to participants who may not be actively participating.
• Mentor new testers, those who may not have any clue how a Weekend Testing session actually works.
• Lead the debrief/discussion about the current session, and explore the ideas and challenges seen.
• Publish the chat session and an experience report, and then alert any and all interested parties in the existence of the final report.
And that’s it, really :).
It sounds daunting, but in reality, it’s fairly straightforward and it’s actually quite fun to do once you get the hang of it. I’ll be happy to be co-pilot, and to help negotiate the sessions (note: I wasn’t given the green light to fly these solo until I did a few of them under the watchful eyes of Ajay Balamurugadas and Markus Gaertner, so of course I would give the same guidance to anyone else who would step up).
As we say in Scouting… “see one, do one teach one” is a powerful concept, and it really is that simple. If you’ve participated, you know how it works. If you have helped anyone in a session before, you’ve facilitated. If you’ve facilitated, you have the skills to lead. Is Weekend Testing Americas worth something to you? Is it worth enough to ensure its health and longevity? If so, I’d really like to talk to you and arrange for our next session, but be sure, there will not be a next session unless someone else climbs into the pilot’s seat.
Gang, really and seriously… it’s your move :).
Sessions truthfully happen about every three weeks, and they happen every three weeks for a very simple reason… it’s about the amount of time I can guarantee a Saturday with enough time before, during and after the event to put everything together as a facilitator. In short, the sessions happen on the days that I can actually drive the bus.
Often I get asked “so when’s the next session?” It’s obvious people enjoy the structure, they enjoy the events and they enjoy the way that the process works, even when we bicker a bit here and there about the way that the events get put together. Over the past several meetings, we’ve addressed methods for how to conduct sessions and the things that people need to know if they want to conduct them. So now it’s time to do the next thing… when’s the next Weekend Testing Session? That depends on who’s going to drive it… and for WTA-19, it will not be me.
WHAT?!! Heresy!!!
Nope, it’s a little bit of tough love and a realization that I’m trying to close the loop on a dangerous loose end. It’s soccer season. My daughter plays on Saturdays. I want to watch her play. My son’s a Boy Scout and I’m his leader, we’re heading into the peak time of scouting events before winter comes. There are several testing activities and conferences coming up that I will be participating in. In short, I can’t guarantee that regular availability I’ve had over the past several months. It would be a shame to shutter something that’s working so well for so many people, and truth be told, I don’t want to. I care enough about this program that I want to give a little EDGE love to others, so I plan to do that, and will help any and all who want the experience, but our next session will have another driver. I could pick about half a dozen people who I think would do a great job, but I’d prefer hearing from those people directly, of course.
What do I mean by “driving”? I mean that you would:
• Develop a testing mission and charter(s). Note: you need not do this alone; many WTA participants are more than happy to help develop these with you, as am I.
• Announce the session.
• Create the permanent link to the session.
• Email and Tweet session details periodically leading up to the event.
• Set up the group so that participants could chat via Skype and add users to the session.
• Announce the mission and test charter(s)
• Watch the clock and make sure that we keep on time.
• Encourage questions, and reach out to participants who may not be actively participating.
• Mentor new testers, those who may not have any clue how a Weekend Testing session actually works.
• Lead the debrief/discussion about the current session, and explore the ideas and challenges seen.
• Publish the chat session and an experience report, and then alert any and all interested parties in the existence of the final report.
And that’s it, really :).
It sounds daunting, but in reality, it’s fairly straightforward and it’s actually quite fun to do once you get the hang of it. I’ll be happy to be co-pilot, and to help negotiate the sessions (note: I wasn’t given the green light to fly these solo until I did a few of them under the watchful eyes of Ajay Balamurugadas and Markus Gaertner, so of course I would give the same guidance to anyone else who would step up).
As we say in Scouting… “see one, do one teach one” is a powerful concept, and it really is that simple. If you’ve participated, you know how it works. If you have helped anyone in a session before, you’ve facilitated. If you’ve facilitated, you have the skills to lead. Is Weekend Testing Americas worth something to you? Is it worth enough to ensure its health and longevity? If so, I’d really like to talk to you and arrange for our next session, but be sure, there will not be a next session unless someone else climbs into the pilot’s seat.
Gang, really and seriously… it’s your move :).
Saturday, August 27, 2011
How Fragile is Your System?
My kids had a somewhat sad, but I think important, lesson taught to them this week. We have been involved in a process since March with our main fish tank in our house; we have a 65 gallon tank that has a colony of convict cichlids (Archocentrus Nigrofasciatus). In March, a large clutch of babies was spawned, and we've been actively working to raise them. The tank is well maintained, it has a lot of filtration, and it has a large capacity air pump feeding air stones (read: a lot of bubbles in the tank background).
Recently the kids were playing upstairs, and as they are oft to do, roughhousing and jumping around. Unbeknownst to them, they knocked the air line from the air pump to the air stones. Earlier in the week, they helped me clean out the tank and do a water change, too. They didn't realize it, but these events conspired to make a fatal flaw in our system apparent.
I came home from work Thursday night and the kids said "hey dad, you should go up and feed the fish, they look really hungry!" I thought this was an odd statement, so I went up and inspected the tank. What I saw was all of the fish hovering at the surface of the water, some on their sides, their gills pumping rapidly. As I looked and saw the tank, I heard the air pump running louder than normal. I looked down and saw that the air hose was no longer attached. I quickly reattached it, which allowed the bubbles (and air) to flow back into the tank. However, this was only part of the problem. I also noticed a tell tale sign of what also wasn't normal; there was no splashing water from the filter return. The water was just running under the surface because the hose had slipped down below the water line. Add to that the fact that we also have about 70 juvenile fish, each now averaging an inch in length or a little more, along with the older denizens in the tank. Individually, any of these would not be a problem. Taken together, though, what resulted was a massive failure to the system.
We had to act quickly, so I hooked up the water siphon to the bathroom sink and drained out about 20 gallons of the tank water. this served two purposes. first, it allowed for agitation of the surface by the filter return, thus creating an oxygen exchange again. This mixed with the bubbles from the air filter would allow the oxygen to return to the water. Second, I turned on the hose and briskly sprayed water all around the tank (the motion of which would help oxygenate the fishes gills and help them to breathe more naturally. Finally, I surveyed the damage after I saw the fish were moving on their own accord and had perked up considerably. The result was 15 dead juveniles. They had suffocated from lack of oxygen.
When all was calmed down, I gathered my kids together and taught them a bit more about the aquarium ecosystem and how it worked, about oxygen exchange, about water column movement and also overcrowding and overpopulation for a small environment. They had asked me why no fish had died when we had power outages. Then not only did the air pump stop working but the water pump and heater had, too. Why didn't the fish die then? I explained that the fish population was smaller then, that there weren't so many babies, and those babies hadn't grown to a size to make a major difference to the resources of the tank. Now however, they were large enough to make such an impact.
With that, we had to make a game plan, and part of that plan is to find a new home for about 70% of the fish, as soon as they are big enough "to let go". To let go means I plan to donate them to various fish stores in the county. The remaining 30% I will let grow as long and as big as they want to get.
Our software ecosystems are similar. Lots of new features may seem innocent by themselves and in isolation, but all it takes is an environmental change to have something catastrophic appear. we may have little to no idea what will cause that to happen, but one day all of our tests pass and everything looks great, and then one seemingly small change takes place, and suddenly everything has gone horribly wrong. I've had that experience with my own tests, and sometimes it's just a little nudge that sends everything over the edge. So what can we do? Just like I needed to educate my kids about oxygen in the water and surface agitation, I also have to be aware of the unique aspects of what makes my software environment "breathe". I may not be able to know every contingency, but knowing the big and important ones will help to stave off disasters.
Recently the kids were playing upstairs, and as they are oft to do, roughhousing and jumping around. Unbeknownst to them, they knocked the air line from the air pump to the air stones. Earlier in the week, they helped me clean out the tank and do a water change, too. They didn't realize it, but these events conspired to make a fatal flaw in our system apparent.
I came home from work Thursday night and the kids said "hey dad, you should go up and feed the fish, they look really hungry!" I thought this was an odd statement, so I went up and inspected the tank. What I saw was all of the fish hovering at the surface of the water, some on their sides, their gills pumping rapidly. As I looked and saw the tank, I heard the air pump running louder than normal. I looked down and saw that the air hose was no longer attached. I quickly reattached it, which allowed the bubbles (and air) to flow back into the tank. However, this was only part of the problem. I also noticed a tell tale sign of what also wasn't normal; there was no splashing water from the filter return. The water was just running under the surface because the hose had slipped down below the water line. Add to that the fact that we also have about 70 juvenile fish, each now averaging an inch in length or a little more, along with the older denizens in the tank. Individually, any of these would not be a problem. Taken together, though, what resulted was a massive failure to the system.
We had to act quickly, so I hooked up the water siphon to the bathroom sink and drained out about 20 gallons of the tank water. this served two purposes. first, it allowed for agitation of the surface by the filter return, thus creating an oxygen exchange again. This mixed with the bubbles from the air filter would allow the oxygen to return to the water. Second, I turned on the hose and briskly sprayed water all around the tank (the motion of which would help oxygenate the fishes gills and help them to breathe more naturally. Finally, I surveyed the damage after I saw the fish were moving on their own accord and had perked up considerably. The result was 15 dead juveniles. They had suffocated from lack of oxygen.
When all was calmed down, I gathered my kids together and taught them a bit more about the aquarium ecosystem and how it worked, about oxygen exchange, about water column movement and also overcrowding and overpopulation for a small environment. They had asked me why no fish had died when we had power outages. Then not only did the air pump stop working but the water pump and heater had, too. Why didn't the fish die then? I explained that the fish population was smaller then, that there weren't so many babies, and those babies hadn't grown to a size to make a major difference to the resources of the tank. Now however, they were large enough to make such an impact.
With that, we had to make a game plan, and part of that plan is to find a new home for about 70% of the fish, as soon as they are big enough "to let go". To let go means I plan to donate them to various fish stores in the county. The remaining 30% I will let grow as long and as big as they want to get.
Our software ecosystems are similar. Lots of new features may seem innocent by themselves and in isolation, but all it takes is an environmental change to have something catastrophic appear. we may have little to no idea what will cause that to happen, but one day all of our tests pass and everything looks great, and then one seemingly small change takes place, and suddenly everything has gone horribly wrong. I've had that experience with my own tests, and sometimes it's just a little nudge that sends everything over the edge. So what can we do? Just like I needed to educate my kids about oxygen in the water and surface agitation, I also have to be aware of the unique aspects of what makes my software environment "breathe". I may not be able to know every contingency, but knowing the big and important ones will help to stave off disasters.
Friday, August 26, 2011
Podcast Friday: Three Quick Hits
Hello everyone! It's Friday and that means it's time for another batch of my personal weekly "Podcast Favorites" :).
First, of course, is the podcast I actually produce. This time around, This Week in Software Testing interviews Timothy Western (aka @Veretax on Twitter). Matt and Timothy talk a bit about video game beta testing, ho to leverage automated testing, and dealing with finicky customers and project managers. It's a good interview, I think you'll enjoy it :).
Second, Bruce and Trish are back with another installment of TestCast. This features the 2nd installment of their interview with James Bach and this time around James discusses all things pairwise.
Finally, Back to Work is a special treat for me this week. Dan Benjamin is away on vacation, and Merlin decided to take the show in an interesting direction by interviewing Jonathan Coulton (the independent musician who is deservedly referred to as "the geeks Muse"). It's a fun interview and it is surprisingly "on pointe" for Merlin, but then I've heard that Jonathan has that effect on people.
Looking forward to seeing what next week has in store for us all. Happy listening :).
First, of course, is the podcast I actually produce. This time around, This Week in Software Testing interviews Timothy Western (aka @Veretax on Twitter). Matt and Timothy talk a bit about video game beta testing, ho to leverage automated testing, and dealing with finicky customers and project managers. It's a good interview, I think you'll enjoy it :).
Second, Bruce and Trish are back with another installment of TestCast. This features the 2nd installment of their interview with James Bach and this time around James discusses all things pairwise.
Finally, Back to Work is a special treat for me this week. Dan Benjamin is away on vacation, and Merlin decided to take the show in an interesting direction by interviewing Jonathan Coulton (the independent musician who is deservedly referred to as "the geeks Muse"). It's a fun interview and it is surprisingly "on pointe" for Merlin, but then I've heard that Jonathan has that effect on people.
Looking forward to seeing what next week has in store for us all. Happy listening :).
Thursday, August 25, 2011
Weekend Testing Americas: Developing Effective Charters with James Bach
Actually, I'm glad they did, because they helped me realize something I've been struggling with for some time. It'[s one thing to make a test charter or a test mission, but how can we make them more effective? More to the point, how can we craft them so that they are appropriate for the testing session at that time?
To help explain this, imagine you have a group of people you are going to send out to test something. They have one hour. they have to maximize that time, and therefore they need to be able to hit the ground running as fast as humanly possible. Can you adequately describe what needs to be done so that everyone in the group can do that? What if we had a whole group of testers specifically trained to be able to do that, not just for Weekend Testing sessions, but all the time?
This is the skill that James Bach will be working with us to develop and improve this Saturday. Normally, I would be cautious to not over-hype or over-promote these sessions because we might be overrun, but in this case, I think it will prove worth it, so I'm breaking my "limited distribution" promotion (Twitter and direct email) to talk about and announce this session.
So do you want in? If so here's what you need to know and what you've gotta' do:
Date: Saturday, August 27, 2011
Time: 11:00 a.m. - 1:00 p.m. PDT (2:00 p.m. - 4:00 p.m. EDT)
To join the session:
1. Please send an email message to wtamericas@gmail.com with the subject line "WTA18" and a confirmation that you would like to attend the session.
2. Please add "weekendtestersamericas" to your Skype ID list if you have not already done so. Please ask us to add you to our contact list.
3. On Saturday, August 27th, approx. 20 minutes before the start of the session, I will set up the group. If you ping me on Skype at that time, I will add you to the session. If you have replied via email and stated that you will be attending the session, if you are online at that time, I will automatically add you.
Remember, these sessions are "chat" only, no call in is necessary, but you have to be on Skype to participate.
Look forward to seeing you there :).
Wednesday, August 24, 2011
I'll Be at PNSQC... How About You :)?
PNSQC has a broad option of topics speakers and activities, and this year, one of their track speakers is, well... me :).
I will be giving a talk titled "Delivering Quality One Week at a Time: Lessons Learned in Weekend Testing", and I will be delivering it in two ways. First will be a formal track session on Monday, October 10th at 1:30 pm. I will also be delivering a modified presentation during the social hours and poster paper presentation times during the conference. That way, if you don't get to see my technical presentation, you can always catch it in this more personal format.
In case I'm not enough of a draw (yeah, as if :) )... the keynote speakers will be:
- Goranka Bjedov from Facebook exploring "The Future of Quality"
- Rob Sabourin of AmiBug.com, Inc. discussing "Value Sync".
- Jim Benson, talking about "Personal Kanban"
- Michael Bolton, talking about "Standards and Deviations"
- Diana Larsen, discussing "Starting New Projects on a Trajectory Toward Success"
- Erik Simmons, on "21st Century Requirements Engineering"
In addition to the keynotes, invited speakers and other presenter, there will be a full day of in-depth workshops. The technical papers are available for your review with the Conference At-a-Glance.
So, do you want to come and join us? It's not too late. Register Now! I look forward to seeing you there :).
Tuesday, August 23, 2011
Let Codecademy Teach You How to Program!
I would have said the same thing a few days ago... and then I discovered "Codecademy".
Codecademy is a clever idea, and it's a fun way to get your hands into general programming. At the moment, there's a simple set of modules built around JavaScript, but it's really neat the way they have structured this. It feels like you are in a "programming chat" with another user, and you can actually keep tabs on your progress, earn badges you can display, share details on your Facebook profile (if you are so inclined) and see graphical representations of what you've completed. Really, it's a clever system, and it's actually fun to use. It's a bit sparse at the moment; those expecting a one stop shop of all thing programming related will have to wait awhile... or they can actually offer their own lessons if they have the knowledge and skill. This has great potential to be to the programmer what Wikipedia is to the encyclopedia. It's a community driven service, and you can sign up to get notifications when new modules or courses are made available.
In short, if you've ever wanted to get into programming, have limited experience, or just like playing with fun tools, give Codecademy a visit. It's a lot of fun and, hey, you just might learn something :).
Thursday, August 18, 2011
Online Book Review: Learn Ruby the Hard Way
First of all, I love the title of this “book”, and I love the concept behind it. Zed Shaw originally wrote this for Python, in a book called "Learn Python the Hard Way". Rob Sobers made a language equivalent conversion/translation to Ruby. Rob is quick to point out that, while he has made the conversion to Ruby, and has made the book relevant to Ruby programmers, the concept and approach is still Zed's.
Zed (and Rob) have written something noteworthy, a shot across the bow to anyone who laments the loss of the “old ways”. When I talk about the old ways, I’m referring to the old books and magazines where those who wanted to run the programs had no choice but to type out the lines verbatim from the pages from the books or magazines, run them, figure out where we messed up, and ultimately get them to run.
From Learn Python the Hard Way:
The Hard Way Is Easier
LPTHW emphasizes precision, attention to detail, and persistence by requiring you to type each exercise (no copy-paste!) and make it run, as well as to read up on outside topics and to return to exercises and ideas that you don't understand, and understand them.
At the end of LPTHW, you'll know the basics of coding, and be ready to move on to more challenging books. Or at least you'll have tried something new.
The ability to have books and texts online is wonderfully convenient, and the ability to cut and paste code in quickly is a great advancement… but it comes at a cost. Cut and paste helps us to get the ideas down quickly and see them in action, but there just isn’t a replacement for “muscle memory”, the long and often arduous process of typing out the lines of code, forcing us to slow down and physically, manually mull over those lines. I sometimes laugh about the fact that I still remember shell programming tips I learned 20 years ago, but I can barely remember things I did in intense Java study sessions just a couple of years ago. Why is that? It’s because I had to type out every single one of those shell programming examples. There was no CD-ROM, there was no “web site” to download code from. It was type or do without.
“Learn Ruby the Hard Way” expects the programmer to do exactly the same thing. The explicit first instruction is to type in the examples, verbatim, and no cheating. No copy/paste, no macros, and no advanced IDE (they do recommend using gedit as an IDE and it’s very basic and straightforward, very few bells and whistles). There are over 50 exercises, many of them long, repetitive and tedious… and that’s awesome! I’m totally serious here! Especially for us testers. We often try to find the quickest way to accomplish a step or a process when it comes to programming (because, come on, we’re not programmers, we’re testers, we don’t have time for this stuff, right?). Well, the more time I spend with this cumbersome and tedious system, the more appreciation I have for it. There’s no quick gains here, there’s no fast “a-Ha!” moment, and yes, occasionally I roll my eyes at the “master of the obviousness” of a lot of the examples. But there’s definitely a method to the madness here. This isn’t a platitude and concept book, this is a workout book. There’s a lot of code, there’s a lot of questions, there’s a lot of extra credit, and there’s a lot of time to be spent soaking in this stuff. The more that I mess with “code”; be it Cucumber, RSpec or general Ruby, there just isn’t any better method to learning it than just the raw doing it, over and over and over again.
So for those who have gone through a number of the commercial books and feel, yeah, OK, but am I really getting this, I recommend giving “Learn Ruby the Hard Way” a good and vigorous look. If you get irritated and fed up with it, sit back and allow yourself a smile, because that’s a good sign that it’s actually doing what it’s supposed to. It’s the hard way, as the title implies, but sometimes it’s the hard ways that prove to be the best ways :).
Zed (and Rob) have written something noteworthy, a shot across the bow to anyone who laments the loss of the “old ways”. When I talk about the old ways, I’m referring to the old books and magazines where those who wanted to run the programs had no choice but to type out the lines verbatim from the pages from the books or magazines, run them, figure out where we messed up, and ultimately get them to run.
From Learn Python the Hard Way:
The Hard Way Is Easier
LPTHW emphasizes precision, attention to detail, and persistence by requiring you to type each exercise (no copy-paste!) and make it run, as well as to read up on outside topics and to return to exercises and ideas that you don't understand, and understand them.
At the end of LPTHW, you'll know the basics of coding, and be ready to move on to more challenging books. Or at least you'll have tried something new.
The ability to have books and texts online is wonderfully convenient, and the ability to cut and paste code in quickly is a great advancement… but it comes at a cost. Cut and paste helps us to get the ideas down quickly and see them in action, but there just isn’t a replacement for “muscle memory”, the long and often arduous process of typing out the lines of code, forcing us to slow down and physically, manually mull over those lines. I sometimes laugh about the fact that I still remember shell programming tips I learned 20 years ago, but I can barely remember things I did in intense Java study sessions just a couple of years ago. Why is that? It’s because I had to type out every single one of those shell programming examples. There was no CD-ROM, there was no “web site” to download code from. It was type or do without.
“Learn Ruby the Hard Way” expects the programmer to do exactly the same thing. The explicit first instruction is to type in the examples, verbatim, and no cheating. No copy/paste, no macros, and no advanced IDE (they do recommend using gedit as an IDE and it’s very basic and straightforward, very few bells and whistles). There are over 50 exercises, many of them long, repetitive and tedious… and that’s awesome! I’m totally serious here! Especially for us testers. We often try to find the quickest way to accomplish a step or a process when it comes to programming (because, come on, we’re not programmers, we’re testers, we don’t have time for this stuff, right?). Well, the more time I spend with this cumbersome and tedious system, the more appreciation I have for it. There’s no quick gains here, there’s no fast “a-Ha!” moment, and yes, occasionally I roll my eyes at the “master of the obviousness” of a lot of the examples. But there’s definitely a method to the madness here. This isn’t a platitude and concept book, this is a workout book. There’s a lot of code, there’s a lot of questions, there’s a lot of extra credit, and there’s a lot of time to be spent soaking in this stuff. The more that I mess with “code”; be it Cucumber, RSpec or general Ruby, there just isn’t any better method to learning it than just the raw doing it, over and over and over again.
So for those who have gone through a number of the commercial books and feel, yeah, OK, but am I really getting this, I recommend giving “Learn Ruby the Hard Way” a good and vigorous look. If you get irritated and fed up with it, sit back and allow yourself a smile, because that’s a good sign that it’s actually doing what it’s supposed to. It’s the hard way, as the title implies, but sometimes it’s the hard ways that prove to be the best ways :).
Wednesday, August 17, 2011
A Scoutmaster's Key, or What Others See In You
Last night, the boys in the Troop petitioned the council office and wrote in on my behalf to have the Scoutmaster's Key awarded to me. This is an award that takes three years of active tenure and a lot of activity and a productive program to earn, and Scout leaders can turn the paperwork in after they have completed all requirements. So what makes this different? I didn't turn in any paperwork for this. My scouts did. They sent in the application and wrote a letter to the council office on my behalf. Frankly, that makes it worth a lot more to me.
Very often, we look to see what we are worth in the world, whether it be our salaries, our titles or other aspects that we choose to use to identify ourselves with. Scouts like recognition, and that desire for recognition doesn't change when we are adults. Cub Scouts like lots of patches, Boy Scouts like the rank patches and the medals, adult leaders are all about "the knots". Check out any adult leader who's been doing it for a decade or more, and you'll see a leader with a bunch of square knot patches right over their heart looking like a Soviet era general. Is it a little silly? Maybe, but it represents a lot of years of service and dedication. Most of them are training and tenure related; you do the time and the required training, and you get the knot when you finish. While it's cool to claim recognition, I think it's even better when it comes out of the blue and by the ones that are most connected to what you are doing. In my testing world, being recognized as a Miago-do black belt is in the same category. I can't claim it for myself, it has to be given to me by others who believe I have earned the right to have it. That makes it more meaningful.
So to my tester friends out there, think to yourself what you appear to be in the eyes of others. Knowing you do something awesome is a great feeling. Knowing that other people feel and believe that you do something awesome makes it that much more cool :).
Monday, August 15, 2011
Test Framing, or "Helping Someone Make a Decision"
I was describing to some friends of mine that "Test Framing" was a hot topic at CAST, and that I wished I could attend the session (was involved elsewhere). We discussed a bit about the ways that test framing comes into play when we work, and how we could explain test framing. I gave them an example of a recent situation that helped me with framing a situation, and then apply various testing ideas and critical thinking skills. Whether or not this is classic test framing is open to debate.
Anyone who knows me knows that I like to find ways to save money. I don't consider myself to be "cheap", but I also don't like spending money needlessly or foolishly. However, we often do things just because we have always done them or there doesn't seem to be a real benefit to doing them another way.
For the past six and a half years, I've worked in San Francisco. I live about 15 miles south of San Francisco, and in my town I have the benefit of two transit options. There's Bay Area Rapid Transit (BART) and CalTrain. Both travel about the same distance from my home town, but drop the passengers off in different sections of town. When I first started using BART, it made sense to take it because the office I worked at was literally upstairs from the Montgomery Street Bart station. Go up the escalator and turn left. I could time my departure from work within two minutes and still make my train. Insane convenience, plus trains from my stop and to my stop every 8 minutes. Framed like that, there's really not much reason to consider an alternate mode of transportation, even if it's less money. That's some significant convenience… but is it worth a 60% premium?
Honestly, I didn't consider it worth considering, even after our office moved from Market street (just up the stairs from BART) to Montgomery street (plus three blocks north of Market, or even further away from the other option). However, after I changed jobs and my company moved after being acquired. I found myself in an interesting position… my office was now roughly half way between the two commute choices (four blocks south to CalTrain, or three blocks north to BART? Well now, that's a little more interesting. Let's do some math.
From San Bruno to San Francisco and back on BART (including the $1 a day parking) that works out to $8.80 per day. Multiply that out 22 times and we're looking at roughly $195 per month or $2323 a year.
From San Bruno to San Francisco and back on CalTrain (they charge $4 a day to park in their lot, but there's plenty of nearby street parking for Free) works out to $5.50 per day, $121 per month, $1,452 per year. In short… is it worth it for me to walk a block to save $3.30 every day, $72.60 a month, or $871 a year? The answer is yes, of course it is.
But wait, both BART and CalTrain have a discount option for frequent commuters. How does it compare when those are factored in? Bart offers a 6 1/4% discount for high value ticket purchases, and if you use a Clipper card, these are applied automatically. So there's a discount benefit applied there. How is it with CalTrain? Well, here's where the gap widens considerably. CalTrain offers a monthly ticket for $73.00, which is a 40% discount over their daily rates, or a 60% discount from what BART charges, and that's AFTER the BART high value ticket discount. All told, taking CalTrain instead of BART saves me $4.99 a day, $24.96 per week, $109.82 a month, or $1,317.84 per year.
So here's the next piece of this… just cause I like to play what if's… Taking the convenience factor out of the equation, had I opted to take CalTrain from the very beginning of my time working in San Francisco (back in March of 2005) up until now, all things considered, had I banked the difference in ticket prices, the net savings over six years would have been $8400! Put into perspective, that's the cost of a decent used car, a semester of tuition at quite a few private universities (not to mention state schools), and could have paid for the equivalent of a mostly remodeled bathroom or a home landscaping project.
This is an example of framing a situation and examining the ramifications of choices. Do I beat myself up over the choice I made? No, because it made much more sense at the time to do it the way I did. The options were there at times, but the time required to get from CalTrain to my old office and back took me out of doing other things that mattered to me, and thus it was a non-starter. Still, there was a lot I hadn't considered, and looking back, maybe I should have. What would my physical fitness profile have been like if I had opted for the longer walk? Would I be in better shape and weigh less today with all that walking under my proverbial belt? Would that time spent walking allowed me to think up various ideas that I wouldn't have had the time to consider because I was focused on maximizing my time? It's easy to play these games and get frustrated about what could have been, but that's not the point. The point is that we sat down with scenarios, considered the options available, and came to a conclusion based on that information.
Now, to add additional details to this, and just to show it's not so cut and dry, CalTrain runs on a less frequent timetable. BART runs trains that can get me from San Francisco to San Bruno every 8 minutes in prime commute time. CalTrain's schedule gives me a train every hour regularly and a few express trains to choose from during the day, for roughly a train every 45 minutes. That's a lot less convenient, true, but is it so much less to make the savings not worth it. Absolutely not.
Take a scenario. Lay out all of the parameters you can find. Compare and contrast. Consider the benefits. Consider the disadvantages. Weigh the costs. Weigh the savings. Then present the whole story… and make a decision based on your new-found understanding. Repeat for every scenario you face :).
Anyone who knows me knows that I like to find ways to save money. I don't consider myself to be "cheap", but I also don't like spending money needlessly or foolishly. However, we often do things just because we have always done them or there doesn't seem to be a real benefit to doing them another way.
For the past six and a half years, I've worked in San Francisco. I live about 15 miles south of San Francisco, and in my town I have the benefit of two transit options. There's Bay Area Rapid Transit (BART) and CalTrain. Both travel about the same distance from my home town, but drop the passengers off in different sections of town. When I first started using BART, it made sense to take it because the office I worked at was literally upstairs from the Montgomery Street Bart station. Go up the escalator and turn left. I could time my departure from work within two minutes and still make my train. Insane convenience, plus trains from my stop and to my stop every 8 minutes. Framed like that, there's really not much reason to consider an alternate mode of transportation, even if it's less money. That's some significant convenience… but is it worth a 60% premium?
Honestly, I didn't consider it worth considering, even after our office moved from Market street (just up the stairs from BART) to Montgomery street (plus three blocks north of Market, or even further away from the other option). However, after I changed jobs and my company moved after being acquired. I found myself in an interesting position… my office was now roughly half way between the two commute choices (four blocks south to CalTrain, or three blocks north to BART? Well now, that's a little more interesting. Let's do some math.
From San Bruno to San Francisco and back on BART (including the $1 a day parking) that works out to $8.80 per day. Multiply that out 22 times and we're looking at roughly $195 per month or $2323 a year.
From San Bruno to San Francisco and back on CalTrain (they charge $4 a day to park in their lot, but there's plenty of nearby street parking for Free) works out to $5.50 per day, $121 per month, $1,452 per year. In short… is it worth it for me to walk a block to save $3.30 every day, $72.60 a month, or $871 a year? The answer is yes, of course it is.
But wait, both BART and CalTrain have a discount option for frequent commuters. How does it compare when those are factored in? Bart offers a 6 1/4% discount for high value ticket purchases, and if you use a Clipper card, these are applied automatically. So there's a discount benefit applied there. How is it with CalTrain? Well, here's where the gap widens considerably. CalTrain offers a monthly ticket for $73.00, which is a 40% discount over their daily rates, or a 60% discount from what BART charges, and that's AFTER the BART high value ticket discount. All told, taking CalTrain instead of BART saves me $4.99 a day, $24.96 per week, $109.82 a month, or $1,317.84 per year.
So here's the next piece of this… just cause I like to play what if's… Taking the convenience factor out of the equation, had I opted to take CalTrain from the very beginning of my time working in San Francisco (back in March of 2005) up until now, all things considered, had I banked the difference in ticket prices, the net savings over six years would have been $8400! Put into perspective, that's the cost of a decent used car, a semester of tuition at quite a few private universities (not to mention state schools), and could have paid for the equivalent of a mostly remodeled bathroom or a home landscaping project.
This is an example of framing a situation and examining the ramifications of choices. Do I beat myself up over the choice I made? No, because it made much more sense at the time to do it the way I did. The options were there at times, but the time required to get from CalTrain to my old office and back took me out of doing other things that mattered to me, and thus it was a non-starter. Still, there was a lot I hadn't considered, and looking back, maybe I should have. What would my physical fitness profile have been like if I had opted for the longer walk? Would I be in better shape and weigh less today with all that walking under my proverbial belt? Would that time spent walking allowed me to think up various ideas that I wouldn't have had the time to consider because I was focused on maximizing my time? It's easy to play these games and get frustrated about what could have been, but that's not the point. The point is that we sat down with scenarios, considered the options available, and came to a conclusion based on that information.
Now, to add additional details to this, and just to show it's not so cut and dry, CalTrain runs on a less frequent timetable. BART runs trains that can get me from San Francisco to San Bruno every 8 minutes in prime commute time. CalTrain's schedule gives me a train every hour regularly and a few express trains to choose from during the day, for roughly a train every 45 minutes. That's a lot less convenient, true, but is it so much less to make the savings not worth it. Absolutely not.
Take a scenario. Lay out all of the parameters you can find. Compare and contrast. Consider the benefits. Consider the disadvantages. Weigh the costs. Weigh the savings. Then present the whole story… and make a decision based on your new-found understanding. Repeat for every scenario you face :).
Subscribe to:
Posts (Atom)