All or Nothing, or Why Ask Then?

Thursday, March 05, 2015 23:36 PM

This is a bit of a rant, and I apologize for people who are going to read this and wonder what I am getting on about. Since I try to tie everything to software testing at some point and in some way, hopefully, this will be worth your time.

I have a drug/convenience store near my place of work. I go here semi-regularly to pick up things that I need or just plain want. I'm cyclical when it comes to certain things, but one of my regular purchases is chewing gum. It helps me blunt hunger, and it helps me get into flow when I write, code or test. I also tend to pick up little things here and there because the store is less than 100 steps from my desk. As is often the case, I get certain deals. I also get asked to take surveys on their site. I do these from time to time because, hey, why not? Maybe my suggestions will help them.

Today, as I was walking out the door, I was given my receipt and the cashier posted the following on it.


Really, I get why they do this. If they can't score a five, then it doesn't matter. You weren't happy, end of story. Still, I can't help but look at this as a form of emotional blackmail. It screams "we need to have you give us a five for everything, so please score us a five!" Hey, if I can do so, I will, but what if you were just shy of a five? What if I was in a hurry, and there was just a few too many people in the store? The experience was a true four, but hey, it was still pretty great. Now that experience is going to count for nothing. Does this encourage me to give more fives? No. What it does is tell me "I no longer have any interest in giving feedback", because unless it is something that says "Yay, we're great!" then it's considered worthless. It's a way to collect kudos, and it discounts all other experiences.

As a software tester, I have often faced this attitude. We tend to be taught that bugs are absolute. If something isn't working right, then you need to file a bug. My question always comes down to "what does 'not working right' actually mean?" There are situations where the way a program behaves is not "perfect", but it's plenty "good enough" for what I need to do. Does it delight me in every way possible? No. Would a little tweak here and there be nice? Sure. By the logic above, either everything has to be 100% flawless (good luck with that), or the experience is fundamentally broken and a bug that needs to be addressed. The problem arises when we realize that "anything less than a five is a bug", and that means the vast majority of interactions with systems are bugs... does that make sense? Even if at a ridiculously overburdened fundamental level it is true, that means that the number of "bugs" in the system are so overwhelming that they will never get fixed. Additionally, if anything less than a five counts as zero, what faith do I have that areas I actually consider to be a one or a two, or even a zero, will actually be considered or addressed? The long term tester and cynic in me knows the answer; they won't be looked at.

To stores out there looking for honest feedback, begging for fives isn't going to get it. You will either get people who will post fives because they want to be nice, or they will avoid the survey entirely. Something tells me this is not the outcome you are after, if quality of experience is really what you want. Again, the cynic in me thinks this is just a way to put numbers to how many people feel you are awesome, and give little to no attention to the other 80% of responses. I hope I'm wrong.

-----

ETA: Michael Bolton points out below that I made a faulty assumption with my closing remark. It was meant as a quip, and not to be taken literally, but he's absolutely right. I anchored on the five, and it made me mentally consider an even distribution of the other four numbers. There absolutely is nothing that says that is the case, it's an assumption I jumped to specifically to make a point. Thanks for the comment, Michael :).

Book Review: Ruby Wizardry

Thursday, March 05, 2015 19:45 PM



Continuing with the “Humble Brainiac Book Bundle” that was offered by NoStarch Press and Humble Bundle, I am sharing books that my daughter and I are exploring as we take on a project of learning how to write code and test software. Part of that process has been to spend time in the "code and see" environment that is Codecademy. If you have done any part of the Ruby track on Codecademy, you are familiar with Eric Weinstein’s work, as he’s the one who wrote and does updates to the Ruby section (as well as the Python, JavaScript, HTML/CSS and PHP modules).

With "Ruby Wizardry", Eric takes his coding skills and puts them into the sphere of helping kids get excited about coding, and in particular, excited about coding in Ruby. Of all the languages my daughter and I are covering, Ruby is the one I’ve had the most familiarity with, as well as the most extended interaction, so I was excited to get into this book and see how it would measure up, both as a primer for kids and for adults. So how does Ruby Wizardry do on that front?

As you might guess from the title and the cover, this book is aimed squarely at kids, and it covers the topics by telling a story of two children in a magical land dealing with a King and a Court that is not entirely what it seems, and next to nothing seems to work. To remedy this, the children of the story have to learn some magic to help make the kingdom work properly. What magic, you ask? Why, the Ruby kind, of course :)!

Chapter 1 basically sets the stage and reminds us why we bought this book in the first place. It introduces us to the language by showing us how to get it ("all adults on deck!”), how to install it, make sure it’s running and write our first "Hello World” program. It also introduces us to irb, our command interpreter, and sets the stage for further creative bouts of genius.

Chapter 2 looks at "The King's Strings" and handles, well, strings. Strings have methods, which allow us to append words like length and reverse written with dots ("string".length or 'string'.reverse). Variables are also covered, and show that the syntax that works on raw strings also works on assigned variables as well.

Chapter 3 is all about Pipe Dreams, or put more typically, flow control, with a healthy dose of booleans, string interpolation, and the use of structures like if, elseif, else and unless to make our Ruby scripts act one way or another based on values in variables and how those values relate to other things (such as being equal, not equal, done along with other things or in spite of other things, etc.).

Chapter 4 introduces us to a monorail, which is a train that travels in an endless loop. Likewise, the chapter is about looping constructs and how we can construct loops (using while as long as something is true and until up to the point something becomes false, along with for to iterate over things like arrays) to do important processes and repeat them as many times as we want, or need. Also, it warns us to not write our code in such a way to make an infinite loop, one that will just keep running, like our monorail if it never stops.

Chapter 5 introduces us to the hash, which is a list with two attributes, a key and a value,  as well as the ability to add items to arrays with shift, unshift, push or pop. Additionally we also learned how to play with ranges and other methods that give us insights as to how elements in both arrays and hashes can be accessed and displayed.

Chapter 6 goes into talking about symbols (which is just another word for name), and the notation needed to access symbols. Generally, the content of something is a string; the name of something is a symbol. Utilizing methods allows us to change values, convert symbols to strings, and other options that allow us to manipulate data and variables.

Chapter 7 goes into how to define and create our own methods, including the use of splat (*) parameters, that allows us to use any number of arguments. We can also define methods that take blocks by using "yield".

Chapter 8 extends us into objects, and how we can create them and use them. We also learn about object IDs to tell them apart, as well as classes, which allow us to make objects with similar attributes. We also see how we can have variables with different levels of focus (Local, Global, Instance and Class) and how we can tell each apart (variable, $variable, @variable and @@variable, respectively).

Chapter 9 focuses on inheritance, which is how Ruby classes can share information with each other. this inheritance option allows us to create subclasses and child classes, and inherit attributes from parent/superclasses.

Chapter 10 shows us a horse of a different color, or in this case, modules, which are a bit like classes, but they can't be created using the new method. Modules are somewhat like storage containers so that we can organize code if methods, objects or classes won't do what we want to do.  By using include or extend, we can add the module to existing instances or classes.

Chapter 11 shows us that sometimes the second time's the charm, or more specifically, we start getting the hang of Refactoring. Using or operators to assign variables, using ternary operators for short actions, using case statements instead of multiple if/elseif/else statements, returning boolean variables, and most important, the removal of duplicate code and making methods small and manageable.

Chapter 12 shows us the nitty-gritty of dealing with files. Opening reading from, writing to, closing and deleting files are all critical if we want to actually save the work we do and the changes we make.

Chapter 13 encourages us to follow the WEBrick Road, or how we can use Ruby to read and write data from the Internet to files or back to Internet servers using the open-uri gem, which is a set of files that we can use to make writing programs easier (and there are lots of Ruby gems out there :) ).

Chapter 14 gives some hints as to where you, dear reader, might want to go next. This section includes a list of books, online tutorials, and podcasts, including one of my favorite, the Ruby Rogues Podcast. It also includes interactive resources such as Codecademy, Code School, and Ruby Koans, and a quick list of additional topics.

The book ends with two appendices that talk about how to install Ruby on a Mac or a Linux workstation and some of the issues you might encounter in the process.

Bottom Line:

For a "kids book", there's a lot of meat in here, and to get through all of the examples, you'll need to take some time and see how everything fits together. The story is engaging and provides the context needed for the examples to make sense, and each section provides a review so that you can really see if you get the ideas. While aimed for kids, adults would be well suited to follow along as well. Who knows, some wizarding kids might teach you a thing or three about Ruby, and frankly, that's not a bad deal at all!

Less Eeyore, More Spock

Thursday, February 26, 2015 21:30 PM

Today's entry is inspired by a post that appeared on the QATestLab blog called "Why Are Software Testers Disliked By Others?" I posted an answer to the original blog, but that answer started me thinking... why does this perception exist? Why do people feel this way about software testing or software testers?

There's a lot of jokes and commentary that go with being a software tester. One of the most common being "if no one is talking about you, you're doing a great job". Historically, Quality Assurance and Software Testing was considered somewhat like plumbing. If we do our jobs and we find the issues and they get resolved, it's like the plumbing that drains our sinks, tubs, showers and toilets. Generally speaking, we give the pipes in our walls next to no thought; that is, until something goes wrong. Once there's a back up, or a rupture, or a leak, suddenly plumbing becomes tremendously present in our thoughts, and usually in a negative way. We have to get this fixed, and now! Likewise, software testers are rarely considered or thought about when things are going smoothly, but we are often looked at when something bad has happened (read this as "an issue has made itself out into the wild, been discovered, and been complained about").

This long time perception has built some defensiveness for software testers and software testing, to the point where many testers feel that they are the "guardians of quality". We are the ones that have to find these horrible problems, and if we don't, it's our heads! It sounds melodramatic, but yes, I've lived this. I've been the person called out on the carpet for missing something fundamental and obvious... except for the fact that it wasn't fundamental or obvious two days before, and interestingly, no one else thought to look for it, either.

We can be forgiven, perhaps, for bringing on ourselves what I like to call an "Eeyore Complex". For those not familiar, Eeyore is a character created by A.A. Milne, and figures in the many stories of "Winnie the Pooh". Eeyore is the perpetual black raincloud, the one who finds the bad in everything. Morose, depressing, and in many ways, cute and amusing from a distance. We love Eeyore because we all have a friend that reminds us of him.

