Asking What Would I Do Today?

As a new week started, I was thinking about things to do. I made a little list of changes I knew I would need to spend time on. There were quite a few, which made me think of individual choices I can make on "What would I do today?"

I've been spending a fair amount of time thinking about the fact that time is limited. There's so much to do, so much to learn and not choosing a focus means not making progress on any of them. Everyone has their individual choices of what and how they choose to do.

My Monday list included many choices of what I could do:

• Reflect what happened recently and learn from past
• Analyze the product, in particular business goals/progress and requirements against the product and ideas of where the product is evolving
• Prioritize the backlog with others
• Pairing on production code, or just reading it for ideas
• Working on Selenium tests, could add a few again
• Working on Unit tests, could do something there
• Exploring the application and the new features to find problems quickly
• Updating documentation
• Staying connected with my colleagues in office and outside
• Learning general applicable ideas about testing and software development
• Re-energizing by something

I could learn to be better at any of these tasks, improve my abilities. But I couldn't do all of it at once. 

This brought me back to thinking about short-term vs. long-term gains. Learning is like farming. You plant seeds and pay attention, and you  have lots to eat. On the other hand, we need to eat today and for that purpose hunting keeps us fed now. There's always a balance.

Balance of perspective (short vs. long term gain). Balance of types of tasks. And balance of where I am right now, and what I am able effectively do from that state of mind. 

I made my choices. And made sure my choices this week are different from my choices last week. 

Becoming a Keynote Speaker

There's a few things very close to my heart. Public speaking - delivering talks and training sessions is one of them. It's an area where I have gone well beoynd my comfort zone, transforming myself into something I was not before.

20 years ago, I was afraid of doing presentations. I went through high school optimizing my writing to be as good as it could be, but just bad enough so that the teachers would not make me read them out loud. When I wanted to be in the board of my student union, I almost passed out in front of the audience just for having to introduce myself. Things are now different. I practice a lot to improve. And the end result already now is worth looking at.

I dream big. I dream of having a story worthy of a TED stage. I dream of being a regular invited keynote in software and testing conferences to an extent I have to say no. I dream of being a professional speaker who gets paid to speak. And I work towards this dream.

The work that I do is manyfold. It includes

• being the best possible person in the projects where I work, contributing and learning. I want to be a great tester and a great software specialist, and work on that. I look for understanding to share through doing those things.  
• delivering talks on things I want to talk about and that I think would be of value for others
• studying what makes a great presenter, finding my own style to being great presenter as myself and practicing. 

I work with new presenters, learning from them as much as from anyone. I'm absolutely in support of the Speak Easy initiative, and I find that Speak Easy can also be a home of support for an aspiring keynote speaker.

To find more focus on my studies, I turned to a personal coach. She suggested that since the road I'm traveling is not just mine but there are other women aspiring to keynote eventually, we should set up a Mastermind group. It's not just people who want to keynote on testing, but any women looking into growing into more relevant speaking engagements. There's a strong tech flare to it, but we would welcome women on the path to speaking improvement and greatness. You could be an experienced speaker aspiring to become better, or you could be just starting but set on making fast progress.

Let us know of your interest on peer learning and support by filling in this doodle by Monday 5.10. The first session is just about discussing what we could do on peer support and what is a mastermind group.

Natural laziness and "It works on my machine"

When teaching programming to kids, a first "rule of programming" sinks in well. Telling the kids programmers are lazy, and that you should never write more than a few letters of whatever method you are about to call. Let tools do the work for you when you can.

My personal experience of people in the software industry is though that most of us are far from lazy. Programmers automate the tedium, identifying repetitive (and even potentially repetitive) tasks and turn them into code. That level of effort shows qualities where laziness isn't the first word that comes to mind.

But there's things where programmers are lazy in ways I find sometimes hard to comprehend. The laziness coins to a way of thinking that her own computer is the center of the universe, resulting in the infamous "it works on my machine" phrase.

At work, I was testing a few minor changes to the user interface. I had reported that there was a bit too much of indentation in one particular dialog. I had reported a choice of color in certain places was a bit to gray, making it appear disabled. Simple things. Simple things that stayed in our queue quite a while. So when they finally came through, I was happy with the idea that we'd now have two items less and we could be one step closer to our targeted "stop-and-fix" ideal, that we struggle with as a team on some areas more than others.

So I tested the changes. I opened the two distinct places that had been broken and rightly so, they were now changes. But the first thing I observe is that the thing that used to be grey but was properly indented was now incorrectly indented while black. And looking around a little more, to it seemed like to fix one specific thing, every other place in the program had been broken.

I reminded myself to breath while I was going through what I perceived as the obvious: the developer could not have tested this at all. With a few breaths in and out, I rephrased it in my head: the developer could not have tested this in a production-like environment. That's where the laziness in testing shows. My developers always keep hoping that their development environment is like production. And regularly they learn (from me) that this is not the case.

