The twist on the experiment

Preface

Having resurrected this blog for the purpose of helping find myself a job (again), some things are going to be different.

The principle thing is a switch in focus, less on the technical and more on the people side, corresponding with how my career has evolved over the past decade. I probably will still dig into some technical topics, both out of interest and because it's easier to find opportunities to solve technical problems in the wilds of the internet, but it's important I also demonstrate, as best as I am able, that I have some understanding of organizational dynamics and human issues.

The secondary thing that's different is nearly a consequence of the first thing. In short, I will try to use this space to promote the efforts of those less well-represented in tech than myself. I will still surely include some of my own opinions, but my experience is that my opinion is much less likely to provide unique value than that of, say, a black woman.

Compared to the last 5-7 years, where in general I've sought to avoid injecting myself into discussions, I am going to use this space to highlight and discuss relevant events. Again, where I can I will populate those discussions by including quotes from and links to others thoughts on the subjects, but when I believe I can provide value by collating and commenting on these subjects, I will.

I will be writing about:

People - Process - Product

When I was working on my resume recently, I shrunk it down about 75%, and I wanted a pithy way to convey where my priorities were at this point. Both to put it out into the world, as an expression of what I was looking for, but also because it represented a clear shift in how I approached "work" over the past decade. While process has always been a significant part of the work I do in the tech world, it's generally been in service of the delivery of a particular product. Yes, I spent plenty of time optimizing processes for people, but that wasn't where the focus was. So a big part of resurrecting this blog is also about representing that shift to a focus on people.

People

Writing about people here is likely to be the most difficult, in some ways. I don't think there's a bug tracker for people problems, where I could just volunteer to try to help them, then write about it. But one of the ways that I think I can incorporate writing about people into my efforts here is through the relatively introspective manner that I tend to approach problems. That is, through documented analysis of my own process and behaviour in approaching problems, I can demonstrate at least some personal understanding of the dynamics involved.

Besides that, I will write about patterns and individual instances of workplace people problems that I encounter, primarily on Twitter. I will do my best to gather evidence demonstrating the harms that are occurring, and highlighting opportunities to mitigate those harms. I expect to lean heavily on the work of others here, and if I allow the focus of this type of writing to be on me, please call me out on it. That said, I will incorporate examples and stories from my own experience, as appropriate.

Process

Writing about process is something I generally enjoy, and while I'm used to doing that in a professional setting where I have long-term plans for the processes in question, I don't think I'll have a problem finding many, many relevant opportunities when writing about people or products.

Product

While definitely the lesser focus overall in how I'm approaching work, I will demonstrate delivery of high quality products throughout here. Both in the written work, and any accompanying projects, completeness and correctness will be held to a high standard. 

Enhancing Google Keep

To that end, my first project here is going to be building an opinionated task management tool on top of Google Keep. It will allow me to write about many of the topics relevant to the kind of work I'm seeking, while also scratching a very old itch for me. :)

The Automator's Manifesto, Part Two

This was written quite a while ago, but I never got around to publishing it. So here you go!

Proactive Transparency

One of the most important things any automator can do is provide confidence to stakeholders in the project. Confidence can only develop if stakeholders understand the project, and see meaningful improvement. As such, it behooves the automator to make it easy to understand the state of the project. This is particularly relevant when it comes to actual test results, as even successful results that have no audience are essentially useless.

The term I came up with for this aspect of an automators role is "proactive transparency", based on the idea that it's not enough to simply run tests and call it a day. It's a good start, but publishing the results of those tests in a way so as to maximize their audience is where real value starts to develop.

Entropy Factors

The most challenging automation task of my career came at Research in Motion, where I put together a device lab to test over the air OS software updates (RIM was actually the first to have this available, as I understand). This was a hugely complex endeavour, covering a range of devices with different capabilities, moving between OS versions that could vary greatly. But even more significant to our testing were the externalities we were dependent on.

For instance, knowing what builds were available for updating required manual scraping of a development version of an application maintained by a different team, with no formal connection. This application, in turn, was loosely connected to the servers which devices would contact to identify what updates might apply to them. We frequently encountered issues where a test was queued, but when the device navigated to the update screen, the desired build wasn't found.

These, and many others, came to be known as our "entropy factors". I'm probably misusing entropy, but here the phrase means things outside of your control that could impact the results of your tests. Understanding what these are for a given automation project is one of the most important planning exercises you can do.


Measuring Everything

At my first GTAC, Patrick Copeland said "measure everything" (he probably said "at Google we measure everything", but that wasn't what I wrote down.) This was an inspiring credo for a then new-to-the-field automator, and I spent many years trying to live up to it. But it's wrong, or at least deceptive.

Assuming you have the resources to make it possible, measuring everything is still going to require implementation time. But what is much more important is that it is going to increase the scale of measuring output, while doing nothing to identify which metrics mean success. It might feel great to have every system metric, API call, user session and what-have-you carefully collected, but it does nothing on it's own to make your project better. That's an oversimplification, as having this all can increase stakeholder confidence initially, but after a couple of scares, that will fade.

You need to commit to measurements that correspond to your desired outcomes for the automation project. That doesn't mean you shouldn't collect a ton of other metrics if your tooling can do it for free, but you shouldn't surface them by default. Keep clear what you are measuring and why, and add cases to that as you grow.

Renewing the Experiment

 I started this blog about a decade ago to help me find work.

Once I found work, it began to atrophy rather quickly.

Now, I need to find work again. :)

So here's a placeholder, saying that this blog is coming back to life. I've got a handful of unpublished drafts from the past several years that I may polish and publish, and I'll write about my job search otherwise.