The problem is when we find ourselves actually being Eeyore, and for many years, software testing deliberately put itself in that role. We are the eternal pessimist. The product is broken, and we have to find out why. Please note, I am not actually disagreeing with this; the software is broken. All software is, at a fundamental level. It actually is our job to find out where, and advocate that it be fixed. However, I have to say that this is where the similarities must end. Finding issues and reporting/advocating for them is not in itself a negative behavior, but it will be seen as such if we are the ones who present it that way.

Instead, I'd like to suggest we model ourselves after a different figure, that of Spock. Yes, the Spock of Star Trek. Why? Spock is logical. He is, relatively speaking, emotionless, or at least has tremendous control over them (he's half human, so not devoid of them). Think about any Star Trek episode where Spock evaluates a situation. He examines what he observes, he makes a hypothesis about it, tests the hypothesis to see if it makes sense, and then shares the results. Spock is anything but a black raincloud. He's not a downer. In fact, he just "is". He presents findings and data, and then lets others do with that information what they will. Software testers, that is exactly what we do. Unless we have ship/no ship decision making authority, or the ability to change the code to fix what is broken (make no mistake, some of us do), then presenting our findings dispassionately is exactly what we need to be doing.

If people disagree with our findings, that is up to them. We do what we can to make our case, and convince them of the validity of our concerns, but ultimately, the decision to move forward or not is not ours, it's those with the authority to make those decisions. In my work life, discovering this, and actually living by it, has made a world of difference in how I am perceived by my engineering teams, and my interactions with them. It ceases to be an emotional tug of war. It's not a matter of being liked or disliked. Instead it is a matter of providing information that is either actionable or not actionable. How it is used is ultimately not important, so long as I do my best to make sure it is there and surfaced.

At the end of the day, software testers have work to do that is important, and ultimately needs to be done. We provide visibility into risks and issues. We find ways in which workflows do not work as intended. We noticed points that could be painful to our users. None of this is about us as people, or our interactions with others as people. It's about looking at a situation with clear understanding and knowing the objectives we need to meet, and determining if we can actually meet those objectives effectively. Eeyore doesn't know how to do that. Spock does. If you are struggling with the idea that you may not be appreciated, understood, or liked by your colleagues, my recommendation is "less Eeyore, more Spock".

If You Have $20, You Can Have a Standing Desk

Friday, February 20, 2015 18:35 PM

I've had a back and forth involvement with standing desks over the years. I've made cheap options, and had expensive options purchased for me. I've made a standing desk out of a treadmill, but it has been best for passive actions. It's great for reading or watching videos, not so great for actually typing, plus it was limiting as to what I could put on it (no multi monitor setup). Additionally, I've not wanted to make a system that would be too permanent, since I like the option of being flexible and moving things around.

I'm back to a standing desk solution for both home and work because I'm once again dealing with recurring back pain. No question, the best motivation for getting back to standing while working is back pain. It's also a nice way to kick start one's focus and to get involved in burning a few more calories each year. I'll give a shout to Ben Greenfield, otherwise known as "Get Fit Guy" at quickanddirtytips.com for a piece of information that made me smile a bit. He recommends a "sit only to eat" philosophy. In other words, with the exception of having to drive or fly, my goal should be to sit only when I eat. All other times, I should aim to stand, kneel, lie down or do anything but sit slumped in a chair. The piece of data that intrigued me was that, by doing this, I'd be able to burn 100 additional calories each day. In a week's time, that's the equivalent of running a 10K.

For those who have access to an IKEA, or can order online, at this moment, the Ikea LACK square side table, in black or white, can be purchased for $7.99 each. I chose to do exactly that, and thus, for less than $20, including tax, I have set up this very functional standing desk at work:




The upturned wastebasket is an essential piece of this arrangement. It allows me to shift the weight from leg to leg, and to give different muscles in my back some work, and to rest other areas from time to time. I've also set up a similar arrangement at home, but added an EKBY ALEX shelf (I'll update with a picture when I get home :) ). This gives me a little extra height and some additional storage for small items. The true beauty of this system is that it can be broken down quickly and moved anywhere with very little effort, and is much less expensive than comparable systems I have seen. If you'd like to make something a little more customized, with a pair of shelf brackets and a matching 48" shelf, you can make a keyboard tray, though for me personally, the table height works perfectly.

What I find most beneficial about a standing desk, outside of the relief from back pain, is the fact that it is incredibly focusing. When I sit down, it's easy to get into passive moments and lose track of time reading stuff or just passively looking at things. When I stand, there is no such thing as "passive time". It's very focusing, and it really helps me to get into the zone and flow of what I need to do. For those looking to do something similar, seriously, this is a great and very inexpensive way to set up a standing desk.

Packt Publishing says "FREE LEARNING - HELP YOURSELF!"

Monday, February 16, 2015 21:39 PM

Something's in the air, I think. Maybe it's a new year of possibilities, maybe it's the nature of technical advancement and growth that happens each year, but there seems to be a groundswell in opportunities for programmers, testers and DIYers to learn new stuff all the time, often very close to free, and in many cases, just plain outright for free.

Packt Publishing recently did this with their 24 gifts for Christmas, in which they offered ebooks for free each day for a limited time, and they are back at it again with their "FREE LEARNING - HELP YOURSELF!" initiative, and again, available for a limited time.




"Packt is here to help you develop, and that's why we're offering you and other IT professionals 18 days of Free Learning -- from today (February 16, 2015) until March 5, 2015, you can claim a free eBook every day here.

Each eBook will only be available for free for 24 hours, so make sure you come back every day to grab your Free Learning fix! We'll be featuring a diverse range of titles from our extensive library, so don't miss out on this amazing opportunity to develop some new skills and try out new tech.

Happy learning!

The Packt Team"


Starting today, they are offering a title related to developing in Drupal. Not something you're currently interested in? That's OK, check back tomorrow; there may be something else that will be interesting.

As Packt Publishing and a number of other vendors have been super helpful to give me free materials throughout the past five years, and in a sense, contribute greatly to the overall content of the TESTHEAD blog, I'm happy to help spread the word for these promotions when they provide them, so if you want to take advantage of them, check in each day over at Packt and see if they have something interesting for you. I certainly will be!



Book Review: Build Your Own Website

Thursday, February 12, 2015 05:55 AM

With the "Humble Braniac Book Bundle" still underway, I felt it only fitting to keep the trend going and review books that are geared towards kids and those who want to have a quick introduction to the worlds of programming, web design and engineering. My daughter and I are exploring a lot of these titles at the moment, and one that caught my eye was "Build Your Own Website", primarily because it promised to be "A Comic Guide to HTML, CSS and WordPress", and that indeed it is.

I should probably mention that by "a comic guide", it does not mean in the funny sense (though some of it is), but in the illustrated, graphic novel sense. For those familiar with NoStarch Press and their "The Manga Guide to..." series of books, Nate Cooper's writing and Kim Gee's artwork fits very well in that space. What's more, "Build Your Own Website" follows the same template that "The Manga Guide to..." books do, in that each section starts with an illustrated graphic novel treatment of topics, and then follows on with a more in depth prose treatment of each area.

So what's in store for the reader who wants to start on a mission to make their own site from scratch?

Chapter 1 starts with our protagonist Kim looking forward to her first web design class, and shows that inspired and excited first timer's desire to get in and do something. It's followed by an explanation of the tools needed to be downloaded and do the work necessary to complete the examples in the book. All of the exercises and examples can be done for free, all you need is a web browser or two, a text editor, an ftp client (the book recommends FileZilla; it's the one I use as well) and you can get a free WordPress account at http://www.wordpress.com.


Chapter 2 talks about The Trouble with HTML, and how Kim and her dog Tofu meet up with the Web Guru, who introduces them to the basics of HTML, paths and naming conventions, loading pictures and following links, the hierarchy of files and directories that make up a basic web site, and a dragon called "404". The second section goes into details about all of these including explaining about document structure, HEAD and BODY tags, the items that go in each, embedding images, and a basic breakdown of the most common HTML tags.


Chapter 3 shows us how Kim Makes Things Look Great with CSS. Well, Glinda, the Good Witch of CSS helps Kim do that (graphic novel for kids, gang. Work with me, here ;) ). Glinda shows Kim the basics of CSS including classes and IDs, inline styles and external stylesheets that can be referenced along with inline styles, effectively creating a "cascade of styles" (CSS == "Cascading Style Sheets"). The chapter also discusses using div's for creating separate sections and blocks that CSS can be applied to, and ends with commonly used CSS properties.


Chapter 4 is where Kim Arrives in WordPress City, and where the examples focus on, of course, WordPress as a composition platform. Kim gets introduced to what WordPress is, which is a Content Management System (CMS), and the conventions of creating both blogs and websites. Kim is introduced to the Dashboard, creating posts, using the Visual editor, structuring her site, using Categories and Tags, using the Media Library to store media items, and the overall Theme to be used for the site. Each of these is covered in greater detail with examples in the second prose part.


Chapter 5 takes us to Customizing WordPress, and the myriad options that Kim can use to make her site look the way she wants it to. She is introduced to the Appearance panel, the difference between free and premium Themes, plugins such as Buy buttons or sharing posts on social media, Widgets that perform special functions that can be replicated for sections or each page, changing the navigation options to get to your pages quickly, and how each of the elements of WordPress are built on HTML and CSS (as well as things like JavaScript, PHP, Ruby, etc.).


Chapter 6 brings us to The Big Launch, where Kim and Tofu navigate the realities of hosting the site and how to set up hosting so that they can display their finished site to the world. There's lots of options, and most cost some money, but not very much (plans ranging from $5-$10 a month are readily available). Registering a domain is covered, and many sites have an option to install WordPress and use it there.


Bottom Line:
"Build Your Own Website" starts with some basic HTML and CSS, and then spends the bulk of the second half of the book introducing you, the user, to WordPress. For those looking to see the nuts and bolts of making a web site from scratch, including making the navigation elements, more involved interactions, and other esoteric features of web sites outside of the CMS system that WordPress provides, you will be disappointed. Having said that, if the goal is to get a site up and running and using a well designed and quick to use interface, WordPress is a pretty good system, with lots of flexibility and ways to make the basic formatting of a site nearly automatic. Younger web development acolytes can get in and feel what it's like to design and manage a site. To that end, "Build Your Own Website" does a very good job, and does it in an entertaining and engaging manner.

I would recommend this as a good companion book with "Lauren Ipsum", so as to give some high level computer science interaction. Both books also show that young programmers can get in, see what is happening, and become curious as to what comes next. From there, focusing on books that deal with JavaScript or frameworks for setting up sites will be less of a jump, because we can look back at WordPress and its CMS and say "oh yeah, that looks familiar". "Build Your Own Website" sets up a nice foundation, and makes a good jumping off point for those further explorations.