It turned out that our minified styles were included in version control where they were not supposed to be, overriding old stuff of top of the new. Developers were happy to find a root cause that enforces the idea that they still don't need to go outside their own environments. If it only stays this way, says a little voice in my head. So we have a discussion, resulting in changes to our TFS configuration.

The core problem remains. The developer environment is not the same as the end user environment, even in a ridiculously tiny product development like ours, and more so on anything bigger I've had a chance to work on. If I cannot overcome the natural laziness of the developers on this like my friends keep suggesting, there's another way to solve the problem. Turning the problem into a programming problem of test automation over various environments.

Meanwhile, I'm practicing breathing and encouraging use of other test environments at least for particular types of changes. It had been a while since I had to hear "It works on my machine".  

Seeing what is there, away from the eyes

We made significant changes on how our product handles logins, and I was feeling like it was a whole new feature and approached testing of it that way. You know all the usual stuff of valid and invalid passwords with various contents, looking through allowed character sets and seeing what happens then. And then there's the usual extensions to what you can see, like locking an account after enough trials and scenarios related to that.

As I was testing the login, I got particularly intrigued with the idea of locking / unlocking one's password, and with a little back and forth, I learned that our application counts the failed attempts also while in unlocking mode, and thus one wrong entry gets your password locked after you turn on the locking. Not quite what we meant.

I had a discussion with the developer on this, to learn that this was not new. It was just something neither one of us had felt the urge to test before. I was puzzled on what lead me to it now. Looking into my feelings, it was the risk of being bored. Wanting to see that things could be different than before.

With that idea, I stared at the user interface a while, and let my mind wonder. I realized that when running group testing sessions, people often miss things that are connected, but not visible. And I realized yet another hidden thing I had not paid attention to: audit logs. Kind of obvious thing, something I definitely should be aware of but something that did not remind about its existence visibly.

Software has so much connections that are there, that you need to see even if they were not visible. I'd be really badly off as a tester if I expected to get that kind of information from specs, it's the stuff that I tend to bring to the table thinking about other systems and scenarios in which things can be connected.

I updated my little pictures and checklists, to keep the core insights available for those who come after me. I'm looking forward to someone telling me all the perspectives I'm still missing.

Let me be myself - all testers are not the same

This year, I noticed that on one of the conferences was offering a workshop on Myers-Briggs type indicator for finding out about your natural style / personality, and how that might affect your style of testing. As much as I dislike the idea of thinking as a manager that the type really would tell you what one of the people you coordinate would do, I really like the idea of trying to understand oneself. In your journey to self-understanding, tools like this may be helpful, while they don't give you ready answers.

I was typed as "ENFP". Through those letters, I learned that I have typical patterns of what I lean towards, and I found understanding my stress reactions typical for the type particularly useful over the years in learning to work better with others. I also learned that a "typical tester" would be just opposite, and have tried to keep that in mind when assuming testers should be like me - they typically are not. I also later learned that in strong voices of exploratory testing, there's others who are typed same as me.

My first thought on noticing the session at the conference was that this is again the same old stuff. But right after that came the realization a friend of mine gave me, that is turning into a bit of a mantra now.

The software industry doubles every five years. It means that half of us have less than five years of experience. 

What's same old and obvious to me, might be something we've stopped talking all in all in the field amongst those who have been around a little longer.

Myers-Briggs is kind of complicated, and I recall reading five books on the topic on my journey back then. I've used a simplification of similar ideas by Lloyd Roden that groups testers into four categories. As I went googling for the reference, I came to realize this is from 1999 and as valid today as it ever was.

Lloyd looks at the then popular writings about personality types, and finds four tester profiles he names Pragmatist, Analyst, Facilitator and Pioneer. Within these, I'm a pioneer.  I went to dig out the summary slides I've done when reading the article while being a researcher.

I recognize myself from what the Pioneer is said to like/dislike, as well as can identify with the list of things a pioneer is good at:

• Be good at exploratory testing / bug-hunting / error guessing 
• Be good at challenging and improving things to make things more efficient and effective 
• Enjoy GUI-type of testing / lateral testing 
• Have good ideas 
• Be good at brainstorming ideas on what to test 
• Share ideas about different ways to approach testing 
• Identify and take necessary risks when required 
• Have creative ideas on how to test to find more bugs

With growth mindset, this does not define what I can do, but it could show what my natural tendency to gravitate towards is. And a working theory of mine is that people who want all testers to be automators most likely are not "like me" in personality and background. If that would be true, with automation emphasis we're redefining certain personality types of out of our recruitment patterns. I can just hope my working theory is incorrect. And if I ever have the time and energy, actually go and research my working theory. 

