Courting Coincidence (aka “networking”)

I spoke at a panel at Edmonds Community College today.  It was designed to help students get ideas to increase their chances of finding a job.  The other panelists tended to treat it like a resume clinic or job interview seminar.  They missed the point.

The point was *networking* — the ways people connect and relate to each other.

It occurred to me that even if someone in the audience was successful in landing a job, there was no guarantee they were going to keep it.  I was hired once, and laid off 7 months later. The anxiety of the economy might not stop just because you got hired.  Sure, some bills might get paid, but now you have the problem of wondering when they won’t.

It’s tough out there, but networking has saved me. My reputation has been the battle jitney that has not only protected me from some turmoil, but has been conspicuous enough to attract opportunities.  In that spirit, I give you my ideas to increase the likelihood you will be at the right place at the right time or meet the right person with the right opportunity.

* Twitter: tweet something that really resonates with you. Sure, sometimes saying what bagel you had for lunch might help (that’s actually how I met a worthy speaker for QASIG), but give others a chance to know what you find meaningful. Find a hashtag that you’re interested in (like #testing) and reply to someone who said something that resonated with you.

* Facebook: comment on someone’s status with a link you think is relevant and cool. Post your own status about an test idea you have or a thought about a test tool.

* LinkedIn: There are lots of forums in which to participate, so don’t just post a profile and status and leave it there.

*  Blog: start one or comment on one with your full name and email. Give others a chance to say “Where has *this* guy been?!? He’s got game!”

* Seattle Job Social: A regular meetup of employers and seekers in an informal setting — a popular bar in Belltown. I’ve been to two of them — one as an employer, one as a seeker.  Both were useful, but became less so the longer people drank. 🙂

* QASIG: Quality Assistance Special Interest Group — free — meets every second Wednesday of every odd month. Sponsored by Quardev — hosts a speaker and free pizza. (I’m its speaker chairman.)

* SASQAG: The Seattle Area Software Quality Assurance Group — free — meets every third Thursday at Compucom (Excell) – hosts a speaker and free snackies. Keith Stobie and Tracy Monteith from Microsoft are its speaker coordinators.

* SEASPIN: The Seattle Eastside Area Software Process Improvement Network — free — meets every month at Construx — — hosts a speaker and free pizza.  Jeff Smith and Steven Smith (no relation) are its speaker coordinators.

* Seattle Lean Coffee: meets every Wednesday morning at Uptown Espresso — free — hosted by Jim Benson and Jeremy Lightsmith.  Devoted to talking about software development problems in the context of  principles and notions of Lean, Agile, XP, Scrum, kanban.

* Open Coffee: meets every Tuesday morning at Louisa’s Cafe on Eastlake. Devoted to entrepreneurs who want to meet with others, as well as venture capitalists.

* OWASP: The Open Web Application Security Project — a meetup dedicated to discussing software  security issues.  This is a worldwide org.

* Volunteer to be a guest speaker at a community college.

* Your local Chamber of Commerce has an events calendar or newsletter.

* Local Business Journals.  In Seattle, we have the PSBJ with an events calendar.

* Technology Associations. In Washington, we have the WTIA with an events calendar.

* Industry Associations. Like the Association for Software Testing. You can volunteer to be a facilitator or help with the website, or the yearly conference.

* Colleges and tech schools. Volunteer to be on their industry (“real world experienced professional”) curriculum advisory board.

I’ll think of more and post them here.

Comment to add your ideas, too.

Or, do one of these above and tell me how it went.

Questions from the future

I did a guest lecture today at University of Washington’s Bothell campus.

It was for CSS 490 (“Software Testing”), taught by a colleague of mine named David Socha.

He handed out 3 x 5 cards to the students and asked them to come up with questions for me about testing.

In the interest of giving all of you fellow software professionals a glimpse into the mind of our future workforce, here is what they asked:

* I’m looking for a career in the gaming industry as a game programmer. I know software testing can help me as a game programmer but I want to learn more. Where do I start?

* Is it possible to work both as a tester and a developer?

* What certifications are industry standards?

* How do I get started as a tester, and also more interview questions / techniques?

* How much do testers make in comparison to devs?

* Is there a different approach to take when testing critical systems?

* What’s it really like to be a tester?

* Where do you get started?

* Can you tell us any interesting stories?

* What is the salary range for entry level, 5 years, 10 years?

* What are the working hours?

* Is the software testing job secure and stable?

* What is the major challenge?

* How do you know you’re a tester, not a developer?

* How much time a day does a tester spend documenting, coding, and testing?

* What are some testing career paths?

* What are the popular testing tools?

* During an interview how is a tester tested?

* What are the internship options around here?

* How do I get a tester job at entry level with no experience?

* What role does the PM have in testing?

* Is it a very stressful job?

* Can you give us some interview tips?

* What one thing can a dev do in coding to make things easier on a tester?

* Why should I be an SDET over an STE?

* What is the growth path for a tester at your company?

* What is the difference between a tester and an SDET?

* How do I write code in a way that is testable?

* How do I test my own code?

* How do I work with testers efficiently and in a friendly way to keep a positive relationship?

* What should I know to be a successful tester?

* How do you define a successful tester?

* What other college courses can help me become a tester?

* What’s it like if you have to work as a tester for a defense contractor in terms of ethics?

* Do testers work longer hours compared to other team members?

* Does paired testing result in better tests than individual testing?

* What’s a good answer to the classic “How would you test a soda machine?”

My next-to-last favorite:

* As a PM, how do I learn to like testers?

And my favorite… :

* Is testing depressing?

These questions would make Utest proud given their skill in asking questions for their “Testing the Limits” series.  In fact, I mentioned them today as an answer to “How do I get started with no experience?”  [ David Socha (the instructor) also mentioned mifos.org as a good way to build skill by volunteering. ]

Anyway, I’m sure we can build a whole conference around answering these, and I plan to do them service next time I’m asked to guest lecture (on Wednesday, actually). If you want to drop a dime on some of these, feel free to comment below and I’ll say to them: “This is what my colleagues had to say…”

Class, class, and class and STARWest

Just back from STARWest in San Diego.

The hotel was great and so were the attendees I ran into. Well, it was easier to run into some mainly because James was in fine form drawing a mob around his tester games in the main walkway.

Class was in session, even when it wasn’t. To me, that’s the mark of a good conference.

I had emerged from a session to find about 30 people crowded around him.  He was like a chess master, playing his dice game with 3 people at once.  He always carries three bags of about 30 dice each with him wherever he goes, and he seemed to be using every one of the dice in those bags.

Knowing the operating premise of the game, I decided to help him out.

He looked over and saw me, and told me he was glad to see me and could use my help because he had to go meet someone.  I’ve never had to follow James after he finishes a talk, but this was as close as it got — I inherited his crowd and did my best to keep the momentum.

He got back a few minutes later, glad to see the party was still happening.  But he noticed that the bags of dice were all laid out on the table — all 100 or so of them.  He seemed annoyed.

“Hey, man! My dice are all mixed up!” he said.

I had no idea that the dice had an organization to them. I felt bad, but I told him there was no way for me to have known that.

Still, this was not an impossible problem to solve. The “dice game” is about recognizing a pattern in  James’ head.  You do this by rolling dice.  After each time you roll, he says a number.  You have to figure out why he’s saying what he’s saying. It’s fast feedback from testing, and you have to form conjectures just as fast — then you roll the dice to either confirm or refute your conjectures.  You win when you can describe the operating pattern to a high degree of certainty.

Welcome to testing. Fast, fun, and authentic skill-building.

But back to James’ annoyance.  I replied, “ok, then, don’t tell me how they were organized in the bags.  Let me figure it out with you giving me feedback as I do it.”

He seemed to lighten with the perspective of that challenge.  But before we could make this into a game, he said “Each bag uses the principle of requisite variety.”

I knew what James meant by that. It’s one of the many terms to describe tests.  In this context, it meant the bags were equivalently and sufficiently diverse.

The first thing I wanted to do was  make sure the crowd knew this was spontaneous.  I wanted them to know this was something new between James and I, so they could pitch in to help if they wanted. Like everyone else at conferences, he and I follow threads of ideas that pique our interest. I had no idea what was going to happen, but I knew it would be fun, interesting, and meaningful somehow, and I hoped the crowd would play along as James tested me.

So I took all the dice in one big (laid-out) pile and scanned for affinity. It quickly emerged that there are several ways to make affinities. The ISTQB folks want you call these “equivalence classes”, and that’s fine, but they don’t tell you what to do when you suddenly realize that many tests might belong to more than one equivalence class.

For example, a red translucent die with black pips could go in 5 categories: red dice, black pipped dice, lightly opaque dice, dice that were identical to it, and approximate size to other dice like it.

My aim was to quickly take stock of the primary dimensions that stood out to me, then group them by those properties. There was background color, size, shape, pip color, pip type (dots, numerals, or symbols), opacity, albedo, elasticity, number of dice that were identical, and weight — and many fit in more than one category as I sorted them, so the notion of “equivalence partitioning” was difficult.

Good thing I remembered the context.  These dice are for games. The point is to have three bags that are equally diverse such that the odds are greater of having a similar experience no matter what bag James reached for. If one bag had too many of one kind, or not enough of a different kind, that may stall the exercise or the lesson he wanted to teach.

So I grouped mostly by “similarity to each other.”  I grouped the white dice together, the red translucents, the small standard blues, the more-than-six sided, the “few huge” (relative to most of the others), the ones with numerals instead of pips.

Then someone noticed that in the red dice pile, some had black pips and some white.

I took the suggestion to separate those into two piles.

In the white dice pile, someone noticed a few felt like they could be “eraser” dice — they had a rubbery consistency to them — which brought another dimension to dice: “the tendency of the pips to wear off with heavy use.”

I separated those.

Then I just did a straight count of each affinity and divided by 3.  If it was not perfectly divisible, someone suggested I make a separate pile — a kind of Holding Pattern /  Issues List pile to check with James about his preference for which bag they were most appropriate for.

The exercise took about 5 minutes, and with James as my “onsite product owner”, the mission was done when he grabbed the last 5 “issues list” dice and threw them into two bags, as if to say “good enough” (translation: further sorting into deeper affinities would be a waste of time and resources).

Too cool. Mission accomplished with a potential blog idea (mission accomplished there, too).

That was my best class that day, and a classy way to have an impromptu experience about class.