Writing the "Michael Larsen" Way?

Monday, February 09, 2015 21:24 PM

First off, I have to say "thank you" to my friend Jokin Aspiazu for inspiring this post today. He wrote a piece about writing a blog from your own experiences and how he found inspiration from a number of people, including me.

The statement that prompted today's blog post was the following. In it, Jokin is explaining different styles and approaches to writing a blog post, and ways in which those posts are done:

"The Michael Larsen way. He wakes up early, so he has time to write before his daily routines start. The thing is that if you write late at night, when the day is gone, you are going to be tired in body and mind. And your writing won’t be as fluid as you would like, and the next day, when you read your text, you will hear “I’m so tired…” in the background."



I have to say that this is mostly correct. If given a choice, I much prefer writing in the early morning over any other time of day. I think Jokin was referencing a comment I said to him at EuroSTAR when we were talking about the ideal times to do certain things, and that for me, that sweet spot is early in the morning, and by early, I mean any time before 6:00 a.m. The quote, as I remember saying it (because I do say this a lot ;) ), is that "I can get a lot done while everyone else I know and relate with is asleep".

Having said that, there are a few other things that I do, and I find them helpful as well.

The Voice Recorder on my Phone is a Really Good Friend

Oh, Voice Recorder, how kind you are to me. You make it possible for me to capture any insane and rambling thought I might have, and not lose it to the ether. I should also add I am grateful for the headphone and mic combinations now available with SmartPhones, because they make me look like less of a lunatic while I am walking down the street.

Some great spots where I can let loose with my thoughts are on my daily commute legs. I park my car about a half mile from the train station I use because I'm cheap and don't want to pay for a parking permit, but also because it gives me a bit of a walk each day. That walk is often a golden time to think out loud (something I do regularly), and having the voice recorder lets me capture all of that. Also, it gives people walking past me the impression I'm just talking to someone on the phone, so I'm not looked at as though I'm crazy ;).

Often, the ramblings don't amount to much, and those I tend to delete at the end of each week, but every so often, I'll find something that sticks, or that gives me a reason to say "OK, I want to explore that some more". Often that will result in something I want to write about.

Every Book Has a Story to Tell

Generally speaking, I love to read. Though my book buying habits have changed with Kindle apps and e-books, I still love having a lot of choices to choose from and read from. My SmartPhone has become my secondary reading device, but my first is my laptop computer. I often find myself reading books and grabbing passages or parts of a book that I have found interesting, and I pull them over into a Notes app that I use. Sometimes they sit there for months, but every once in awhile, something will happen, or I'll see something that jumps out at me and I'll say "hey, that fits into a problem I'm dealing with".

Very often, those discoveries are not limited to technical books or books about testing. I'm a fan of history, and I love reading about interesting things that have happened in the past, both distant and more recent. I often borrow the Dan Carlin quote of "history has all but ruined fiction for me", and that shows up in the things that I read. It's rare that you will find me reading fiction, though I do from time to time. Most of the time, it's non fiction of a historical, technological, or business perspective. Those lessons often make their way into my posts.

"That Reminds me of a Testing Story..."

I owe this phrase to the Cartoon Tester, aka Andy Glover. He used it as a comical way of showing the different type of testers out there, but it illustrated something I frequently try to do. Even in the mundane aspects of my life, I find things that both inform my testing, and also inform my view of the world as I see it, which in turn informs my testing. Something as simple as a way to mow the lawn, or deal with pests in the yard, or trying to manage the delicate balance of life in my fish tanks, or the daily dilemmas my kids face, or the often interesting and noteworthy events that happen in my role as a Scout Leader, all of these shape what often becomes an analogy to software testing. They may be helpful to others, they may not, but overall, I remind myself that they are helpful to me. Whether they be specific to ideas, events, or interactions with individuals, each of them informs what I do, and gives me ideas of ways that I can do it better... maybe :).

Again, I want to thank Jokin for helping me consider this, and give me a chance to respond a little more in depth. While everything Jokin says is accurate, I hope this gives you a little more of a glimpse into how I think and work, and how I like to gather material that ultimately makes its way into my blog. If these ideas help you to write better, more frequently, or at least think a little differently about how you write, awesome. If not, again, it felt good to give some additional thoughts as to what writing "the Michael Larsen way" actually means, at least to me.

Book Review: Python for Kids

Friday, February 06, 2015 22:12 PM

As I have been working with my daughter to learn programming, we have been focusing on learning Python.  We chose Python primarily because it was something I felt we could both come at from a similar frame of reference. I had worked with Python but in limited capacity, and Amber had not really worked with any programming languages. By working on Python, we could be somewhat closely matched with what we were learning.

NoStarch Press has a number of books that are ideally suited for younger programmers, and to that end we both decided to look at the books together. We will be doing three “for Kids" books reviews during February, provided we can get through all of them. All journeys have to start somewhere though, and this journey will start with Python for Kids. I should also mention that, for a limited time, you can get Python for Kids as part of the NoStarch and Humble Bundle "Humble Brainiac Book Bundle" offer, which comes with a lot of other additional books.

Python for Kids is written in a way that lets the user, whether they are kids or adults, readily get into the material and see how the examples work and try them out for themselves.

Chapter 1 starts out with installing and using Python 3, so right away Amber and I had to adjust to the new syntax (Codecademy’s Python modules are still based on Python 2).  Be aware that there are some subtle differences with Python 3, one of the main ones being the parentheses required when using the print(“text goes here”) function (yeah, like that ;) ).

Chapter 2 introduces the user to calculate values using simple equations via operators, using parentheses to ensure the desired order of operations, and creating and using variables to store values for use in those calculations.

Chapter 3 introduces strings, lists,  tuples, and maps, each of which allows the user to manipulate text in a variety of ways. Each of the approaches has rules as to how to move items and how they are represented, ranging from simple strings with are just quoted sentences, up to maps which have keys and values that can be called as needed.

Chapter 4 introduces the user to drawing methods, and in this case, that involves using a module called turtle (which in turn uses a tool called tinter). Using this tool, we can actually draw the turtles movements with lines moving left and right, moving forward and backward, as well as starting and stopping with up and down commands.

Chapter 5 focuses on asking questions and responding based on the response the system gets. For experienced programs, this i about if statements and their related commands (elif, else)  and how commands allow for combining conditions (using and/or) and converting values (using int, str, float and none).

Chapter 6 talks about “Going Loopy” which, as you might guess, deals with handling loop conditions and repetitive tasks. for and while loops are covered, and break conditions are shown to, well, break out of loops.

Chapter 7 talks about ways to recycle code and reuse it defining and using Functions and importing Modules. Variable scope is also covered so as to see where values are assigned, used and passed back and forth.

Chapter 8 focuses on the things in python, otherwise known as classes and objects.  this chapter covered the details of classes and how they an be used to create instances, and how objects can be created, call functions to work with objects, and assigning object variables to save values in those objects.

Chapter 9 covers the various built-in functions available in Python, those that we can import into Python programs and use directly (functions like abs, bool, print, float, int, len, etc) as well as howe to open and manipulate files.

 Chapter 10 covers a variety of helpful modules, such as copy, keyword, random, shuffle, and the sys module that allows the user to control the Python shell itself, reading input with stdin, writing output with stdout, telling time with the time module, and using pickle to save user information in files (yes, there’s a module called pickle ;) ).

Chapter 11 revisits turtle, and how we can use it to draw a variety of items. including basic geometric shapes, changing the pen color, filling shapes and reusing steps in functions to combine drawing shapes and using multiple colors in one function call.

Chapter 12 covered using tkinter to make “better graphics” and my oh my does this take me back. I used Tcl/Tk back in the 90s for a number of things, and the syntax to use tkinter is very familiar.  Simple shapes, event bindings so objects can move when keys are pressed, using identifying numbers to move shapes and change colors are all covered here.

Part II gives the user a chance top practice the programming chops they have developed in the first Part by making a ball bouncing game called, appropriately enough, Bounce!

Chapter 13 starts out using the tinter module, in which we can create a class for a ball and move it around the screen.  Coordinates can be set so that it will bounce off of the top and corners of the screen, and a randomized option so the ball has a dynamic movement.

Chapter 14 continues with creating classes for the paddle, and using coordinates to see if the ball hit the paddle. Event bindings tie the left and right arrow keys to control the  paddle,  and make it so,  if the player misses the ball, the game ends when the ball hits the bottom.

Part III continues the ideas so far shown with “Mr. Stick Man Races for the Exit”.

Chapter 15 shows how to make graphical images of, you guessed it, a stick man (using GIMP to make the actual images) and making the backgrounds of the images transparent so they won’t cover up other things.

Chapter 16 covers creating a Game class making a background image. By using functions called within_x and within_y, we can determine if items have collided with other items. We also discover Sprites and a sub-class, PlatformSprite, to draw the platforms on the screen.

Chapter 17 walks through the details for taking the pictures we created for Mr. Stick Man back in Chapter 15 and setting up options for the figure to move, turn and jump.

Chapter 18 finishes off the Stick Man game, and shows that putting together a working game is not trivial, but it’s also not a huge endeavor either.  We focus on using the images we made for Mr. Stick Man so he appears to be running, use  collision detection to tell if he hits the sides of the canvas or another object, and have Mr. Stick man drop if he runs off the edge of a platform. We also make a door that Mr. stick man can go through, ending the game.

The book also provides an Afterward that discusses some additional options for doing basic game development Alice, Scratch and Unity3D, PyGame, which is a dedicated library for making games, band a discussion of other programming languages and a super quick look at what they do , where to get them, and what it takes to make a   “Hello, World!” program. The Appendix highlights keywords in Python, and the glossary defines a number of words kids might not hear in their everyday interactions.

Bottom Line:

Python for Kids clocks in at a little over 300 pages, but you won’t feel like it as you work through it. There are numerous small projects and samples to examine, and all of the solutions to the puzzles and challenges are available at http://python-for-kids.com/. While this book is geared towards kids, there’s plenty in here to keep adults engaged and focused. Often, programming books are plagued with the “implied knowledge” trap that happens so often, where small projects give way to bigger ones, without a clear understanding of how the jump was made. Python for Kids does a very good job of avoiding that problem. Having kids as the primary audience, they take their time explaining key areas, and yes, for programmers with a little work under their belts, this is going to probably seem remedial, but as an introduction to Python, I think it’s first rate.