I named the blog post after a song that played in my head this morning with yet another batch of people encouraging me into automation: Let me be myself. I want to let others be themselves too. There's no one tester. There's a lot of great, diverse people with personalities and interests that compliment the others. With software running the world, we can't leave people out from the revolution, we need to learn to be more inclusive and stop trying to find the one perfect profile that should not exist for the bigger picture. 

Mob Testing at Testival

I'm in the process of working out how to best facilitate exploratory mob testing sessions, and all of my rehearsals don't quite work out as I would hope to. With feeling I failed, I keep trying again. And I tried again a week after the previous, this time in Croatia in an open space conference named Testival.

Introducing the session, I again went with rules, but I added one more to my list of two from CITCON. I decided to explicitly remind people on "kindness, consideration and respect" to work together as a team. And they did. 

The experience with the group was completely different than a week ago. This was a group of smart, a little puzzled individuals where some people found the idea of testing without a specification strange until I promised I'm happy to answer any questions they have about the software. 

They got started learning about use of my Mac, learning how to do right/left clicks and move between windows. Looking at how fast they picked that up, I was happy with how much better I've learned to communicate things like that as I'm noticing that some things I consider muscle memory have finally become things I can voice out. 

There were few observations I made about how this group was learning:

• The group had difficulties noticing bugs while focusing on understanding the software and making a list of things to fix. The third dimension was too much to handle at once, or some of the bugs were too subtle to jump to their view. But they found one that I pointed out to them they did, that none of the people I've tested this application before had run into. 
• The group would easily focus on shallow notes all around over analyzing one piece of what they had in mind. I changed the dynamics by giving them a constraint: "find all you can about the little area of features on lower left corner". With the constraint, we got to talk about things like undo (it's elsewhere, but connected to everything) and multi-select (you can do it but it's not a visible feature). And we found interesting behaviors on not having a menu but certain click combinations revealing features we were looking for in a menu. 
• The group had a special observer, who was uncertain about how to contribute the things he had in mind. He would often say things quietly or say them to me to check their correctness, and I noticed repeating to the group that they might want to pay attention to what he was contributing. 
• Everyone contributed and the group was creating shared understanding. I was feeling I'd love to continue longer than the hour, to deepen what we had learned and to put together more observations. 
• Very little of the things the group learned about the application ended up in the Mindmup document. The group was inclined to understand first and document only then. And since we were time constrained with an hour, we would not get that far. 
• The group was really in the yes, and... state. They would complete the previous navigator's sentences, and deepen where they left off without their ego forcing them to show how they could do best elsewhere. 
• Asking "What are you trying to do?" was a helpful question to clarify intent and keep the group in the yes, and... -mode. 
• With two rounds of rotations, I got to see how people improved. The learning for round 2 was quite wonderful to see. 
• It was nice to hear that people enjoyed doing this. The group was small enough not to have to split into inner circle (the mob) and outer circle (the observers). 

For next learning sessions, I will play more with what type of assignment I give the group. While I like mapping out the application / feature often as the first task, I was am truly this time constrained at work, I would not waste it on documenting much of anything else but bugs. There's always the choices with no right and wrong. I wish there was a way of getting them fast-forward into the application, starting from where some of my other participants had already learned. I could try also showing an existing map and seeing how that changes what happens. I also still want to start the exploration from the code instead of the UI. 

Women (like me) in Testing

Long time ago, I was sitting with my university presentation skills teacher discussing feedback I needed to give on a presentation of mine she just forced me to watch on video as part of the course. The experience was painful, but life changing. That discussion made me start my journey to become a public speaker.

There was another bit that she said that I brushed off and only thought about again recently. She told me I’m a feminist. I laughed and kindly declined the label. I did not need to stand up for women’s rights; there were no issues I had experienced. If I did not experience them, perhaps others did not either. I held this belief a long time.

Last autumn I met a lady, who woke me up to think about this again. She was a programmer, younger than me but with plenty of experience and she said exactly what I had said two decades ago: she’s not a feminist. There’s no need to work particularly on women in tech. I realized that as time had passed, I had started to accept other people’s genuine experiences that were different than mine. And I had run into some myself.

The discussion made me realize I had grown used to the idea of being a feminist. A woman who thinks equality is important. It’s about caring to do something about equality. I realize all feminists are not the same, and I don’t care so much about the label that I’d like to go into long discussions about it.

Since then, I’ve been picking up on cues of what I’m experiencing. I find the courage to share these ideas, since nowadays there’s an amazing group of women in testing and through getting to know this large group of wonderful testing professionals, I find that sharing my lessons might be of value to others. So let me share a few stories on the theme of being a woman like me.

I work too hard to be excellent

