Sunday, August 7, 2016

Thinking of Microskills

There was a post I read on testers needing to obviously learn to code. I still think reading code and pairing on writing code that needs to be created a viable options, and will lead to the accidental learning to code too. Being a tester amongst 20 programmers, the obviousness of me needing to code isn't quite so obvious. It's obvious I need to be able to work with my lovely programmers effectively. Having any specific skill isn't going to hurt me. But when I'm missing several skills, I don't find it *obvious* that programming would be the first. I've written about this a lot before.

The post did something really nice though. It dropped out from talking about programming as if it was a general one thing only, and listed a good number of ideas of tasks that would be programming. Tasks that most testers might have done or been part of doing.

Reading about the tasks triggered me to go back to a note I wrote for myself a few days earlier, while pairing with a developer on cleaning up some test automation code. We really need to drill down in our communication.

Instead of saying programming, we need to talk about specific tasks requiring programming. Instead of talking about the skill of programming, we need to drill down to specific skills that would enable us to perform those tasks. In the world of team work, we have the option of getting comfortable with paired work and leveraging the "friends with pickup trucks", a metaphor for James Bach on knowing when you don't need a resource/skill on your own, as long as you have a friend you can rely on.

In drilling down to the skills, it's not just skills related to a task. We would benefit from microskills, things that are little but taking us towards something bigger.

An example of a microskill I was thinking while pairing was the skill of being comfortable driving through code. Knowing the CTRL+click to go into a class, or finding usages to go up in the call hierarchy.

For established programmers, all this is coming as obvious. For people new to programming, every small thing is a step forward in the learning.

We should celebrate learning microskills. Acknowledging their existence and giving them credit would make learning many things more approachable. Belittling those drives people away from this path.

Testing too has a lot of task types, skills areas and microskills. Many of those catch to new people when mobbing. Acknowledging them more actively by naming feels necessary.


  1. That's an interesting idea, I think I should process it a bit to how does it fit in my world.
    My first reaction, though, is "I think it will do more harm than good".
    Most of the time, when I see someone stating "I don't program", I suspect I'm actually hearing "I'm afraid of code". It is not always the case (though, when I encountered counter-examples, they ended up by "oh, and I did pick up some programming skills on the way, I just didn't develop them to be able to write production code").Since code is what we deal with, having in mind "I don't do that" is excluding a large part of the things that needs doing, since there's a lot that is code-related, and even for those that "read code", some of the more magicky parts of programming will be deterring. Furthermore, if I'm presenting myself as a non-programmer, I will get a lot of "you won't understand this part" (which will be true in about a third of the cases), while if I present myself as "I program, just not as good as you", it is far easier to respond with "show me anyway, I might learn a new thing", since programming is in the domain of "what I am known to be doing"

    1. In my experience, if you add to that equation my gender and present as a programmer, you get challenged a lot. And that is not a pleasant experience. Being a non-programmer who programs gets still all the explanations but in my experience, less of the attitude I have difficulties dealing with.

    2. huh, I didn't consider that.
      What does it mean "non-programmer who programs"?

    3. Over the years, I've identified as non-programmer. I counted for my learning programming through osmosis talk that I've programmed in 13 languages. Identity and choices of where you spend your time can be very distinct of abilities/experiences.

    4. I think I understood you now, and this is very much where I was aiming - there's a world of difference between stating "I'm a tester, and I can program (even if not as good as the developer)" and "I'm a tester and I don't program, I just can read code \ write simple scripts".
      It would seem to me that the first one yields better results in terms of attitude and getting the information I want\need. So while having those micro-skills is indeed a nice way of looking at it, I think that it is more useful to claim one posses the macro-skill even if they actually posses only a few of the relevant micro-skils

  2. Love this post! Wish your QA/dev ratio were more reasonable. How is your interaction with BAs?

    1. Personally, I don't think there's much wrong with the ratio. The devs automate and test a lot. We don't have BAs as such, but we have real users around. And they are great to pair with. :)

  3. Yesterday a senior developer from my team told me that I am a full stack tester/developer, and he told it something like this: "Some people call them self's full stack developers, they do not know what they are talking about. Look at what Dragan is doing, he is finding bugs and then by reading our code he points us to origin of problem, sometimes he even fixes some of it, automates tasks, sets CIs, CDs, environments for testing and production, writes documentation and tests all the way, he raises scale on what you mean when you say full stack." Makes me really proud to contribute to my team in so many ways. Being a tester does not mean that you should be limited by your role. I like to say that I`m non-programmer who`s programming and not coding. And, yes, we need to develop microskills that could help us to help our team.