If you are looking to give your kids a kick start in learning how to program, if Python seems like an interesting language to start with, and if you’d like to have a couple of tangible projects to play with and augment as you see fit, then Python for Kids should be on your short list of programming books… provided having fun while learning is a priority.

How I am Overcoming "Expectational Debt"

Thursday, February 05, 2015 21:59 PM

A phrase I have personally grown to love, and at times dread, is the one that Merlin Mann and Dan Benjamin coined in 2011 during their Back to Work podcast. That phrase is "expectational debt". Put simply, it's the act of "writing checks your person can't cash" (there's a more colorful metaphor that can be and is often used for this, but I think you understand what I mean ;) ).

Expectational Debt is tricky, because it is very easy to get into, and it is almost entirely emotional in nature. Financial debt is when you have to borrow money to purchase something you want or need, and it invariably involves a financial contract, or in the simplest sense a "personal agreement" where the money owed will be paid back. It's very tangible. Technical debt is what happen in software all the time, when we have to make a shortcut or compromise on making something work in the ideal way so that we can get a product out the door, with the idea that we will "fix it later". Again, it's also tangible, in the sense that we can see the work we need to do. Expectational debt, on the other hand, is almost entirely emotional. It's associated with a promise, a goal, or a desire to do something. Sometimes that desire is public, sometimes it is private. In all cases, it's a commitment of the mind, and a commitment of time and attention.

I know full well how easy it is to get myself into Expectational Debt, and I can do it surprisingly quickly. People often joke that I have a complete inability to say "no". That's not entirely true, but it's close enough to reality that I don't protest. I enjoy learning new things and trying new experiences, so I am often willing to jump in and say "yeah, that's awesome, I can do that!" With just those words, I am creating an expectational debt, a promise to do something in the future that I fully intend to fulfill, but I have not done the necessary footwork or put the time in to fully understand what I am taking on. Human beings, in general, do this all the time. We also frequently underestimate or overestimate how much these expectations matter to other people. Something we've agreed to do could be of great importance to others, or of minor importance. It's also possible that we ourselves are the only ones who consider that expectation to be valuable. Regardless of the "weight" of the expectation, they all take up space in our head, and every one of them puts a drag on our effectiveness.

Before I offer my solution, I need to say that this is very much something I'm currently struggling with. These suggestions are what I am doing now to rein in my expectational debt. It's entirely possible these approaches will be abandoned by yours truly in the future, or determined not to work. As of now, they're helping, so I'm going to share them.

Identify your "Commitments"

Get a stack of note cards, or use an electronic note file, or take a 365 day single day calendar, whatever method you prefer, and sit down and write out every promise you have made to yourself and to others that you have every intention of fulfilling. Don't just do this for things in your professional life, do this for everything you intend to do (family goals, personal goals, exercise, home repairs, car repairs, social obligations, work goals, personal progress initiatives, literally everything you want to accomplish).

Categorize Your "Commitments"

Once you have done this, put them in a priority order. I like to use the four quadrants approach Steven Covey suggests in "Seven Habits of Highly Effective People". Those quadrants are labeled as follows:

I. Urgent and Important

II. Important but Not Urgent

III. Urgent but Not Important

IV. Not Urgent and Not Important



My guess is that, after you have done this, you will have a few items that are in the I category (Urgent and Important), possibly a few in the III category (Urgent but Not Important), and most will fall into Categories II and IV.

Redouble or Abandon Your "Commitments"

These are questions you need to ask yourself for each commitment:

- Why do I think it belongs here?
- Will it be of great benefit to me or others if I accomplish the goal?
- Is it really my responsibility to do this?
- If I were to not do this, what would happen?

This will help you determine very quickly where each of the items fall. Most expectational debt will, again, fall in categories II and IV.

For your sanity, as soon as you identify something that falls into Category IV (Not Urgent and Not Important), tell yourself "I will not be doing this" and make it visible. Yes, make a list of the things you will NOT be doing.

Next is to look at the items that fall into Category III. These are Urgent but Not Important, or perhaps a better way to put this is that they are Urgent to someone else (and likely Important). They may not be important to you, but another person's anxiety about it, and their visible distress, is making it Urgent to you. It's time for a conversation or two. You have to decide now if you are going to commit time and attention to this, and figure out why you should. Is it because you feel obligated? Is it because it will solve a problem for someone else? Is it because you're really the only one who can deal with the situation? All of these need to be spelled out, and in most cases, they should be handled with a mind to train up someone else to do them, so that you can get out of the situation.

The great majority of things you'll want to do, and want to commit to, will fall in Category II. They are Important, but they are not Urgent (if they were Urgent and Important, you'd be doing them... probably RIGHT NOW!!!). Lose weight for the summer. Learn a new programming language. Discover and become proficient with a new tool. Plan a vacation for next year. Read a long anticipated book. Play a much anticipated video game. These are all items that will, in some way, give us satisfaction, help us move forward and progress on something, or otherwise benefit us, but they don't need to be done "right now". Your goal here is to start scoping out the time to do each of these, and give it a quantifiable space in your reality. I believe in scheduling items that I want to make progress on. In some cases, getting a friendly "accountability partner" to check in on me to make sure I'm doing what I need to do is a huge incentive. A common tactic that I am using now is to allocate four hours for any "endeavor space". I also allocate four hours in case I need to "change tracks" and take care of something else. This may seem like overkill (and often, it is), but it's a shorthand I use so I don't over-commit or underestimate how long it will take to do something. Even with this model, I still underestimate a lot of things, but with experience I get a bit better each time.

This of course leaves the last area (Category I), the Urgent and Important. Usually, it's a crisis. It's where everything else ends up getting bagged for a bit. If you ever find yourself in an automobile accident, and you are injured, guess what, your getting treatment and recovery rockets to Category I. In a less dire circumstance, if you are the network operations person for your company and your network goes down, for the duration of that outage getting the network to work is Category I.

I hate making promises I can't keep, but the truth is, I do it all the time. We all do, usually in small ways. Unless we are pathological liars, we don't intend to get into this situation, but sometimes, yes, the expectations we place on ourselves, or the promises we make to others, grow out of proportion to what we can actually accomplish. Take the time to jettison those things that you will not do. Clear them from your mind. Make exit plans for the things you'd really rather not do, if there is a way to do so. Commit to scheduling those items that provide the greatest benefit, and if at all possible, do what you can to not get into crisis situations. Trust me, your overall sanity will be greatly enhanced, and what's more, you'll start to develop the discipline to grow an expectation surplus. I'm working towards that goal, in any event ;).

Giving Kids a Jump Start: The Humble Braniac Book Bundle (UPDATED)

Wednesday, February 11, 2015 20:17 PM


As many of you are no doubt aware, I have a very long list of books that are in the hopper to be read, processed, applied and reviewed. Those books all come from somewhere. Some of them I buy, but a fairly large percentage of them are given to me (with the proviso that I review them). NoStarch Press has been a partner with me in this process for the past four years. I am very appreciative of their contributions to my technical knowledge and understanding.

It's with this in mind that I want to alert TESTHEAD readers to a special offer. NoStarch Press and the folks at Humble Bundle have teamed up to offer a jump start for kids who want to learn programming and other technical skills. This is really significant right now for me, as I have a 14 year old daughter in the early stages of learning how to program.

What could that special offer be? I'm glad you asked ;).



Until February 18, 2015, 2:00 p.m. EST, Humble Bundle will be offering the "Humble Braniac Book Bundle". This is a variety of e-books geared towards kids so that technical subjects are more accessible to them. What makes this bundle interesting is that YOU get to decide how much you want to pay for it. Yes, you read that right, you get to name your price for a selection of books that, if purchased separately, would cost more than $250.


What do you get with this deal? There are three levels:

1. You can pay any amount of money (seriously, you decide) and for that payment, you will receive:
  • Ruby Wizardry: An Introduction to Programming for Kids
  • Lauren Ipsum: A Story About Computer Science and Other Improbable Things
  • The Manga Guide to Electricity
  • Snip, Burn, Solder, Shred: Seriously Geeky Stuff to Make with Your Kids
  • The LEGO Adventure Book, Volume 1: Cars, Castles, Dinosaurs & More!

2. Humble Bundle keeps track of the average payment. For those willing to pay more than the average (which at the time of this writing is $13.08), NoStarch will sweeten the deal and throw in:
  • LEGO Space: Building the Future
  • The Manga Guide to Physics
  • Python for Kids: A Playful Introduction to Programming
  • Incredible LEGO Technic: Cars, Trucks, Robots & More!
  • Build Your Own Website: A Comic Guide to HTML, CSS, and WordPress

3. Customers who pay $15 or more will receive all of the above, plus:
  • Steampunk LEGO
  • JavaScript for Kids: A Playful Introduction to Programming
  • The LEGO Neighborhood Book: Build Your Own Town!

For less than the cost of one retail NoStarch book, you can purchase and download thirteen books that will entertain and educate kids and adults alike. My personal recommendations, "The Manga Guide to ..." series of books are great fun and super informative. I have also read or am reading Ruby Wizardry, Python for Kids and JavaScript for Kids books (reviews pending), and they are all individually worth the price of purchase. In this format, plus all the other titles being offered, really, this is a sweet offer.

As if that weren't enough, all Humble Bundle promotions let purchasers choose how much of their money goes to the publisher (NoStarch), Humble Bundle, and charity. The two charities supported by this bundle are the Electronic Frontier Foundation (EFF) and the Freedom of the Press Foundation.

NoStarch has been great to me for many years. I really appreciate their willingness to provide me books to review. To be transparent, I have many of the books in the list already (that NoStarch gave me for free to write reviews), but there are several in this bundle that I don't have, and I have bought in for the Full Monty :).

This Humble Brainiac Book Bundle ends February 18, 2015 at 2pm EST time, so if you want to take advantage of it, best get a move on!


UPDATE: As of February 11, 2015, The Humble Brainiac Book Bundle just got a little sweeter. Three new books just got added to the "pay more than the average" bundle. Those new books are:

- The Manga Guide to Calculus
- Beautiful LEGO
- The LEGO Build it Book, Volume 1: Amazing Vehicles

If you have already purchased your Humble Brainiac Book Bundle, go to the confirmation email and click on the download link... the new books have been added and you can download them from there. Yes, they've been added to orders already purchased. Nice job, Humble Bundle and NoStarch... well done :)!!!

Two Great Tastes that Go Great Together :)

Tuesday, February 03, 2015 20:42 PM