I’m the oldest of 6 children in my family. Two of us have ended up working with software. For years and years, my siblings that were not in this industry laughed at the geeky hobbies and work, making remarks of unsocial aspects of staring at the screen all day. The two of us that share the passion of the industry, infiltrate the realities of our work on many family meetings. It’s not uncommon for me and my brother to get into a heated argument of “can all testing be automated” in Christmas table. And the others endure our geeky ways, when we go into details of cool bugs and difficult things we’ve had the pleasure to work with.

As the difference in our geeky ways was established already a long time ago, I haven’t really talked about it so much with my non-software siblings. A week ago I did, and I learned something I consider profound.

My non-software sister has recently studying programming as an option of future work. She’s had a great coach working through some basic materials, and making nice progress on seeing how all this programming stuff isn’t that impossible after all. With changes in her current work, she needed to take time off from learning programming, so she came to talk to me about some joint learning efforts we had been thinking. We talked about teaching kids (girls in particular) programming and the world of computers, and I was asking for her advice on how to make progress on that. And her advice was surprising, but very honest.

“You’re a bad role model”, she explained. “Looking at what you do to succeed in the industry gives the impression that you have to work twice as hard, and be extraordinary, and driven”, she continued. “You need role models who are just normal, average. Like some of the guys you work with”.

With her telling me this, a lesson sank in. I live with a double standard. I expect more of myself than of others. And my gender just might have something to do with it.

I’m afraid of gender issues

My story with my teacher long ago shows I did not consider myself a feminist. I stayed with my beliefs of feminism being unnecessary for a long time, dismissing conflicting evidence. I did not want to believe gender could be relevant. It’s all hard work, right? It’s what you do what matters?
I’ve been treated very equally at work. The negative parts about how I get treated I’ve always attributed to being a tester. I remember one manager giving me feedback on being too abrasive, and that I needed to pad my messaging about issues and bugs better. That is a typical thing to hear as a tester, after all we tell developers regularly that their babies are ugly. I learned to communicate better, and took the feedback as typical tester feedback.

On two occasions, I’ve had a developer come and reveal to me after finding some particularly nasty bugs that they knew of those and left them in intentionally to try out if I would find them. Doing things like that is just stupid, even irresponsible, after all I do not find all of the bugs and tricking me isn’t really the thing collaboration is about. But again, I take that as the stupid things people do to testers.

As a tester, I’m really good at what I do. And I love my work, the joy of hunt for the bugs that so often are things no one would code in intentionally.

Recently with more programming tasks, the style of comments has started to change. People around me slip out sexist remarks and recognize my reaction: extreme discomfort. It creates two counter-reactions: I step away back into my comfort zone and wish I would never enter the world where people are treated differently based on their gender; and it makes me find my fighting spirit, telling myself I’ll show them all.

Where testing energizes me, the fear of being treated differently (with special attention, or belittling what I can or want to do or what I have done) drains me. Testing is safe. Programming is not. And when these issues arise, I’ve learned that managers will have hard time dealing with them. The best they seem to be able to do is to silence them, but they remain in people’s minds even if they learn to keep it to themselves.

I’ve come to realize that choosing testing comes partly from being safe of that difference I cannot change: my gender. Not that I would want to change it even. I love being me.

Realizations of some of the differences

I’m not a fan of generalizations, and don’t want to make one here on women. But I wanted to share some insights on gender differences I’ve picked up recently that resonate with me.

On a talk by Coraline Ada Ehmke on “He does not work here anymore”, she shares an idea on how women and men communicate differently. She describes this in a geeky way that resonated well with me. While men’s style resembles a straightforward request-reply protocol (“I ask, you respond to what I asked”), women tend to communicate with metadata in addition to the request-reply. The metadata encodes information about what kind of a response would be appropriate right now. If you miss that, the communication fails. I recognize that in so many cases of miscommunications, both at home and at the office.

Another difference that I started noticing is in how we deal with rejection and getting a no. I realized this from a personal point of view first, in the dating scene. Men might have to grow to become used to getting no and still asking for things. Like a friend pointed out, without asking and probing for relationship statuses, it would be hard to find that someone special. And we do spend a lot of time in the professional circles. Women might get used to, especially when working in tech, not having to ask even when they might want to. I started recognizing how much work I’m willing to do work around things where the answer, when asked directly, could be a No. For me at least, a bit more of training on being told No and still asking for things would do a lot of good. I suspect there might be a gender tendency here. Perhaps that tendency shows in why women don’t end up keynoting, because in the field of testing, “lack of merit” does not really explain the inequality there. I’ve learned that a lot of men that keynote ask to do so. They’re told no a lot of times. Quoting the “Talk like TED” book, “Every ‘no’ means you’re one step closer to yes”. A new friend in twitter is almost as wise:

If you want something, consider asking for it. Sometimes, it's that simple.

— Bryan Beecham (@BillyGarnet) September 18, 2015

