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. 

Sunday, April 13, 2014

Life as a Remote Worker

My "life as a remote worker" has just begun. A few weeks ago, the company I work for decided it was time for my small team to let go of its office and work remotely on a full-time basis. To prepare for this change and gain a better understanding of the intricacies of remote work I've decided to do some research. My first reference was the book Remote: Office Not Required by Jason Fried and David Heinemeier Hansson of Basecamp (formerly 37Signals).

There’s been some debate over the tradeoffs of remote work, sparked by Yahoo’s decision to end remote work so “speed and quality aren’t sacrificed.” My experience was limited to the occasional stint working from home or working during business travel. I saw the advantages of sitting next to my developers, over-hearing potentially interesting and useful information. Prior to reading Remote, my position was similar to Yahoo’s – speed and quality must be sacrificed. I suppose that’s why I needed to do research; I was only seeing things from one side.