Crossroads: Success or Failure by StockMonkeys.com, on Flickr
Creative Commons Creative Commons Attribution 2.0 Generic LicenseStockMonkeys.com
One of the things I enjoy hearing about is when engineering teams give credit to their testing teams and customer support teams. Both play important roles. In fact, it’s common to see software testers and customer support people wear each others hats. I personally spent a few years in my career doing both roles simultaneously, so I appreciate how, in many ways, customer support and software testing are two sides of the same coin.

Imagine my smile when I read "The Incredibly Obvious Secret: Finding (and Fixing) Product Bugs Through a Close Relationship Between Test and Customer Support”, written by Jay Kremer and posted to the Zoozk Engineering Blog. How, might you ask, would I think to be looking at an online dating web sites engineering blog? For that, I have to thank the great group of software testers who attend the Bay Area Software Testers Meetup group. One of them is the Test Manager at Zoosk, and he told me about this article and suggested I have a look. OK, yeah, that test manager is Jay ;).

In any event, I felt a lot of kinship with this post, and I wanted to have a chance to reply to it and say that, yes, there are organizations that do have this kind of relationship in addition to Zoosk. I work for one of them.

At Socialtext, if a  customer reports an issue, the first line of contact is a real human being who walks through the issue with them. The support engineer can often see the the potential value of the bug in question (it’s real, it’s reproducible, it’s potentially impactful, and it has a high probability of affecting a number of people). At this point, that support person can contact us, or we can go over to them and say “hey, anything interesting coming in?”, and they will tell us what they are working on.

Socialtext has the approach that bugs get on the Kanban board as soon as we can identify and reproduce the issue (again, the easier it is to quantify the problem, the easier it is to fix, generally speaking). It is not at all uncommon to have a bug be reported one day, scheduled in the Kanban and picked up on the second day, a fix committed and tested, and then merged to our staging environment in short order thereafter. We are a company that runs most of our businesses processes on our product. This makes us, essentially, the primary alpha and beta testers, which in turn allows us to address bugs quickly, at least most of the time. It seems that Zoosk has a similar philosophy.

I have often said that customer support engineers make for awesome testers, and software testers can often make amazing support engineers. Like Jay, I believe this is a symbiotic relationship that needs to be enhanced and encouraged, and more testing organizations should make that connection and work closely with their support teams, not just for when they report issues. Software testers can learn a lot about the true state of their product and the workflows that really matter by spending some quality time with the support team. I think you will be pleasantly surprised with what you learn.

A World Without "Heroes"?

Friday, January 23, 2015 16:12 PM

As is often the case, there is a two level thought process that goes into every one of my "Uncharted Waters" blog posts. The first is the thought and consideration that goes into the lead up to, the writing of and the making public of the post. The second is what happens usually within the first twenty-four to forty-eight hours after the post goes live, because I will get a comment or a thought from someone that will make me slap my head and say "Oh! Yes! That! That would have made sense to say!"

In my most recent Uncharted Waters entry "Heroes, Hubris and Nemesis", I decided to take on the "hero culture" that tends to exist in various companies, and the fact that, instead of them being shining examples of excellence, instead, those so called heroes are very likely the bottleneck to their team. I then spent the rest of the article giving advice about how to deal with all of that.


After the post went live, Michael Bolton posted a comment that was, quite frankly, the perfect follow on:




"Oh! Yes! That! That would have made sense to say!"


Here's where I think we really could make a difference. What if, instead of calling the person that does these things a hero, we used terminology like this instead? What if, for the people that hoard expertise, we called them out for doing exactly that? What if we made the perpetual online and self-flagellating martyr of the team out to be the problem rather than the savior of the organization? Would behavior change? I believe the answer is yes.

Alan Page and Brent Jenson talked about this in Episode 14 of "AB Testing" back in December. They likewise described a "hero" on their team and the way they did things. Brent described the challenge he had with a person that had no desire to teach others, because if others were taught, they wouldn't be special any longer. In addition, what was really happening was that, due to the existence of this particular hero on the team, management didn't have to invest the time or emotional energy in the rest of their team, because their hero was there to save the day.

What if, instead of extolling the hero, this team instead called out that behavior as anathema to their success? What if management had instead insisted that this person be given advancement based on how well and how frequently this person crossed trained the team, and made it clear that any opportunity for advancement would hinge on their ability to teach others and bring the whole team up to that person's level? What if, instead of praising the "hero" instincts, the management instead called out their opaque approach and unwillingness to share as fatal detriments? Do you think the entire culture of that team would have changed? I certainly do. One of two things would have happened. Either that person would have worked hard to train up the team, or that person would have left of their own accord because they would realize that their "heroics" were not going to be their differentiation. Either way, the team would have been better off, because the team as a whole would have to deal with the imbalance of skills. By relying on the hero, management was taking the lazy way out. They (management) didn't have to invest the time and energy in the rest of their team, the hero got to play the public martyr, and everyone was happy... at least until a crisis came where the hero couldn't step up.

My solution was to make a team of heroes, but perhaps the better way, the more appropriate way, is to try to remove the hero moniker from those who are not working to help the entire organization succeed. It would take a lot of guts, but I think the teams willing to do the latter will long term be better off than those who don't.

Do You Want to Move Testing Forward?

Monday, January 26, 2015 22:11 PM



The Association for Software Testing (AST) is holding its tenth annual conference this year. The Conference for the Association for Software Testing (CAST) will be held in downtown Grand Rapids, Michigan on August 3-5, 2015. Ten years is a cause for celebration in my book, and we are throwing a party. I say "we" because I am part of the Board of Directors and the President of AST, and therefore this conference is a big part of what 2015 will be shaping up to be for me.

The theme of the conference this year is “Moving Testing Forward”, and to that effect, I want to reach out and encourage my fellow software testers, programmers, quality advocates, or whatever area you see yourself, to put in a proposal for this year’s conference.

My belief is that the best way to move testing forward is to do so with more voices, and CAST is well known for being the conference where new and unique voices are heard. Several great speakers have developed over the years, and CAST has been quoted as being where many of them first had the opportunity to present. We want to encourage that approach further, so I am sending out a personal call to those software testers who might still be on the fence.

- Maybe you are a relative newcomer.
- Maybe you have not spoken in front of a large group before.
- Maybe you work in an industry and an environment where you think “oh, nobody would be interested in hearing what I have to say”.

Let me assure you, that last one is categorically false. In my opinion, the best talks and presentations are not built around theories or tools. They are built around real world experiences, the good, the bad, the occasionally ugly, and the often unintentionally hilarious.

I had the pleasure of having dinner last night with a couple of friends, both involved in various levels of software delivery, including software testing, and the stories we were sharing, and frequently laughing about, came from our core experiences, what we have witnessed, and what we have learned from those experiences. As I listened and participated with my friends, I mentally ticked off six or seven talk ideas and said “wow, these stories, and the lessons learned from them, would be so great if we could get them out to more people”. I have a pretty good feeling that several of these conversations will become talks at CAST, but the main point I want to encourage is that “your real world experiences make for great talks!

The Call for Participation for CAST 2015 ends on January 31, 2015. That’s a little under ten days from now. I’d like to encourage all of you, if you are able, to propose a talk for CAST. How are you moving testing forward? There’s a very good bet that what you are doing (or perhaps wish you were doing, or perhaps not doing) will be of great value to your fellow software testers. We encourage people from all arenas, all experiences, and all backgrounds to come share in each others ideas and approaches. There will be a lot of fun things happening at CAST 2015. We want you to be part of it :).

Experience is Earned, Expertise is Granted

Wednesday, January 21, 2015 21:55 PM

This title is meant to be a little provocative, and some may disagree with it, but I've been thinking about this topic quite a bit recently. First of all, I want to say thank you to Ryan Arsenault and the folks over at uTest for showcasing me in their first "Ask the Expert" blog entry. The questions I was asked centered around career choices for testers and ways that we can succeed, or at least do better than we are now.

I cannot help it, part of me feels very strange using the word "expert" to describe myself at anything. I'm happy to use words like experienced, educated, practiced or even proficient, but "expert" carries a strange weight to it. It's so subjective, and it feels like, once you've been branded one, that there's only one way to go from there, and that's down. Moreover, I don't really believe there is such a thing as an "expert", because that implies that that person has learned all there is to learn and has mastered all there is to master... and that's just fundamentally wrong on so many levels.

I've come to realize that we all own our experiences, and that we all have opportunities to learn from our successes and our mistakes (oh, how much I have learned from my mistakes). This is why I have no problems talking about my experiences or my observations. They are mine, and as such, are certainly open to interpretation, or debate, or scrutiny, or even outright ridicule at times, but they are wholly mine. Expertise, however, is a judgment call. I personally have very little trust in people who proclaim themselves to be "experts" at anything. However, I place a lot of credence on other people who tell me that someone is an expert. Why? because they are witnesses to the skill, acumen and judgment being displayed, and they can then decide if the term "expert" makes sense.

It also often comes down to "expert compared to who?" I have many interests, and things that I spend a lot of time getting into. When I tell people I was a competitive snowboarder for several years, it conjures up an image in their minds; I must be an expert snowboarder. They may even watch me ride, and come to that conclusion because of the technique I can muster and the terrain I can ride on. Yet put me alongside other riders I used to compete with, and any questions of my so called "expert" level goes right out the window. That doesn't take away from what I have learned, the events I've participated in and the medals I won, but to use those hallmarks to say I am an "expert" is, in my mind, misleading. Still, to others who have never raced, or are newcomers to the sport, to them I am an expert, insomuch as I can show or teach them things that they do not know.

Again, I thank uTest for giving me an opportunity to share my experiences, and I am honored to be part of their "Expert" panel. I don't know if I deserve the moniker, but they seem to think so, and so do their readers, and ultimately, I guess that just means it's up to me from here on out to either prove them right, or prove them wrong. Here's hoping my actions and efforts do more to strengthen the belief in the former, rather than proving the latter ;).

Take Two: A Survey on “The 2015 State of Testing”

Wednesday, January 21, 2015 18:52 PM

So let me set the stage here….


Joel Montvelisky wanted to write a post about the advances that have taken place in the tester-verse in the last 5-10 years. While he was trying to put this post together, he came to the conclusion that there really isn’t a centralized set of information or trends as to what is happening in the testing world.

What does a tester do when they can’t find that information? They take it upon themselves to make their own. Trust me, I understand this logic completely ;).