Great advice, but sometimes unbelievably hard to follow. At least for me.

To end this with

My fear with posting this blog post is that the trend of labeling me on my gender just increases. My earlier commentaries on not finding keynoting women already make me sad, when meeting people in conferences that now only recognize that bit about me. I post this with the hopes of some of this somehow resonating, to share my stories. Posting this I consider a step on a personal journey of growth, learning to trust that I different sides of me can exist.

Writing about my experiences does not mean it’s my duty to drop all other work to engage in a debate about true nature of e.g. feminism. But I’m happy to have civilized discussions that aim for better understanding in the scope of what I’m experiencing and thinking.

Pressure or curiosity: Testers learning to program

It's getting to all of us testers. The message that the testers of the future need to be technical. The message that more and more companies set up teams of developers who are also responsible for all the testing is everywhere.

So you find it in yourself, like so many of my close non-programming tester colleagues have, to learn to program. It could be something completely new to you. Or it could be something you stopped doing 15 years ago, because you just found the world of testing from the business and value viewpoint so much more fun. Some of us find the motivation from the negative: feeling the pressure, needing to be 'competitive'. Some of us find the motivation from the positive: curiosity, seeing how that will improve the selection of things I can do with testing.

I find that recently almost every tester I know, including myself, have started taking the steps to become better programmers. On one hand, I'm happy for the turnout. But on other, it might mean that the side of not respecting the value of thinking in testing, at least without self-contained ability to turn that into test automation, has lost the battle.

My curiosity towards the code has lead me to learn that I dislike the stuff I was forced to learn on at school. The algorithms. The mathematical puzzles. The so-called funny little programs that were geeky in the wrong way (like paper-rock-scissors-lizard). I also dislike what automating does to the work of testing that I love so much. I dislike how it transforms my thinking into more procedural, how it forces me to spend time on details when there's so much of the world to see that I have to choose to prioritize out, thinking of long term over short term. I do it, because I believe it's good for our product development. But it makes me want to go work in McDonalds on a regular basis.

Coding from the perspective of solving my own problems is much more fascinating. There's an iPhone app I want to have. I will have it. And I know I need to create it myself. There's the excitement, and I don't mind at all doing great testing (even automated testing) around it.

Could it be that we need to look deeper into our strengths and interests to find what each of us would like to use programming on, instead of thinking that testers are programmers of testing problems? Because with that trend, there will be one tester less - with direct impact on the quality that comes out from our current pipeline.

Another thing on the programming trend that really puzzles me is languages. I'm a strong believer in using the same language for test automation as you use for the rest of your development. If my team works with C# and I bring in python because it's so much better for testing, I will be alone with my code. And I find from experience that bringing in selenium in C#, I get the whole team contributing, and whatever test automation we're doing benefits from the skills of the whole team. The trend still seems to be to look for a language specific to testing, be it a different programming language or vendor-language built into a tool.

For learning, my lesson is this. Pick a language, any language. But pick one that works with problems you find interesting to look into. Pick one where you have people close to you that you can collaborate with. Work with it long enough to get over the starting pains, so that you start to see the structures. Adding more languages when you know one isn't that big a deal. But knowing hello world in 20 languages but nothing deeper isn't that helpful.

Mob testing: Leave some of your ego at the door please

Last weekend was #CITCON - Continuous Integration and Testing Conference in an open space format. One of the sessions I set up was to spend an hour on Mob Exploratory Testing. I facilitated the session for a nice group of 8 people.

I went into the session writing two rules on the whiteboard:

1. Driver is not allowed to think at keyboard
2. Yes and... Continue where the previous navigator left

I had one person sit at the keyboard, telling him he's the driver for first four minutes and that it's a resting position in the sense that others will tell him what to type. I had another person as the main navigator, and suggested that the others could help through navigating the navigator.

This group was completely different in dynamics than any group I've seen before. I was soon happy to have a designated main navigator (lesson learned from facilitating at Agile 2015), because everyone would have loved to pitch in to tell what to do, leaving the driver confused on whose instructions to go with. But that did not stop people from contributing, loudly, and with disagreement. A new team of new individuals on a task most of them had never experienced before, with an idea of exploratory testing as something where you hack away to find bugs. They quickly forgot the task at hand was to learn the application and make notes ("a test plan") of things they should spend more time on.

Everyone appeared to be anxiously waiting for their turn to get to control the direction. The Yes, and... -rule was very flexibly followed, as in continuing with anything is appropriate and each new person would push to introduce their own specific idea of what and how should be tested.

In 40 minutes of mob testing, here's the visible result the team created.

They learned and saw more, but did not collaborate yet well enough on the task to make notes of what they saw. They got easily distracted with investigating anything that they might consider a bug (starting from bad names of Java-files when starting the application).

