Thursday, December 18, 2014

Blogging for your Career

It may not seem obvious to the casual observer but one of the major ways the testing community disseminates information is through blogs. When practitioners want to find help or stay informed of the latest on goings, reflect on events, the medium-of-choice are blogs. We are able to disseminate and discuss things online in an open space for anyone to consume and criticize. A blog can also serve as a public identity; proof you exist. It signals to others in the community that you feel discussion and sharing is important. It could also signal to potential employers you have depth and experience dealing with issues they may consider to be important.

My current employer contacted me because the CTO saw me write about a topic they had a need for. I consider software testing to be an important role in the world of software development so I write about it. To them that was important or at the very least a differentiator outside of my resume or LinkedIn profile.

I believe modern software professionals must shape their own identity or else it will be shaped for you. There may be times its smart to keep your identity small but not with your career.

At the very least a blog is a starting point. I can’t tell you how many people have used my blog as a first time / conversation starter for gauging my interest in a job, product, or service offered for the industry. Don’t get me wrong I think writing is hard and requires practice but it can lead to all kinds of interesting connections if you use it right.

Thursday, September 25, 2014

Deliberate practice of writing

Writing is hard.

I'm always coming up with concepts of things to write about but hardly ever do I find the time (and/or desire) to sit down and flesh out those ideas. Some ideas are really strong, or well timed and they eventually make it but most linger as notes in Evernote / a Moleskin / Word / or even as a scribble on some papers and are discarded later. Knowing a life-long period of deliberate effort is necessary to improve performance (skills) in a specific area I’m deliberately trying to practice writing.

Committing to deliberate practice is hard and but the follow-through can be even harder. In order to commit I’ve created a daily goal of writing 1,000 words. I might get to it a few times per week at most but I hope at some point I’ll get over the hump where the ideas and words start flowing and things start to make sense. Whether or not I publish what I write doesn’t matter at this point.

I often start with some scratch notes or ideas from something I read, those become an incoherent story until I start moving the pieces around, filling in areas and eventually (hopefully) it turns into a pretty decent story. Most of the time anyways. Tools are abundant but don’t much matter until I know where I’m going to, if at all, publish and formatting comes into play. Minimalist writing tools like Ulysses seem to be my preferred platform at this point.

I think writing has intrinsic value. If you publish your writing it might one day have extrinsic value and help you build a readership, brand, or help someone else. When I need help I look to those who’ve published and when I can I acknowledge their work. Yet as much as I like helping others, my priority and joy in writing is in clarifying and distilling my thoughts and practices.

I greatly respect people who write well and whom take a first principles approach to their work. That’s an even more difficult goal - once you’ve begun to write well, can you analyze the subjects of your writing through the contrarian lens of thinking for yourself? Writing is hard but I will push forth and try to write for myself and hopefully be able to share some of that writing in the future. Who knows, maybe someone else will find some value in it as well?

Saturday, August 30, 2014

Please sign the Petition to Stop ISO 29119

I signed the Petition to Stop ISO 29119 and I think so should you too. Here's how you sign this petition: http://www.ipetitions.com/petition/stop29119

I don't typically get involved in overly political movements, typically because I don't feel I have enough information to make an educated or defensible position. I think software engineering standards (including ISO 29119) are one of those overly political movements that aren't designed to benefit the majority of the community nor do they have practitioners in mind.

There are a few reasons why I'm worried about this standard:

  • Closed standards seem to be anti-thesis of the modern software age where open-source standards, software and collaboration are the keys to success. Plus it makes the organization seem a bit shady. 
  • It's anti-agility. Burdensome test processes, documentation, etc. over the skills and experience of the people applying them directly reject the philosophy of the Agile Manifesto
  • There are legitimate disagreements within the software testing community on fundamental things such as terminology, let alone basic processes. In the last 15+ years as an industry we've started to develop a path towards understanding these disagreements but I highly doubt this "standard" has solved or even attempted to understand and settle those differences. 
James Bach says "[a] standard for testing would have to reflect the values and practices of the world community of testers. Yet, the concerns of the Context-Driven School of thought, which has been in development for at least 15 years have been ignored and our values shredded by this so-called standard and the process used to create it. They have done this by excluding us." (ref 1) (emphasis is my own)
  • As Cem Kaner said "Standards are political documents and sometimes legal ones. The existence of a standard makes it easier for a court (or a regulator) to rule that the standard-approved approach is the professionally correct one, and the non-approved approaches (or the ones that conflict with the approved one) are professionally incorrect and therefore improper. The imposition of a standard that imposes practices and views on a community that would not otherwise agree to them, is a political power play." (ref 2) (emphasis is my own)
In the end I'm not sure how much effect signing this petition will have on it's outcome, impact or acceptance but I am concerned enough to make a stance. I would rather say I protested it than accept it in silence.

I signed the Petition to Stop ISO 29119 and I think so should you too.  Go to iPetitions to sign.

References:
  1. James Bach's post
  2. Cem Kaner's post via Context Driven Testing

Friday, August 29, 2014

Macbook Pro Flaire - Scuba Decals

You might have seen the MacBook Air commercial, I sure did, affectionately called the “Stickers” commercial in which a MacBook is shown with all kinds of fun, creative decals people have put on their laptops.

If you haven’t seen it, take a look:



The decal flashed by very quickly but I spotted it. Scuba Divers! A quick Google search and there they are on Etsy. Here's what they look like on my MBP:


Technology should be fun after all!

Tuesday, May 27, 2014

TDD and Software Testers

I've been following along with the series of conversations with Martin Fowler, Kent Beck and David Heinemeier Hansson (DHH) entitled Is TDD Dead. The whole conversation about what's good, bad and ugly with test driven development (TDD) is interesting in my role as a software tester and from an overall system / quality perspective. What works, what doesn't? What do some programmers like about it and what do others fear? Does TDD translate into a better product? Etc.

According to Fowler's website, part 3 of the series covers
...the various ways in which we get feedback while programming and the role of QA in providing feedback to developers.
The whole series is worth a watch but if you are just interested in TDD and the role it plays when you have software testers (or QA), watch it here:


The three people involved with it have have varying experiences with Fowler having worked for many years with software testers in enterprise software, Beck now working at Facebook where they have few testers (and his own experience with dysfunctional QA) and DHH's experience running Basecamp. It's an interesting and relevant discussion because it's coming from a programmers point of view (programmer testing).  My view says testing is an investigation designed to reveal information about a product. Beck frames it as feedback that builds confidence in the code. I think both views of the software are valuable and those differences in techniques and approaches yield very different ways of viewing quality.

The title "TDD is dead" reminds me of the saying "Test is dead". Neither of those titles are accurate (they are catchy) but understanding the differences in views can help us when talking to stakeholders who have similar feelings or views.