Thus, Joel reach out to Lalit Bhamare (who edits Tea Time with Testers) to create and conduct a State of Testing Survey. The purpose? To provide a “ snapshot” of what the “ reality” of the testing world is, and see if we can follow various  trends as they shift year by year.

For those feeling that this post is a dose of “deja vu”, well… yes, it is! The above couple of paragraphs are pretty much word for word what I wrote towards the end of 2013, when the last version of the survey was posted. Joel, Lalit and others who were asked to contribute to it are now bringing forward the 2015 State of Testing survey. I had a small hand in reviewing and helping shape this second go around for the survey.

Also, just like in December of 2013, for this survey to be effective, many people need to participate. With that in mind, I’m doing my part once again to help spread the word and encourage everyone to participate



This survey will be going live roughly 00:00 Thursday, January 22, 2015 (Pacific Time). Right now, there’s a countdown saying when it will go live, so if you go there right now, you’ll see the countdown. Come back when it tells you it’s done, or subscribe to get the official go-live message. Like last time, I am anticipating the survey will be up for about ten days.

So here’s what I am asking… again ;):

  1. Go to the link and subscribe so that they can contact you when the survey goes live.
  2. Participate in the survey and give you honest feedback.
  3. Make a point to tell as many testers as you can to likewise participate in the survey.


For those who would like to see what the end of 2013 survey looked like, at least as far as the survey responders said, the link to the results are on the page as well. Also, a disclaimer; this survey is, like all things, subjective and reflective of the respondents as a whole. It may or may not reflect your own reality, but then, if you don’t participate, it definitely will not reflect your reality, or even a statistical sliver of it. If you want to give your opinion or have your voice heard, well, now’s your chance :).

Book Review: Design Accessible Web Sites

Tuesday, January 06, 2015 21:23 PM

This is a bit of a retro review, but since I’m in the process of putting together a talk about the design and testing aspects of sites as relates to accessibility, this came recommended as a good starting point.

Many books that talk about designing for accessibility tell you a lot of the what and the way around accessible design, but don’t put much emphasis on the how. Jeremy Sydik’s book “Design Accessible Web Sites: Thirty-six Keys to Creating Content for All Audiences and Platforms" does an admirable job on explaining the "how" of accessible design.

This book was originally published in 2007, so the technical underpinnings of the web have certainly changed a bit, but the overall message of “Design Accessible Web Sites” is still very relevant and still very usable. In the current rush for the latest and greatest, with frameworks abounding to handle just about every conceivable interaction, there comes a need for programmers and site designers to step back and consider if they are making it possible for the most people to use the sites and access the content they provide.

The core of the book revolves around what Sydik calls the Ten Principles for Web Accessibility:


  1. Avoid making assumptions about the the physical, mental, and sensory abilities of your users whenever possible.
  2. Your users’ technologies are capable of sending and receiving text. That’s about all you’ll ever be able to assume.
  3. Users’ time and technology belong to them, not to us. You should never take control of either without a really good reason.
  4. Provide good text alternatives for any non-text content.
  5. Use widely available technologies to reach your audience.
  6. Use clear language to communicate your message.
  7. Make your sites usable, searchable, and navigable.
  8. Design your content for semantic meaning and maintain separation between content and presentation.
  9. Progressively enhance your basic content by adding extra features. Allow it to degrade gracefully for users who can’t or don’t wish to use them.
  10. As you encounter new web technologies, apply these same principles when making them accessible.


Part 1 lays out the case for why accessibility is important (it’s good business, it;s the right thing to do, it’s the law in many places, and accessible sites are more usable for everyone). This section also steps through a variety of disabilities, some of which we automatically associate with Accessibility (visual, auditory and mobility impairments, as well as a variety of cognitive impairments and those who deal with a combination of the previous issues, specifically due to the results of aging). It also introduces the first eight “keys” of preparing for making an accessible site, including planning, making multiple access paths, avoiding the WET trap (WET stands for “Write Everything Twice”), and to set a solid foundation of accessibility testing, which really does require sapient skills to do. Automation can tell you if a tag is there or not, but it cannot tell you if a user experience for a disabled user is comparable to one for a normative user.

Part 2 focuses on building a solid structure for your pages, with thirteen additional keys to help you design your pages with accessibility in mind, such as keeping the site design simple, removing style from structure as much as possible, using links effectively, designing interfaces that emphasize the selecting of elements and actions rather than drag and drop movement, breaking away from tables and creating forms that are easy to follow and intact with without losing their interactivity or power.

Part 3 focuses on the visual aspects of the web, specifically how we deal with photographs and video clips. the nine keys in this section focus on selecting colors that contrast and don’t blend together, utilizing alt tags as more than just a place holder for generic text, and encouraging a design that can describe itself and allow the user to “see” the whole picture, or “hear” the whole story, even if those options are not on the table.

Part 4 looks at some additional aspects of accessibility and rounds out the last six of the thirty-six keys with how to work with documents that are not traditional for the web, options for dealing with PDF files, scripted output, as well as with Flash and Java apps.

Part 5 is a reference to a variety of web accessibility guidelines including WCAG, US Section 508, and examples from around the world, including Australia, Canada, European Union, Japan, United Kingdom, United Nations, etc.

Bottom Line:

To design sites that are accessible, we have to think differently, but the differences need not be radical. Also, accessible design need not be boring design. There are plenty of techniques and approaches to use that will help make sites easier to interact with for a broad population, and for those willing to embrace this approach, having the capability of designing sites that are accessible could be a differentiator for you as compared to other designers, programmers and testers.  As the tenth principle says, "As you encounter new web technologies, apply these same principles when making them accessible.” Technology moves on, but the advice and methodology is still sound, making ‘Design Accessible Web Sites” an evergreen title to consider for years to come.

In Through the Side Door: Advice from an Unconventional Career

Thursday, January 01, 2015 19:38 PM

First off, Happy New Year to all of my friends and readers out there. I wish you all a great 2015 with the hope that what you strive to do and accomplish will be met.

About two years ago, I was given the opportunity to do a talk for a conference that would be happening in India called ThinkTest. My friend Smita Mishra extended an invitation to me to participate, and while I could not actually travel to India at that time, we decided to try something unorthodox. Why not video-tape my talk, and we would whittle it down to a presentation length and make it available to those who wanted to view it? Since I found myself in a hotel room near Chicago for an extra day, I decided to turn the room into a makeshift film studio and talk about my career as a software tester, its ups and downs, and other things that helped make it a reality.

Sadly, due to an automobile accident that incapacitated Smita for awhile, the conference had to be canceled. The talk project was, of course, put on hold, and then, over time, other initiatives took center stage, and I forgot about the talk and the recordings... that is, until a couple of months ago. Lalit Bhamare of Tea Time With Testers, asked me if we could use the material for his new project, TV for Testers. I said "sure", and he then proceeded to gather the clips I had recorded and delivered to Smita into the talk that is presented here.



In Through The Side Door

First, I feel it only appropriate to say... this is a long talk! I had originally recorded it with the idea that we would cherry pick the best parts and make a shorter presentation (something around forty minutes) but through correspondence with Lalit, he asked if it would be OK to present the entire talk, in its (mostly) unfiltered form. He felt that there was a lot of insights I offered that would be of value to those who, likewise, came to their careers from peripheral avenues, and the asides and segues, in his opinion, actually added to the value of the talk. So, again, that's what we decided to do. Lalit posted the talk on TV for Testers today, and I am now saying to those who would like to check it out, please do so.

Again, my thanks to Smita for asking me to put this together, and my thanks to Lalit for deciding he wanted to have it be seen. If you take the time to watch it, I also thank you for doing exactly that. To borrow from and paraphrase the recording artist Seal, "I hope you enjoy the presentation; it was the best material I had at the time" :).

Short Story/Serial Book Review: Markram Battles

Tuesday, December 30, 2014 15:58 PM

"And now, for something completely different!"

I am one for whom Dan Carlin's phrase "History has all but ruined fiction for me" rings true. I find that the real life exploits of historical figures, and the reality of their worlds, tends to make many aspects of fiction story telling, well, just not hold much interest. Fictional Mob Boss or the struggle for Alexander the Great's throne? Mythical marauders or real life Scythian warriors and their waves of descendants? Seriously, how can anyone top the Mongols, in fiction or elsewhere?

Still, there's a part of me that loves the "what if's" of both the near and distant future, with the possibilities, be they wondrous or terrifying, that make science fiction a place I enjoy spending time in. Added to that is my love of Role Playing Games, especially those that come from Japan (think the Final Fantasy series, Shin Megami Tensei, and Suikoden). Also, I love Animé series that look at the struggles of everyday people against overwhelming odds (think "07-Ghost" or "Gantz").  When something hits that sweet spot of all of those interests, and still focuses on the humanity of story telling, I pay attention. Add to that having an author of such material being a personal friend? Well, what else can I say? I want to share, and share I shall :).

M.C. Muhlenkamp is putting together a series of short stories that feel one part ancient Rome, one part Eurasian steppe, one part Japanese RPG and one part Young Adult dystopian struggle. Weave these all together and you get what is shaping up to be "Markram Battles". More to the point, "Markram Battles" takes a cue from the past, in that it is really a serialization. If you liked the idea of Alexandre Dumas publishing his "Three Musketeers" in small pieces, waiting to see where and when the next "dose" will appear, then here's an opportunity to do exactly that.

M.C. takes us into a word where "Earth as we know it no longer exists." In its place is an empire that looks to "recruiting" humans as "battle entertainment", specifically women. The rules of the battles are simple. Fight and win, or die trying. The story focuses on the interactions between the the empire of the Markram and the humans who are forced to play their game to survive. The first and second deliveries ("Genesis of an Uprising" and "Omens of Doom") focus on the interactions between Seven, a Unit Leader whose sole purpose is to lead recruits in battle, and Thirteen, an unwilling recruit who refuses to play the game, at least not in the way that the Markram want her to play.

The chapters are short and taut. The characters are believable even in their other-worldly space. Little in the way of useless exposition is given. The reader is expected to go with the story and figure out the world and its parameters without long winded explanations as to what has gone on before, except where it makes sense to give context to the situation. Even in the first short sections, you find yourself caring for the characters and wondering what will happen next, on both sides, Markram and human.

The cover sets the tone and the mood of the stories, and in this way, I can't help but feel drawn to parallels made in video games like "Shin Megami Tensei: Digital Devil Saga" or Anime like "07-Ghost", each with a fight to survive ethos and a shadowy "other" pulling the strings. The stories feel like they are designed for a YA audience, but don't let that dissuade you, as the themes and the stories focus are strong enough for all ages.