The main lesson I took out of this mob is that a group of people with egos requiring individual contribution is far from a team that works well together. With two rounds through the navigators, the team did not have enough time to grow together and learn to build on what the others accomplished. No roles yet got formed, and none was willing (yet) to step back and let others do the easy navigating, to get their focus on the things others were missing.

In hindsight, I realize I could have helped a lot more with how I facilitate. Now I chose to start with the rules and remind of the task at hand ("your manager will give you time to test stuff you've identified, identifying a little means you will not get to do the testing you should get to do"). But there's more I could have done.

I could have stopped the team members with a constraint that on the first round, only the designated navigator gets to navigate and others focus on understanding where the testing is going. I could have given one designated navigator a constraint to only write down things that others have already seen but failed to make notes of.

More practice and trying things out ahead. Need to learn what questions and constraints would work for facilitating a session on testing. Good thing that my next session like this is in Jyväskylä in just a few weeks from now.

I find it a good lesson to remember that when working in a team, our individual contributor ego needs to step back and let others shine too.

Access to code: denied?

I started in a new company three years ago, as the first tester in the teams. There was a lot to test. There were a lot of problems to be found and reported. I easily spent my time on the applications without ever getting it all done anyway.

I remember my manager asking me if I needed Visual Studio (license) back then, with a premise that I don't. I had not had access to code before (except that I would ask developers to show me stuff), so I wasn't thinking I would need it now.

There were these occasional struggles, when there would be changes I did not know of as no one told me. I could have seen the checkins, if I had the tools. I was also struggling with typos that people did not feel like fixing, that would take a significant portion of my energy as I just cannot pass them without slowing down just a bit. Easy fixes that I got tired of waiting for.

I started looking into my options several months into the job. At this point, it was established that developers would have Visual Studio but I wouldn't. So I installed the free version, looked up a few blog posts on how to get things set up and got myself access to the code repository. That was simple, just ask as the access was controlled in our teams. Developers were more than happy to reorganize the way we did things to whatever I found I wanted to volunteer for.

I quickly learned the places to go to to fix the typos, and haven't reported one since as I fix them faster. I learned to start the builds whenever I needed to. I created a habit of spying on commits, mostly on level of comments attached to them, but also into the code that was actually changed. I started reading code that was created, just because I could.

Again time passed, and we realized that I wouldn't actually be allowed to use TFS with my free version of Visual Studio. While it can be done, it's not what you're allowed to do as per license agreements. And I got "promoted" into the real tools of the trade. They didn't just give me Visual Studio Professional, but I got also ReSharper. Toolwise, I was where the developers were.

