In these posts I worked through my own experiences with my behavior on a software team. These posts also came from my processing on some of the books I was reading at the time. My bookshelf for these posts includes:
The No Asshole Rule, by Bob Sutton
The Sociopath Next Door, by Martha Stout
Crucial Conversations by Kerry Patterson
Good Boss, Bad Boss also by Bob Sutton
Artful Making by Rob Austin and Lee Devin
After all of the reading, all of the testing, lots of asshole screw-ups of my own and dealing with some people in my life who are pretty big assholes in general, I’ve drawn some conclusions: Testers are automatically placed in the most socially awkward position on any software team which means we need more social skills and awareness than anyone else. We need more emotional fluency. We are not assholes and because of the work we do, we must learn how to minimize our asshole behavior as much as possible. As I’ve been reading and learning about this, I’ve found enough compelling information that I decided to put it into the hands of testers by giving a talk at this year’s Pacific Northwest Software Quality Conference (PNSQC).
The talk is meant as a means of self-reflection just as the examination of this topic has been an exercise in self-reflection for me. I’m hoping that people who come to my talk walk away with more questions than answers. I hope it gets people thinking about how they act with others on their team. There is so much in testing that we have absolutely no control over. My hope for this talk is that it gives people enough information to work on controlling the things we can control.
Since I’m not a psychologist, I teamed up with my friend, Gordon Shippey, who is a licensed counselor, to write the paper. We didn’t feel comfortable calling the talk, “Are you a testing asshole?” so we settled on, “Hard Lessons about Soft Skills — Understanding the Psyche of the Software Tester.”
I’ll be talking about:
Asshole behavior in the context of testing
Crucial Conversations
Recovery and Repair
Testing in a Safe Environment
The paper Gordon and I wrote in conjunction with the talk is intended as a resource for times of testing distress when testers feel they’ve backed themselves into a corner or find themselves handling situations in ways that don’t make them proud.
Another conclusion that I’ve drawn in all of this is that anyone can be an asshole when put in the right situation. Personally, I now have enough confidence to know that 95% of the time, I’m not one of them. This realization has made all of the effort and hard work I’ve put into this paper and talk worth the time spent. I hope others find it useful as well.
Unless you write a blog, there’s no way to understand how random the different aspects of it can be. Within the blogosphere, random takes the form of:
* Bloggers who inspire me and keep me blogging
* Who the comments come from, what they say and when they show up
* The different places I go while writing posts
* The posts that show up in front of the public and the posts that don’t
Recently Justin Wehr, a blogger I’ve followed, like for years, posted on his blog writing habits. I’ve also been talking to a few people who are interested in starting their own blogs. This post of mine copies the format of his post with my answers. Justin: this post is for you. Blog on.
Why I got into it
The reason I started blogging was because I was going through a Masters of Software Engineering program and wanted to have something I could easily show others when I finished.
Why I stay(ed) in it
I found that it helped me think through my schoolwork and that I enjoy writing more than I ever understood. I’ve always had a journal in one form or another. In fact, several years worth of entries exist on the 286 pc clone running Norton commander that I think might still be in my mom’s basement.
My blog has been a metamorphosis for my personal and professional life. It’s taken me around the world. It’s introduced me to some very good friends I otherwise would never have met. It’s kept me connected during some dark times and has continued to help me process the world around me. I process my life through writing, some of which makes it onto this blog.
What *is* blogging for me?
Blogging is the most purely selfish habit I have. Whenever I sit down to write a post, the priority is always on me and what I want to say. There are no ads. There is no genuflecting. I have never written a post because someone asked me to or taken money for anything that has shown up on this blog.
Although my content was pretty narrowly focused in the beginning towards school projects, it’s turned into quite a mixed bag. Anyone remember the Kangaroo post? What about the Desert post? Then there’s the dumpster post. (We’ll just leave the “Twilight” post in the ether, shall we?)
How hard is it to keep chugging?
For most of my blogging life, I’ve never, ever had a problem coming up with posts. There was only one period in time when I worried that my blog was withering and the fact that I wasn’t writing freely was a very strong smell of things going on in my life.
Do I read and/or revise old posts?
There is always a small mistake or two that I miss in a post. There are very few posts where I haven’t hit publish then looked at the post and thought (oh shit…edit! Edit now!) Although, to be fair, the edits are always quite small. I do, on occasion, read my old posts. My thinking is circular and I enjoy looking at how my opinions change over time.
What keeps me from sucking?
There are a few guidelines I have for myself.
Be kind to myself. Since the blog is by me, for me, I practice self-love. There is no reason why I should ever not be nice and overly forgiving to myself on my blog. This includes comments. I’ve been lucky to only ever have a couple of comments that I just wouldn’t post. (Protip: RTFM has no place here.)
Posts shouldn’t be a reaction to someone else’s negative energy or merely a regurgitation. The blog is mine so it should be as 100% me as possible. The posts I write shouldn’t be posts that anyone else would or could write. This post is a notable exception, but I think that’s in the best possible way.
Be patient. There are posts that sit in my backlog for months before I finish them. Some of my best posts including the last post on continuous deployment might sit for a while. Sometimes this is because I’m feeling cranky about something and it comes out in a bad way. Sometimes it’s because of, well…life. I’ve found that the good ideas for posts have a certain timelessness so it’s ok if I have to put it down for a few weeks or even months.
Capture the ideas as soon as possible. I know to keep some paper in the bathroom for ideas I have in the shower. I have evernote on my phone. I’ve got religion about it. If an idea comes, I write it down somewhere.
What do I think other people think of this blog?
Umm…I don’t freaking care. I just don’t.
Where do the ideas come from?
I love Justin’s answer to this question, so I’m reprinting it here:
“All over the place.
All over the damn place.
Not uncommonly: Books, blogs, field observations, porch ruminations, pesky bedtime thoughts, car rides, and conversations.”
How do I decide what’s post-worthy?
The content has to be interesting for me and usually relates to a problem I’m thinking through or a challenge I’ve faced. Sometimes I blog about trips that I take or conferences I’ll be attending.
Where: Currently, on a $50 goodwill sleeper/sofa in a one bedroom apartment located in Mountain View, California. There is usually a dog or a man also sitting on the sofa.
When: Usually either early on Saturday morning or late at night (note…it’s 10:54 on Thursday night and I have to be working at 6:00am)
How long does it take, typically?
It’s so dependent on the post. Some are eked out over lengthy periods of time and some come in a great whoosh.
What’s my 5 year plan? What are my aspirations for this mofo?
Uh…who knows.
A phrase I hear a lot around Mozilla is “continuous deployment.” I hear there’s this product Mozilla makes that’s competing with some other product that has rapid release cycles. So, yeah, we’re working on continuous deployment.
I’ve noticed that a main resource around our office for information about continuous deployment is this video from Etsy. Hearing, “We’re moving to continuous deployment,” is nothing new for me. This is the 2nd job I’ve had where it’s been a major focus. Since I’ve heard of the Flickr version, I decided to watch this Etsy video.
Picture yourself at your computer about to hit the big button and deploy a feature you’ve been working on. You are fairly confident that nothing catastrophic will happen, but you don’t know. (I’m writing this from a dev perspective, but even if you’re a tester…come on…you never know, even if you’ve tested the hell out of something). In the talk, this is what is referred to frequently as, “the fear.” It’s actually referred to as either, “THE FEAR” or “the fear.”
“Fear for startups is the biggest no-no.”
“Fear is what keeps you from deleting your database.”
“Fear doesn’t go with creative work.”
This rings true for me because I frequently deploy selenium tests for addons.mozilla.org. My teammates and I have talked about “THE FEAR.” We have strategies for coping with it such as holding one’s breath, saying a prayer or running the 90+ tests one more time. When Etsy talks about “The Fear” I know exactly what they mean.
Etsy’s video fascinates me because of how they have conquered “The Fear.” It’s been on my mind every day since I watched the video. What’s the special-continuous-deployment-sekrit-sauce-that-makes-everything-all-better?
Etsy combats “the fear” with visibility. You see, at Etsy, EVERYTHING IS GRAPHED ALL THE TIME.
Here are some of the things they mentioned graphing in the video:
How many visitors are using this thing?
Can we deploy that to 100%?
Did we make it faster?
Did I just break something?
How long is it taking to generate a page?
How many users are logged in?
How is the bandwidth?
What’s the database load?
What’s the requests per second?
If you look at the graphs, they are simple bar or line graphs. They are not exceptionally fancy but they are numerous and the maintenance admittedly takes work. They are not, however maintained by specialists working in a silo. The graphs are created by an engineer. Here are some numbers:
20,000 lines/second is their log traffic, at times
16,000 is the number of “metrics” they have organized through dashboards
25 engineers committing code to dashboards
20 dashboards
I doubt that when Etsy decided to start graphing everything they woke up one day with 25 dashboards. It sounded very much like they put the tools in the developers hands and lovingly nudged them along.
This is a serious commitment to data.
Data doesn’t just happen. It takes a persistent effort to include log messages in your code. It takes servers and databases capable of handling the traffic created by the log messages and staff to maintain them. It takes investing in huge monitors all around the office and giving people the bandwidth to figure out how to work with the data & graphics stack. Most importantly, it takes trust so that employees are allowed to see the data without making them jump through hoops.
So how can a team move closer to the graphing part of continuous deployment?
According to Etsy:
Give people access to production data — without making them wait months for a special password or even log in every time.
Make the data real time instead of daily. When I say access, I mean feeds. This goes well beyond a spreadsheet.
Create copious amounts of log messages. If someone clicks a link, goes full screen or downloads something…log it.
once you have the data, make graphs for features before you release them
I love data, but will be the first to admit that it is not pretty. The plain truth about data is that it takes patience because combing through and refining it can be tedious, monotonous work. It is very easy to buy a bunch of monitors and put them on a wall showing an inst-o-matic graph that came with your bug tracker (I’ve seen this done. O hai, expensive wallpaper!). It takes more time to ask deeper, meaningful questions. It takes even more time to filter the data into something graph-able. After that, you have to find the right way to share it. Note, that even if you do all of this and the data successfully tells a story, you’ll have to spend time dealing with, “and why did you use those colors.” What was I saying? Oh yes, data is not pretty.
Now that I’m working every day with tests I visualized a couple of years ago, I’m continuing my quest for deeper questions about tests. In my context, the tests are the selenium tests I work with day in and day out, so besides coming to grips with “THE FEAR,” I’ve also been thinking about, “THE FAIL.” But wait! That’s another blog post.
If you want to read more about Etsy’s graphs and data, they have written their own post about it.
For running the AMO tests, it’s good to use our moz-grid-config repo to run selenium because it allows you to get around some issues like setting up a separate firefox profile for accepting certificates and it contains both the standalone version of selenium rc as well as what you’ll need to run selenium grid.
If you’d like to know more about how grid works, you can check out this page.
Once you’ve cloned the moz-grid-config repo using
git clone git@github.com:mozilla/moz-grid-config.git
You can try starting it up. There are 2 commands for this which will each need to be running in their own terminal window:
ant launch-hub
ant launch-remote-control -Drc.environment=”environment name”
The value from the -Drc.environment parameter comes from the grid_configurations.yaml file. If you have a look in the file, you’ll see options for other environments including Firefox 6 and the Aurora channel.
It’s also worth noting that the selenium jars are in the vendor directory.
Once you’ve got grid up and running, and forked the AMO test repository, you can run some AMO tests with this type of command line
py.test -n 5 –browser-name=”Firefox 5 on Mac OS X” -q test_search.py -k test_that_searching_with_substrings_returns_results
-n 5 is xdist telling py.test to run 5 instances at a time. Note that you need to have multiple terminals going with ant launch-remote on different ports to use this option. If you don’t specify a port number when you run “ant launch-remote” it will launch on 5555
–browser-name=”Firefox 5 on Mac OS X” is specified in the grid_configuration.yaml of moz-grid-config
-q test_search.py is telling py.test to run the file test_search.py
-k test_that_searching_with_substrings_returns_results
-k is a keyword parameter. In this example it’s used for a testname, but we could also specify -k substrings to run any tests with substring in the testname.
If you get stuck or if something isn’t working with your environment, feel free to stop by the testday irc channel: irc.mozilla.org #testday. (Note, I probably won’t be watching twitter as much today since I’ll be in the irc channel)
Next Friday will be my 2nd AMO Automation testday at Mozilla and the first one I’ve helped to organize. AMO stands for addons.mozilla.org and it’s the web-site for which I’ve been writing and reviewing automated checks (sometimes I call them tests, but I like referring to them as checks).
Grid by msmail
As part of the last test day, I ran a github workshop to help people figure out how to set up and work with github. Here’s a link to that blogpost.
For the upcoming testday, I’ll be running a workshop to help people who would like to run our addons selenium checks with our grid configuration. Although it’s easier, when starting out to write and execute tests using a standalone selenium jar, it’s good to understand how to run tests with selenium grid as well. All of the tests for AMO are run using grid, so this is the setup I use when I’m doing code review or writing checks.
This is the link to the github repo containing our grid configuration. I’ll be posting again next week with a few more instructions on how to modify the repo for running checks locally.
The testday starts at UTC/GMT 15:00:00 and continues throughout most of the day until 5:00pm Pacific time. (We’re global, baby!)
A few local times for the moz-grid-config workshop:
UTC/GMT: 17:00:00
Pacific: 10:00am
London: 6:00pm
Bucharest: 8:00pm
Bangalore: 10:30pm
By the way…if you’re in the UK and close to London, you should checkout the London Selenium User’s Meetup which is happening next week. (I hear these are frakking awesome) :)
Yesterday marked my 3 month anniversary at Mozilla. I’ve been soaking it all in. Currently my job consists of leading automation for addons.mozilla.org web-site. I write selenium tests and test infrastructure in python, code review tests and infrastructure written by other members in our community.
But that’s enough about me. This post is all about you.
My favorite aspect of working at Mozilla is that every test I write or review is part of a community ecosystem that supports Mozilla’s mission of “promoting openness, innovation and opportunity on the web.”
Openness
The codebase that I work with is completely open in this github repository. Anyone can download it, run the tests and play with them. Thanks to the nurturing of our 2 selenium core commiters, David Burns, The Automated Tester and Dave Hunt, our team is also code-review-infected. These code reviews are also completely open in the pull request section.
Innovation
Our team is fairly aggressive when it comes to trying new stuff. We are already talking about how to switch our tests over to Selenium 2 before the end of the year and I would be very surprised if mobile tests didn’t make an appearance in one form or another.
Opportunity
Because these tests are open, it’s an invitation to try something new with selenium that perhaps you wouldn’t get the chance to try otherwise. If you work primarily with selenium and java, this is your chance to see the python bindings for selenium in action. If you’ve ever wanted to see the difference between xpath and css or wondered what an architecture using page objects looks like, this is your chance.
Mozilla frequently holds test days for it’s different applications, and the automated tests for addons.mozilla.org are no exception. Our next testday will be August 19. These are an opportunity members to focus on writing some tests. For the last one I ran a github workshop and am already thinking about what type of workshop I will hold for the next testday.
I consider this a testing ecosystem, because while I can add tests myself, the real win is having contributors learn something or teach the rest of the community something with their code. The strength of the tests is gathered from the diversity of contributors. With so many smart and generous people working and learning from each other through these tests, we will show what can be done with browser-based testing as well as shed some light on its challenges and limitations.
These are your tests and they help to ensure that the open web works for you.
In my last post, I vented a little about logic and discovered something about myself. In addition to re-framing my relationship with testing, I need to re-frame my relationship with logic.
Sometimes when I say something that I think is true, I realize that it’s not all true. I like the scene in the classic movie, The Princess Bride when Billy Crystal’s character, tasked with resurrecting what appears to be a dead man on his table says, “There’s a difference between mostly dead and all dead. You see mostly dead is slightly alive.” In expressing my boredom in Puzzles class, I made some blanket assumptions about myself and logic. Is this relationship all dead or mostly dead? Actually, I don’t think it’s even mostly dead. It just needs a bit of an ambush makeover.
The reason why I don’t think my relationship with logic is as dead as I assumed is because there are classes where I’ve done work with logic and loved it.
Classes I enjoyed where logic was used:
Discrete math (I loved this class so much I never wanted it to end)
Artificial Intelligence
Formal Methods – In this class I learned how to connect requirements to the logic equations I learned in Discrete Math. It was brilliant!
6th Grade English (we diagrammed sentences…was fun!)
Classes where logic was really boring
Puzzles
Scientific Methodology aka “How We Know” class (“How We Know” was our textbook. My copy has mysteriously disappeared into the ether of time)
Intellectual History (I learned about dead nerds who were not men of action. One of them never left the bathtub. I suspect they were hipsters before their time.)
Hmm…there’s a fairly clear delineation here for me. Classes in the first category are science classes. Classes in the 2nd category are humanities classes.
But I love humanities!!! What happened?
I think I know. I like the clarity that comes from breaking down something complicated into different pieces and rebuilding something completely different with the same pieces. That’s useful for me. It can be very simple. I’m a great fan of DeMorgan’s law and it’s friends. There is no pretension here. There is no bullying or critique…just order being made out of small simple pieces. In the classes I loved, logic made me so happy!
If we skip to classes in the second category, logic turns into something entirely different. While I have a healthy respect for those how brought us logic and were killed or punished for it, there is still plenty of history that is dead dudes trying to one up each other with fancy 3 and 4 syllable words. There is nothing fun about decontextualizing a tautology by using inferences instead of deductions. (Don’t try to figure that out, it’s nonsense. I made it up). This view of logic means as much to me as the shade of lipstick being worn by the housewives in Orange County.
The reason I draw a parallel between some of the most revered scholars in history and the cattiest women I’ve ever seen in my life is because logic can be used poorly just as it can be used beautifully. I understand that the people I learned about in the classes I didn’t like were directly responsible for what I learned in the classes I did like. I guess that not enough attention was paid to the fact that it is easy to abuse logic. Logic can be used to argue someone into a corner for the purpose of making her feel horrible about her new brow lift. Logic can be used to send someone in circles and can be used to split someone’s hair extensions until her weave is ruined.
In this, I see that philosophers and testers have some of the same challenges. It’s easy to do too much and not know when to stop. I’d like to see how far Aristotle would go to isolate a bug. Logic is no good if the person using it doesn’t pair it with heart and an understanding of when to quit. I have a few critical thinking books in my library and both are very clear about how it can be misused. If I had time, I would keep writing. Unfortunately, for now, my draft for PNSQC calls.
I have more work to do with logic and testing, but this is shaking things loose for me. The walled garden I’ve been living in has become a safe place and is showing signs of new growth.
Before I was ever a tester or even in software or even cared about software, I was in Puzzles class. This was a class I took as part of the hippie-powered liberal arts program where I spent my first 2 years in college at Appalachian State University. Doesn’t it sound like a fun class?
Well…despite my best efforts, it bored the hell out of me. There are many testers for whom this class would have been a dream because it was all about logic puzzles, but I find philosophy and talking about logic absolutely, stultifyingly BOR-I.N.G. Even if I try to listen and do the whole “fake it ’til you make it” bit, my eyes glass over and it’s obvious fairly quickly that I just don’t care. At this point in my life, I know that philosophy will never turn me on and I own it. Don’t get me wrong, there’s gold to be had in philosphy for the field of testing. I won’t be discovering it. I have lots of respect for people such as Rick Scott and Zeger von Hese who can throw down with this and make something important and gorgeous out of it. (Go dudes!)
This means that I obviously didn’t learn that much in my puzzles class. In fact, there’s not much I even remember. I only have one memory from puzzles, but it’s come back into my life lately in a very bizarre way. It’s helping me format the paper I’m writing for PNSQC. Here goes:
The only thing I’ve remembered is the day that I showed up for class and our puzzles teacher told the class,”We’re going to destroy the world today.”
Apparently it’s possible to use philosophy to reason oneself into a logical position where the world cannot possibly exist. Of course, I have no memory of how this is done or what it involves. Philosophy leaves me too cold for that.
Anyway, the memory of my teacher’s words and his intentions, “let’s destroy the world,” have come back to me. I’ve found myself rolling down a dusty and, at times, lonely road in my personal journey of software testing. I have a ton of friends in this industry and I’m sure some of them will identify with what I’m talking about. It’s entirely possible to find yourself in a crowded room full of people you love and still feel totally alone. There are those of us in testing who live in this type of “walled garden” because we’ve burned through the ceiling of what a tester is allowed to be within our own ecosystem.
There are other types of fail showing up on the testing doorstep as well: Devs often fear or hate us, our value is questioned on lots of projects and nobody ever starts their software career wanting to be a tester. In fact, there are plenty of people who are in testing simply because it’s the only job they could get in software. (I’m not saying it’s right, but we all know it happens.)
As testers, we’ve become adept at assigning blame for this. Schools don’t teach enough testing, managers don’t understand how we bring value and devs just don’t give a shit. What I’ve noticed is that we never ever point the finger at ourselves. In my own testing journey I’ve come to a place where I’ve started ripping apart who I am as a tester and asking myself, the classic Dr. Phil question, “how’s that working for you?”
I’m now at the end of the road.
I am not a tester.
You heard me.
I AM NOT A TESTER.
and, in my world, neither are you… even if you’ve got 20 years under your belt, a fat paycheck and a bad attitude which you think makes you the greatest thing to smack the devs on the ass since the black turtleneck.
I am not a philosopher, but I’ve managed to destroy the world where I work<.
If we really want to evolve testing, if we really want to find something new it’s time to throw out the hubris and rip what we do down the studs, the bare earth, the beating heart if we’re ever to find answers to some of the hard questions that have dogged testing for years:
Why are we in testing?
Do we really care about the software? or do we only care about making ourselves look good on the software team?
Why is there such a love/hate relationship between devs and testers or even testers who write code and testers who don’t?
Why is it so easy for testers to feel ostracized on software projects?
Why do most testers not see themselves in testing in 5 years?
If you take away the tester, the dev and the software, what’s left? In “The Neverending Story” this is when there is only one small, solitary grain of sand left. I do think we’ve got a bit more than that. At the end of the day, all of we’ve really got is being human.
Let’s get to the bottom where the beating heart lies and start rebuilding on something more solid than a job nobody ever wanted until they “fell into it.” Let’s destroy the world.
In which the lady invites you to participate in a Github workshop on Tuesday, May 24th, 9:00a.m. PDT….world times here
My first month of working at Mozilla has slipped past without a sound on my blog. That’s because I’ve been making lots of noise over in my github space. One of the software skills no one will ever, EVER tell you to learn but a skill everyone in software should know is how to use distributed version control like a Boss. This post is an invitation to an online Github workshop I’m hosting next week and contains a few resources for those who can’t make it but would like to learn more.
I’m not a stranger to version control, but it’s always been something I approached timidly and with great care. Since my first task is re-writing a bunch of selenium checks for addons.mozilla.com, I had to come up to speed pretty quickly on Github. I’d been checking in bits of my own code prior to starting, but I had only ever worked with branches when I was pulling down code on subversion. Let’s just say I had to get it together pretty quickly.
Github is fabulous once you understand the bulk of it. It handles code reviews, has diffs and provides great visibility. Github makes it possible to collaborate with my co-worker, David Burns, who writes The Automated Tester blog and is based in England. If you poke around in my github you’ll see comments both of us have made in the repository for Addon Tests.
Now that I know how painful it can be to spin up on Github, I’d like to spare others some of this pain. To this end, I’ll be running a Github workshop during Mozilla WebQA Automation Test Day. The test day is next Tuesday at 9:00a.m. PDT (World Meeting Times Here). This will be my first Mozilla Test Day, so I’ll be learning what it’s about along with everyone else who shows up for the first time.
About the test day:
From what I understand, it’s an opportunity to collaborate with the team at Mozilla on some testing or, in this case, writing some selenium tests. You’ll need a little, but not tons of programming experience. All levels of experience at writing selenium tests are welcome. Please read David’s post about it here.
The IRC channel if you want to go straight into writing selenium tests is irc.mozilla.org #testday
About the workshop:
I’m expecting to spend from 1 to 2 hours on this. It starts at 9:00am-ish on the West Coast of the U.S. If you are in a different time zone, check this link. Everyone will work at their own pace so it should be very low stress. Prior to the workshop, I’ll put together an example project we can use for getting used to the whole distributed aspect of Github.
If you would like start before the workshop, check out the github instructions for installing and setting up git. I found them to be quite helpful for setting up on both mac and win7.
The IRC channel for the workshop will be irc.mozilla.org #expectpants
If I can get it sorted, I’ll post a transcript here after we’ve done the workshop.
Some Resources:
As I’ve been learning how to use github, I’ve been adding to my github cheat sheet. Making your own cheat sheet seems to be a “rite of passage” for github users and there is no shortage of these. I invite you to use mine, fork it or otherwise steal from it to write your own.
It’s very easy to work yourself into a corner in git. When this has happened, I’ve turned to the Pro Git book. It’s available in the ever-awesome Safari Online (these people brought back html view for me, I <3 them). I also got our manager to purchase a copy for our group. I’m relying on it less these days, but find that when I need it, I really frakking need it.
Besides these 2 places, I search on Stack Overflow.
If I can’t find answers in these places, I’m down to getting creative. Luckily, this hasn’t yet failed me. I am by no means an expert at Git and Github, but I’m ok with them. Let’s practice together :)
A black cloud has hung over my writing for the past year and it’s been frustrating. It has stretched far beyond writer’s block. You could say I’ve had some angst. Let’s chalk it up to “mysterious writing ailments.” There are many artists who do their best work in the dark, when they are messed up, depressed, down, and/or just plain crazy. Unfortunately, that’s not me. I credit this conference, organized by Chris McMahon, and the gorgeous Durango weather with breaking me out of my writing funk. So how did this happen?
Writing!!! There was lots and lots of writing!!! We had a few writing assignments. Chris started us off with memories of high school English. He asked us to write a 5 paragraph essay. This is an essay with an introductory paragraph, 3 main paragraphs and a concluding paragraph. After being programmed by sadistic English teachers in my American high school, I can write these in my sleep. It was a great illustration of how putting some artificial structure around ideas that have grown wild can reinforce and bring them together.
I took this opportunity to pair with Zeger von Hese on the back porch of the library. The picture above shows the view from where we were sitting.
Zeger writes the blog Test Side Story. His posts on Testing, Art and Philosophy have been a bright light during my dark writing period. Zeger has a degree in Cultural Studies which I consider part of the Interdisciplinary Studies family. (I have my own Interdisciplinary Studies degree in German Studies) Since Zeger lives in Belgium and I live in the U.S. this was a unique opportunity for us to physically sit down together with our ideas about art, observation and testing. I remember one particular moment when Zeger was doing some really deep thinking and was standing up. I was typing what he was saying just to capture the thought process, and in this one particular moment some big ideas came together for me. I don’t know where else this would have happened, and yes, Zeger and I have plans to share what we were talking about.
The 2nd writing exercise was to write a story with a beginning, a middle and an end. I immediately knew what I wanted to write and have a rough cut together. It’s inspired by an anecdote Trish Khoo shared with me. I was surprised at how quickly the story came together, actually. She wasn’t at the conference, but I’ve been talking with her about fleshing the story out a bit. That piece will also be showing up somewhere in a blog or maybe one of the testing magazines.
Besides writing, most of the attendees presented on a topic. My impression of these was that most of them were half-baked and brilliant. There are not enough places to work with half-baked but brilliant ideas in testing. I enjoyed every presentation and was happy to see the attendees embrace mine.
My own presentation was based on my “Are you a testing asshole” post. In the wake of that post, I’ve been researching into why I think testers are automatically at a disadvantage on most software teams. If you count my blog post as the first time I talked about this topic, WAT2 is my 2nd time discussing it. Every time I talk about it, I am more alarmed by the feedback I get. We’ve got a serious asshole problem in our community. This is a challenging, non-trivial problem, but not an impossible one. We need to learn ways to improve the way we talk with others and the way we argue when we disagree.
The Pacific Northwest Software Quality Conference agrees with me that our asshole problem needs some addressing. I submitted an abstract to them on this topic and it’s just been accepted. I’m gonna go listen to some Phoenix. See y’all in Portland.