Bottom Line:
The serialization approach works well for this series. It feels like a Manga without the pictures, and that's meant as a solid compliment. Two issues in, I find myself asking "OK, so when will number three be ready?" If stories about human spirit and desire to not cave to the rules of an unfair system hit a sweet spot for you, give these stories a try. They are quick reads, and at $0.99 apiece, less expensive by far than a manga series, and every bit as engrossing and satisfying. Yes, MC and I are friends, but I'd dig this series even if we weren't ;).

In Praise of Khan Academy

Monday, December 29, 2014 19:17 PM


Back a couple of weeks ago, I tagged along with my daughter Amber to bring her to Hour of Code. The class that she chose was being taught through Khan Academy, and as a person there, I figured I'd tag along and see what she was doing. In the process I set up an account, and then I forgot about it for a couple of weeks. 

During my holiday break, I was reading some posts about mathematics education, or in some cases lack thereof, and a friend of mine, who is a long tenured engineer, told me that he had gone back through Khan Academy and walked the Mathematics section, solely for the purpose of seeing how much he had forgotten over the years. His final analysis. It turns out he'd forgotten a lot of things, but more to the point, he mentioned that he came in contact with concepts that he had never studied, and how fun he found it to go through and check those areas out.

I must confess, it takes a special kind of masochist to go and do math "for the fun of it", or should I say, that was my initial reaction. Still, I found myself with several days off last week, and will have several more this week, so I made a personal challenge for myself to take on the same challenge. There is a track called "The World of Math", and it covers everything from the basics of Kindergarten level arithmetic all the way through to Linear Algebra. For the record, I managed to make my way through in my twenties to completing mathematics courses up to and including Differential Calculus, and then I hit a wall. I fancied that, maybe, I could give my old rusty neurons a workout and see if I could push through it all and get to those areas I never learned.

To date, here's where I stand (after three days of off and on focus on this goal):


To add to that, I have pulled in several other topics that just tickled my fancy, and I've been having a lot of fun walking through and checking them out (as of last Tuesday, I've gotten through entire lecture blocks on World History, Biology, Music Appreciation and Greco-Roman art). The materials range from really well produced to someone's screencast on a topic that interests them. All of them are proving to be a fun way to spend time and learn. Because much of the material is bite sized, i.e. can be viewed in anywhere from five to ten minutes, you get the feeling that you are getting a broader appreciation for these subjects, and doing so a little bit at a time (and quite often, you find yourself realizing that you are spending a lot of time, but you don't mind it one bit!).

If someone told me earlier this month that I would have spent close to twenty hours on Khan Academy in less than a week, I would have said "aw, come on, who has time for that?" Well, it turns out, I do! You might also notice that I haven't mentioned anything about their computer programming or computer science offerings. In addition to their Hour of Code, they also offer some respectable HTML/CSS and JavaScript tutorials and coursework, and some stuff on algorithms, cryptography and information theory. It's not enough to cover all the details, but paired with Codecademy and some other initiatives, there's a good chunk of material there to get anyone curious about programming to be able to make a fair stab at getting proficient. What's also cool is that Khan Academy keeps adding more and more material all the time.

My apologies for being late to this particular party, but I have to say, for anyone looking to brush up on long forgotten basics, learn something new in a super low pressure environment, and just plain have fun doing it, seriously, give a gander to Khan. I think you will enjoy what you find :).



BAST in the Saddle Again: New Talk for January, 2015

Monday, December 22, 2014 20:40 PM

As many of you saw last month, we had some dramatic happenings in the Bay Area Software Testers Meetup group. We want to usher in 2015 with a bang, and to that end, I am please to say I will be giving a talk on Thursday, January 8, 2015 and I want you all to come.

Now, granted, this is probably going to work best for people who will happen to be in the San Francisco Bay Area on Thursday, January 8, 2015, but hey, why be exclusive ;). Seriously, though, if you can make it, here's the details about the event and what we will be covering:


All for Web, and Web for All: Designing and Testing for Accessibility - Michael Larsen

As the web, mobile, and other devices we have yet to fully comprehend proliferate around us, we want to do our best to cater to the customers that best represent the users of our products. However, there is a population that is frequently left with little to work with, and that is those who have to deal with physical disabilities. Issues with sight, sound, motor movements, comprehension and other disabilities puts many sites and apps out of reach for those who would most like to use them.

Making products that are accessible is more than just implementing a few tags so a screen reader can spell out the terms, it involves designing a product from the top down to be navigated easily and seamlessly.

In this talk, I will present some challenges those with disabilities face, ways that we can design products to better work for those with various physical disabilities, and that testing for accessibility can be a fun, interesting and important part of your organizations product offerings.

To RSVP, please see the formal invitation and event details HERE.

For Your Listening Pleasure: TESTHEAD’s Podcasts

Friday, December 19, 2014 14:07 PM

It’s the end of the year, and it seems that people are going to be getting all sorts of new devices for the holidays. Smartphones, tablets, computers, etc. will likely be purchased by many, and with those purchases will be a need to fill them. In my personal opinion, while video tutorials and such are cool and all, nothing is as portable, engaging and good for short bursts of calm time, semi-active physical exertion or long road/air trips than podcasts. 

Thus, in the spirit of giving, I would like to give everyone a taste of my current listening habits, my podcasts of choice. Some of these have been with me for years, some are relatively new, all of them are informative and engaging (well, at least I think so). 

Additionally, I have also included websites with background info and storage for previous episodes. All are free for newer episodes, some sites charge for back catalog items. Most of course appreciate donations to help them keep the shows going, so by all means, if you can offer them support to keep producing stuff you like, hey, show a little love :)!

And now, without further ado…

AB Testing
Alan Page and Brent Jenson (AB testing, get it ;)?) talk about a variety of software testing topics and their combined four decades of experience, as well as their own meandering thoughts and topics that happen to come into their heads. Both Alan and Brent are long time Microsoft veterans, so there is, of course, a Microsoft flavor to the podcast, but don’t think that just because you don’t live and work in a Microsoft shop that this isn’t for you. There’s plenty to keep a tester (or anyone interested in software quality, regardless of role) interested. What I love about this is that it’s done in a very casual tone, as though they are just kicking back with a couple of beers and ranting about the topics that come up (please note: I have no idea if they are kicking back with beers as they do their podcast, it’s just the vibe it gives me, and I love it :) ). 

Back to Work
Two hundred episodes in, this is still one of my favorite guilty pleasures. Dan Benjamin and Merlin Mann generate a lot of banter in their podcasts, and for those who want the business end of the podcast each week, I’ll help you now with this tip, just fast forward twenty minutes and you’ll be much happier. However, if you’ve been with the show since the beginning, you’ll know that some of the most fun parts of the show actually take place in these twenty minutes, as well as the banter that carries over every show. It’s goofy, messy, often unfocused, but filled with gems if your goal is to really get into the things that make for creative work. Oh, and don’t be surprised if, after a few weeks of listening, you start to look forward to the rambling intros, because you feel like you are getting a glimpse at two of your friends just kicking it and getting caught up on what matters to them, only part of which is the actual podcast.

Common Sense with Dan Carlin
This is the first of two “indispensable” podcasts for me, ones I have listened to for several years, and that I consider the “gold standard” of what the podcast medium can deliver. Dan Carlin is a cantankerous, fast talking, highly caffeinated and animated commenter who bills himself as being “political by way of Mars”. Dan is based in the U.S., and many of the topics he covers are from a U.S.perspective, but what makes Dan different is he refuses to approach problems or issues from a partisan position. For tester looking to exercise their critical thinking skills when it comes to political topics, this podcast is a jewel. 

Freakonomics Radio
The subtitle of this podcast is “The Hidden Side of Everything”, and it tends to remain true to that tagline. Stephen Dubner and Steven Leavitt are the hosts of this eclectic show that mostly looks at economics, but is wonderful for testers because it looks at teasing out what the data tells us about a variety of topics. We think we understand how things work, and why the world looks the way it does, but very often, the hidden realities go counter to the agreed to narrative. Often controversial, always fascinating.

Grammar Girl: Quick and Dirty Tips for Better Writing
This is the first of the “Quick and Dirty Tips” podcasts that I follow, and the fact that I fancy myself a bit of a writer on the side of being a software tester, it should come as no surprise that I would appreciate a regular infusion of grammar and interesting ways to improve my game as a writer. Grammar Girl is hosted by Mignon Fogarty, and is full of interesting tips and tidbits about language, grammar construction, writing tropes, and etymology. There are as of this writing 446 episodes. That’s a lot of potential grammar tips, and while you may not want to listen to every one of them, you will not surprise me in the slightest if you come back and tell me you have heard them all ;).