Months passed, and I used the paid version just as I had used the free version. Our builds changed from on-demand (which I would just run whenever there was a change, why would I waste time on testing something old that wouldn't go to production anyway) to continuous. And our monthly releases changed to daily, whenever there was something that was ready doing features one by one. I would deal with a lot of the merges and keeping track of what is in the versions.

Then I wanted to work on unit tests. And you really can't work on unit tests without refactoring the application while adding the tests. I needed to build the application. It did not build in my environment, there was a significant struggle to understand from errors I was getting that something wasn't installed. But I got there.

I had forgotten many of these steps, as things changed a little by little until I was reminded that the case still often is that access to code for testers is denied and that many of us still hunt for the information about the changes that we should know of. Having the access creates opportunities for better testing to happen. Why shouldn't we have that door open? 

My first full day of Mob Programming

We've been doing these learning sessions with Mob Programming. We've worked on refactoring, Selenium Webdriver tests on our application, on our unit tests and now on replacing an old component / technology with new. On the last, we spent a full day working as a mob, while the others have been 2 hours of practice on production code.

I'm finding it interesting to see how the group's dynamic changes depending on what type of task we're working on. When we work with something relatively simple (like the first two sessions), our problems of working as a group emerge easily. The driver will not wait for navigators to tell what to do but wants to "show off" or "just get this done quickly". The navigators step away from navigating, leaving it all to two vocal people, so it starts to look more like pair programming with the rest of people watching. From the first two sessions, we agreed to the third we'd go a step back from mob programming (driver - navigators) to Randori (driver - designated navigator - other navigators).

The third session task was completely different. This time, none of us in the mob could actually have done the task all by themselves, so the experience showed a lot more of the idea of bringing the best of everyone into the task. Our task was to replace in one dialog an old grid component with a new Kendo grid. It was the first place in the program where we had to work with subgrids and this brought in the fact that none had knowledge on how exactly that should be done. There were none of our own application examples to look for help.

With this task, Randori did not make sense. Having someone navigate who has no clue of what we're doing, isn't going to help with the navigation skills practice - for that we need something more shared. So we went for group navigation. And it worked much better than before. Partly because one of the developers opted out of the session and complaining about 7 people looking while 1 is working did not interrupt us. Partly because the task at hand required a group to be done effectively. And learning (through retrospecting) could also have it's share in doing better - trying, failing and talking about it probably changes the situation.

We worked as planned for 2 hours before lunch, but as we were not done with the task completely (someone told it was a week of work, no wonder we couldn't do it in two hours...) we discussed how to continue. With my gentle push, I knew that at least two developers would pair up on continuing on it for learning purposes, and the invite to join to mob was open. While there was a mob of 7 in the morning, there was a mob of 4 in the afternoon. The devs invited me into the rotation also in the afternoon.

There were all sorts of events and thoughts I noted during the day:

• Learning coding steals my focus from thinking "like a tester". I would need to use significant energy into learning what was going on in the code, so that I could contribute with the others. The thoughts of "this should be tested" don't fit into that way of thinking, I felt that for doing what I usually do, I need to take a step back from learning the details. It probably changes over long term for me when the code does not require as much attention continuously. 
• I could introduce some things from a tester perspective. Like starting the application while developing in different browsers. Or changing the data or making it more versatile to see problems more clearly and widely. Neither one of these ideas was particularly well received when the focus is on the code and code alone, but I can see that they will humor me with these on the long term, especially after we would do exploratory testing on the mob too. 
• There were many things that we should have had a mechanism to park for future that emerged during the session. We were annoyed with the tools and I felt a need to make a note of doing something about it soon, yet later (seems we did, as first individual task of one dev). There were ideas of what we'd like to learn. And things we'd like to get back to to finish them, in particular adding localization as the last task and any strings in the UI in general. But I guess the code might remind us about some of these later. 
• We saw many surprises from a technical perspective. We learned together there were two types of icons, and that to get them visible, we needed two different ways of implementing those. We ended up having a discussion about one/many subgrids and changed our implementation idea on the fly as we realized that the embedded assumption of one did not meet the needs of the functionality we were supporting. 
• Knowing HTML helps. While it might not be "real code but markup", it helps a lot when you know what the tags do. I felt my years of tweaking html manually were useful in building a connection on my participation in the mob. 
• The tooling problems you can't do anything about will annoy you 10 times more in a mob. We had a Visual Studio 2015 application restart problem requiring us to run the app again after changes. The slowness became painful soon. Similarly, Visual Studio 2015 was lagging behind in recognizing some of the changes we did, and waiting for the tool to become responsive again was more painful this way than it usually is. 
• Slow feedback with missing unit tests was very painful to me, not sure if others paid much attention to it. I've seen too much of TDD lately to learn to appreciate the fast feedback and knowledge of your old assumptions still being there all together when jumping around to change things. I felt certain I could help the team to share that pain  (and remove it) if we'd just mob more. 
• Tens of little mistakes got fixed immediately. Omissions. Typos. Wrong implementation with respect to intent. Bad names. Unnecessary pieces of code. Inappropriate data structure selections. I really enjoyed hearing my devs joke about "that bug would have been a nasty one to try to find debugging later". 
• My slowness as a driver was a good thing. It allowed room for clarity of thought. It seemed like having to navigate on a slightly lower level of abstraction made the communication of where we're going and what we're doing clearer. And that slowness improves tremendously already in a day with learning (and relearning) more of the shortcuts. 
• The two floors difference when needing one's advice in afternoon who was not joining ended up as worse code than it should have been. We could have called. We could have asked him. But we did not. We did something. I suspect we do that a lot. 

I had moments where I would think I'd rather be doing anything else but spend my day with the code. But I loved the social aspect of it, being with my team, having a team instead of people who talk to me once a week and when I initiate a question. And I loved how proud I felt about the people I work with and their skills, abilities and attitudes. We play well together. 

It felt appropriate this day of mobbing was the same day when Llewellyn Falco created his little infographic on putting a group of people together. That really sums up how it is: getting the best out of us all. Some of my best is still in front of us, when we actually explore the feature we're creating. 

The two things they did not teach me with programming at university

I've spent a fair amount of thinking about how I was taught programming. Actually, most of it I was not taught. I enrolled on a course, was given a challenge and then I learned a way to get the stuff done that needed to be done. There was very little teaching.

There was a podcast I listened some time ago on Planet Money, looking into why number of women might have been declining in programming. It made me remember the good moments I had with programming at a young age. I copied Basic programs from magazines (anyone else remember the line by line printed code lines you could rewrite?) and got annoyed with the bug there was in one I was copying, a bug that prevented me from getting the program running without fixing it. I learned English playing Sierra's games. And I write my first own program in high school in Turbo Pascal with simplistic graphics in the splash screen and a little test from some girly magazine. I also remembered that a lot of my early exposure to computers was shadowed with  the memory of limited access: the computer of the family was my brothers and I was the one who had to wait for it.

My brother has similar enthusiasm and a lot more computer time, so he ended up with all the cool demo graphics stuff. The Planet Money episode reminded me that often by the time we start in universities (College-level), my brother had way more experience than I did. And so did most of the people I studied with.

At Helsinki University of Technology, they left us learning quite a number of languages, focusing on the concepts behind any of them. I remember spending time on Scheme, C and C++, Java, Fortran, Python and probably others I have actively forgotten. I remember the courses teaching about the problems we can solve with programming, but they never really taught how to program. The group work was side-by-side work, often so that someone did more than anyone else.

Looking back now, I find there were two things I've learned since that I wish I would have learned sooner:

• The social aspects of programming, and the joy of discovery
  I can only wish mob programming would have been more of a method of teaching. Not watching demos, but  getting a chance to work on your turn in a team, learning. Not being hidden in a corner solving problems on your own, but emphasizing the social side of the work we do. Co-creating something is very cool. I can occasionally understand people we teach on #LearnWithLlew -stuff (beginners/teachers/kids in elementary schools) saying "I could actually like coding". 
• The language and it's IDE (tools) belong together
  We should not teach the language without the professional toolset for it. I can immediately see the experience of Java I had in school without a proper IDE make the whole sport different when writing Java in Eclipse. Painful does not add to my learning. Rewarding does. I suspect that a lot of courses still deny the access to IDE's doing a lot of the stuff for you, thinking it helps you understand the code better. I find that it probably is one of the reasons for bad experiences, that lead people (like me) to dislike coding. 

Perhaps I should, just for the fun of it, give the teaching at university another chance. Now I'd be as much "hobbyist" as my brother was back then. And the schools could have learned a thing or two about teaching from the professional programming circles. 

Making a tradeoff, user vs. technology

In the last few weeks, there's been an ongoing discussion at my work about a particular feature. As we finally had the discussion with the right people all in the same room, we finally came to a conclusion. And I tweeted:

Interesting discussion about decisions: can reasons of technology really drive us to create significantly worse user experience?

— Maaret Pyhäjärvi (@maaretp) September 1, 2015

Let me share the backstory to this.

The feature we've been discussing about is sort of the core of the user experience with the product we're building. I've never seen it as anything complex or complicated. It's a user interface to add in particular data. It was the first thing we implemented (that much of a core) and it's been enhanced based on user feedback, e.g. with keyboard use. It's founded on a component we call "old grid" - a free open source component, that just recently decided the next versions would no longer be free to use.

Some months ago, we were implementing another feature and decided to take in a new technical component "new grid" from one of the commercial vendors. We already knew our current "old grid" turned commercial, and it appeared there was a better one available from someone else.  With the idea of replacing "old grid" with "new grid", we included it as an integral part of the new thing.

As the feature came together and could be tested, both myself and the end user representatives voiced out concerns that the functionality on top of the "new grid" wasn't giving particularly good user experience. There were two clicks on things where one was sufficient before. There was uncertainty about what part exactly could be editable. And there were difficulties coming up with a way to get things to be as good as they were with the "old grid".

As components are code, you can always change how they work. But changing something to work in a way that it was not intended tends to end up, from a technical team perspective, into a maintenance nightmare. Every upgrade is major reimplementation. And the ways to change things are often awful hacks that barely stay together. We looked, and while changing would be possible, it would not be easy. Awful hacks are not welcome.

We had already bought the component. We had not only bought the component, but coded it into a complicated feature that wasn't now good enough. We had discussion-wise committed to taking the same component everywhere in the product, lowering the user experience with the core feature too.

So it was time for the discussion on what we would do. We had reasons of technology to use the component we had and extend its use without creating awful hacks - hacks that we felt are theoretically possible and could just make things worse. We had the user experience to consider.

All the ways to build the thing we needed without an awful hack ended up as worse user experience. We were very close to deciding that this would be the case. But we ended up, to my surprise, with adding the awful hack (and considering changing component to something that would do what our users need).

We also checked with the component vendor.

"Forcing the Grid to be in edit mode at all times is not supported out of the box and adding such feature is not planned. You can achieve similar behavior using ... however such custom solutions have certain drawbacks and negative performance impact."

I've had similar discussions before. In the tradeoff, the user experience often loses. Technology and "things that can't be done" wins. Can't be done includes a component of cost, with work to implement - and in this case, reimplement. But so does user experience in the wasted time for the users.

The whole discussion was somewhat of a comedy to watch. In a team of people who all agreed to listen to the users and not feed them with things they did not want, we stopped one with a leading question to only have another one with a leading opposite question jump in. With all the different leading questions in the table, we got the honest answers though. And I believe we made the right decision, even if it was different from the decision we made three months ago with different knowledge and understanding.

I'm still hopeful that with smart people in the development team the "awful hack" will end up as little less awful.