Hardcore History with Dan Carlin
Of all the podcasts I listen to, most of the episodes are listened to once or twice, and then I delete the ones I listened to already. I do not delete episodes of Hardcore History! I have saved every one of them since the beginning, and I have listened to each episodes multiple times (and that’s no small feat, considering several of the Hardcore History podcast episodes are multiple hours long). Dan Carlin uses the same “Martian” approach to thinking as used in the Common Sense podcast and applies it to historical events. Earlier podcasts were brief entries, while the most recent podcasts would count as full audio books. Dan has a style of delivery that is dramatic, intense, and for me personally, enthralling. Many of the podcasts are continuous series. He’s currently doing a multi part series on the causes and effects of the First World War. The combined total time for this series (titled 'Countdown to Armageddon") is currently almost fourteen hours, with more episodes still to come. Do not be surprised if you find yourself listening for hours at a time. In my opinion, Hardcore History is the perfect long drive or long flight companion, and is still, to me, the gold standard of podcasting.

Philosophize This!
Stephen West hosts this podcast that endeavors to be a chronological exploration of philosophy and epistemology, and if listened to in order, does a very good job of being exactly that. Stephen goes to great lengths to keep a consistent narrative between episodes, and flashes back to what previous philosophers have said to help develop the context for current episodes. He mixes in modern metaphors to help make some of the esoteric bits make sense, and it makes for an overall very enjoyable and interesting series.

Planet Money
Hosted by NPR, and born from the wreckage of the 2008 Financial Crisis, Planet Money has a similar feel and approach to Freakonomics. It’s a very economics based program, with a smattering of finance and a lot of current events, and much like Freakonomics, ventures into territory that is unexpected and open to interpretation. If you think you know that’s going on, you may be surprised to realize how different things look when you “follow the money”.

Ruby Rogues
Ruby Rogues is a revolving cast of commenters, many of which are well known in the Ruby world, and frequently feature guests that talk about a variety of programming topics. I started listening to Ruby Rogues when I worked at a primarily Ruby and Rails shop, and while I have moved on to a work environment that uses different languages, I still listen regularly to this well done and well presented podcast. You do not have to be a Rubyist to reap benefits from listening to the show, but if you are familiar with Ruby, it makes each episode that much more interesting.

Savvy Psychologist: Quick and Dirty Tips for Better Mental Health
This is another Quick and Dirty Tips podcast I enjoy following, and I became interested in it due to some of the challenges I’ve dealt with around my own diagnosis and repeated wrestling with issues related to ADHD. Dr. Ellen Hendrickson tackles a variety of psychological challenges, puts it in terms that every day people can understand and relate to, covering topics such as procrastination, anxiety, depression, motivation, mood and creativity. Understanding the challenges we all face helps us relate better to those we interact with, as well as ourselves. 

Still Untitled: The Adam Savage Project 
You may know Adam Savage from his ten year plus run on the Discover Channel’s “Mythbusters”, but this series goes beyond his most well known career choice and talks about his involvement with special effects, the maker movement, and tests and explorations related to oddball interests. If you enjoy the Mythbusters approach and delivery, you’ll probably enjoy this podcast, too.

Stuff You Missed in History Class
As my interest in Hardcore History will likely tell you, I am a fan of history. I love the obscure and interesting bits and the connection to us today. However, Dan Carlin puts such time and attention to each episode, it can be months between episodes. This podcast (which is part of the “How Stuff Works” series of podcasts) is a twice a week history snack fest. Shows cover a wide variety of topics, often focusing on the weird or unusual. It’s great fun and a must listen for the avid history buff.

Stuff You Should Know
How did leper colonies come into being? What is terraforming? What did the enlightenment actually “enlighten”? If you’ve ever found yourself wondering about these things, and literally hundred more areas, then this podcast is right up your alley. Twice a week, the podcast covers interesting and unique topics that, when taken together, cover all sorts of areas that I may know a little bit about, but I always learn just a little bit more. If the idea of learning more about rogue waves, X-rays, and stem cells interests you, then this is a great destination.

TED Radio Hour
If you’ve ever seen or heard a TED talk, you know the format and approach. TED Stands for “Technology, Entertainment and Design”, and each hour long episode is based around a theme, with a talk from one or several presenters to build each themed episode. Programs range from games and gaming and how it relates to psychological development, to self determined education in Africa, to working with perceptions, to our relationship with animals. Guy Raz hosts this weekly podcast, and each week is a unique exploration into the unexpected.


Again, these are my favorites for this year and as of today. Next year, this list may be entirely different (though some will probably be perennial favorites). Here’s hoping some of these will be interesting to you, and hey, if you have some favorites you’d like to share, please post them in the comments below.

Spreading Some E-Book Holiday Cheer: #Packt5Dollar Deal

Saturday, December 20, 2014 20:21 PM

For the life of this blog, I have deliberately avoided any direct advertisement, or made any attempt to "monetize" it. I plan to keep it that way, since not accepting advertising allows me to say exactly what I want to say the way I want to say it.

Having said that, there's no question that several book publishers have been more than kind, giving me several dozen titles for free over the years as review copies. More than half my current technical library consists of these books, and many have been great helps over the years. If I can return the favor, even just a little bit, I am happy to do so.

Packt Publishing, located in the United Kingdom, is one of those publishers, and they are currently holding a special $5 E-book sale. Any and all e-book titles from Packt are available for $5 for a limited time (until January 6, 2015).


Again, Packt has been very generous to me over the years, and I appreciate the fact that they are offering this opportunity. I've already take advantage of it... and have added even more books to my Tsundoku list (LOL!). For those curious, I decided to purchase the following:
  1. Backbone.js Cookbook
  2. Java Script Security
  3. JMeter Cookbook
  4. Kali Linux Network Scanning Cookbook
  5. Learning JavaScript Data Structures and Algorithms
  6. Learning Python Testing
  7. Responsive Web Design By Example
  8. Selenium Design Patterns and Best Practices
  9. Selenium webDriver Practical Guide
  10. Web Development with Django Cookbook
  11. Wireshark Essentials
Happy reading :)!!!

A "Linchpin" Challenge Revisited: New in "Uncharted Waters"

Thursday, December 18, 2014 19:27 PM

Yes, this is shameless self promotion, and yes, I would love to have you all read my latest post over at the Uncharted Waters blog titled "You Can Live Without a Resume!" I'm kidding of course. Not about wanting you to read the article, but about the shameless self promotion part. If I were really all about shameless self promotion, that's all I would say, but you all know me better than that (or at least I hope so ;) ).

When I say "Live without a Resume", I do not mean live without any reference to you or what you do. What I mean is "spend less time on the resume and spend more time on visible, tangible aspects of your work and what you can do".

If I were to try to convince someone I know my stuff about testing, and all I sent in was my resume, that may or may not get anyone's attention. What I do know is that, if it doesn't match their particular filtering criteria, it may never even get looked at. Personally, I don't want to start a conversation from that position. Frankly, I don't even want to have a conversation stemming from "hey, I looked over your resume, and..."

So what do I want to have happen? Personally, I'd prefer any of the following:

"Hey, I was looking over your LinkedIn profile and I noticed you had several talks posted. I listened to a couple of them, and I'm interested in talking more about what you said"

or

"I was looking at the Weekend Testing site, and I noticed your name listed on many of the sessions. I read a few, and hey, I think we might have something to discuss"

or

"I read several of your published articles. Could we get together and talk?"

or

"I spent an afternoon reading several posts from your blog. I think you're insane, but you might be a good fit for a friend of mine's company. Can I have them contact you?"

For the record, I have had every one of those things happen. No, this is not a way for me to strut and act cocky. Instead, it illustrates the power of having your work be on display in a way that steps outside of having a resume.

I owe this whole experiment to Seth Godin, and I've tried it now for almost five years. Granted, I could be proven wrong tomorrow. The bottom may fall out of the market, I could find myself unemployed, and then all of what I'm suggesting may not work any longer. That is of course possible. So far, though, Seth's hypothesis has proven to be sound, and for that, I am seriously grateful :).

Teaching by Example: Slowing Down to Get Ahead

Wednesday, December 17, 2014 21:20 PM

It's been an interesting month with my daughter, Amber. We have been engaged in an interesting little "tug of war" over the past several weeks. I am realizing that I have to be very careful here, because enthusiasm on the part of the "teacher" can either inspire a student, or completely demoralize them and turn them off.

We've agreed to a simple goal, and for now, that goal is the Codecademy streak. I've told her I don't care if she only does one lesson on a given day, as long as she at least does that one lesson. Of course, I'd be really happy if she did two, or three, or ten, or heck, even do fifty like I did about seven months ago. Yes, I spent a free Saturday and completely pounded through the entire jQuery course. No, I'm not convinced that was the best use of my time, considering how much I still have to look up to write anything today.

What I realized from that particular experience was that my own enthusiasm to "push through" caused me to take shortcuts. I violated what I jokingly refer to as "The First Zed Commandment" which is "thou shalt not copy and paste". Those who have read any of Zed Shaw's books on "Learn [Language] The Hard Way" know that he espouses this pretty heavily, and I do too... most of the time. However, my own impatience often gets the better of me, and yes, I find myself cheating and copying and pasting. If I were looking to get in physical shape for a run, would I get the same benefits if I agreed to run 5K each day, but when I got impatient, I hopped on my bike and rode the rest of the way? Would I get the same training benefit? Would I get the same physical conditioning? The answer is, of course, no. Writing code is the same way.

At this stage, I may wish my daughter were moving faster, but if the net result is that she scores a lot of points, gets a lot of badges, but doesn't remember fundamental syntax or hasn't put the time in to recognize where she has made a mistake, what am I really teaching her? This has prompted me to, instead, ask her what time she wants to sit down with me, her with her computer, me with mine, and we work either face to face or side by side. This way, she sees what I am doing, and how I'm doing it. It may encourage her to do likewise, or she may say "hey, that looks odd, what are you doing?" Either way, it will start a conversation, and then we can discuss the fundamental details. I have to realize that it's better for her to pull from me rather than me push to her.

So fundamentally simple, so easy to say, yet so hard to do when "Dad Brain" wants to carry her along as fast as he can. On the positive side, this is also allowing me to step back and make sure I really understand what I think I understand, with the often neat realization that, hey, I really didn't know that as well as I thought I did. Consider this my solid recommendation to anyone wanting to learn how to code... teach your kid how to code. If you don't have one, see if you can volunteer at a school's computer club and offer your time. What I'm realizing anew is that the example of working through problems for them is a pretty amazing teacher in its own right.

The Weekend Testing Family is Expanding

Tuesday, December 16, 2014 22:00 PM

It is with great pleasure, and a little bit of familial pride, that I announce there is a new kid on the Weekend Testing block.

During the first couple years of Weekend Testing Americas, Albert Gareev assisted me in getting the group off the ground, working on some more interesting and technical topics, and even worked with me to propose and try out the "Project Sherwood" project. We decided that the Weekend Testing model as it was designed at the time wasn't the best model for this expanded idea, but Albert didn't give up the fight.

We've talked a number of times over the past couple of years about how the Weekend Testing model works both as a distributed communication model, but that it can also work well as a live and in person event. We realized that what "Project Sherwood" was missing was that in-person direct give and take element. Albert figured for that to work, it would make sense to try it with a group he already had familiarity with and in a community where such events could be developed and focused on. Since Albert is in Toronto, he figured "why not set up a Weekend Testing chapter in Toronto?"

Why not, indeed :)?!

For those on the East Coast, and especially those in the immediate Toronto area, you are going to get a cool opportunity. Albert is a dedicated and accomplished tester, with a wealth of knowledge and a fountain of ideas. For those wondering if this is going to dilute the current Weekend Testing Americas offerings and sessions, I'm going to say "unlikely", because those who enjoy participating in these events will go to those that make sense for them and their availability. I've attended events in just about every of the chapters over the past five years, so in my mind, the more the merrier. The real winners are the testers that want to participate and learn some cool things.

So what should you do? For starters, go and join the Weekend Testing Toronto Meetup. Follow @WT_Toronto on Twitter. Check Weekend Testing's main site for scheduled sessions. Most of all, get ready for a fun and engaging opportunity with an interesting and passionate advocate for testing.