An Evening Detour to TCR

At an usually early time for me, I waved goodbyes at the office announcing I was heading to a workshop on TCR and greeted with a bit of rolling eyes and quick googling fingers. It was already established that I was more into volunteering on all sorts of learning activities. Aki Salmi hosted a workshop session on TCR with Tech Excellence meetup, which I just so happen to facilitate, so I had all the excuses I could need to get over myself and over  there.

TCR - Test && Commit || Revert - is a programming workflow  or a test-driven development flavor. Reactions have been from "well, got to try it" to "why are we confusing TDD more" to "will TDD replace TCR" and it feels like a worthwhile thing to do in a great company.

Aki introduced the thing we were about to be experimenting with. Test-Driven Development (TDD) as we've come to know it has three steps, RED - GREEN - REFACTOR, and Test && Commit || Revert (TCR) removes the RED. If your tests aren't green when run, you lose what you worked on. If they are green, they get committed as the next baseline to work from.

Other than the focus on experiencing TCR, the session was framed by 3x25 minutes of paired work with sharing impressions in between, the Lift (Elevator) kata and whatever the pair ends up choosing as their language.

I paired with one of my favorite people who I yet had never paired with before. They came in with things set up on their computer, so the choice on language and IDE were settled: Python on Vim.

Over the three 25-minute sessions, the promise of having fun was well delivered.

• The most common reason of reverting for us was syntax - we missed a part of formatting. This made me aware of how much I prefer relying on Pycharm as my IDE, with having my focus free from the details of the syntax. We also had great little discussion on the feeling of control of having to know / do every bit in Vim I wasn't appreciating. 
• With another IDE, I find it relieving to work with intent and generating frames for the code and the Vim as editor made me aware of how much I appreciate other tooling. 
• Differences on Python / Java felt evident in running tests with same name that Python just dealt with for us, while we would have had a couple more of reverts if we worked in Java. 
• One pair "cheated" by commenting out the failing tests and I'm still confused with it. Being always green if cheating is encouraged is easiest by never having much in the way of tests, and that cannot be what Kent Beck means with "Cheating is encouraged, as long as you don’t stop there."
• With the workflow, I was missing seeing the test fail to test the test before implementing. I disliked the thinking as the computer when I would much rather see the test fail first, but wasn't willing to let the test be reverted just for that. 
• Putting the commands together so that your changes are gone on red increased the sense of risk losing your changes and introduced a language of betting a small amount of work. 
• Being painfully aware of the risk of losing changes keeps changes small. It would require next level abilities compared to what we were working with though that we could identify making designs driving us to smaller steps for this. 

Overall, I think I was just as bothered with "losing my IDE" as "losing the RED".

In the discussions afterwards, there was speculation about would something of this sort be more necessary when working on trunk-based development where folks might commit tests while they are red, but it sounds to me like a different problem to just the programming workflow.

I find all these things useful as ways of learning about what you're comfortable with and how constraints of all sorts impact your way of working.

All in all, this just felt like a relaxed version of Adi Bolboaca's baby steps constraint, where you revert if you're not green in 3 minutes. With this style, you can see red, but get to a similar practice - making changes intentionally small without losing the feedback of a test first failing to know you're actually testing what you intended.  

Open Source and the New World of Creator Responsibility

As I'm minding my own business, doing some testing and enjoying myself, I get brutally interrupted by an incoming message. Someone somewhere has a problem. With the product I work with. I know that I care a lot, deep down, but the timing of the message is just so inconvenient. Reluctantly I offload from the work I was doing, preparing myself mentally to dig into the intrusion.

As I read the message and related bug report, I feel the frustration in me growing. The steps to reproduce the problem are missing. The description of the problem is vague. It feel like the reporter did not even understand what they were doing, let alone knowing what  the product was doing. Reading the text again and again, I come to the conclusion they have an actual problem, but their report, all without the right details and logs does not help me to do anything with it.

The tester that I am, I start testing the situation myself. Sure enough, it is not like I have tested our product together with Google Ads management interface. As I set up the environment, I realize I have to have an actual campaign set up so that I could even reproduce the problem. I toy between the "going to ask for company credit card" and "use my own credit card, here's the opportunity I always wanted to try ads for my own stuff" and go for the easy route and build a little campaign to advertise my conference. I confirm the bug, test more to figure out exact steps to isolate it to know what is the minimal impact workaround I can suggest, collect the logs and attach all of my investigation into the records I started with.

The fix is ready in 10 minutes. The release of the fix takes a little longer.

All of this happened in a project where I get paid for my time. Yet I am frustrated. But what about when we find ourselves working on our pet projects, sharing them as open source?

First of all, the code, whether closed or open source does what its creators make it do.

Two reminders in one tweet:
1. Algorithms never make conscious decisions, they do what they’re told
2. You’re responsible for what the code you write does, both socially and technically, including higher-order effects. https://t.co/jRLHuGOXIk

— Pete Holiday (@toomuchpete) November 24, 2018

This means there is always creator responsibility of what can be done with the software you created.

With software, it's not just about being a creator as in writing some lines of code, but it is also being an owner of what you started creating. You can be responsible for the code you wrote to an extent, but when you move in open source projects to the idea of being responsible for code others created on a codebase you started, we're piling a lot of work and responsibilities on someone who did not really opt into it.

There was a great example of that this week.

Holy hell, Node. A package with 2 million downloads a week and the maintainer hands over control to a rando stranger? And now it's mining cryptocurrency. Wow.https://t.co/V2mQ8fS2PZ pic.twitter.com/MkqhHzjic1

— Kenn White (@kennwhite) November 26, 2018

It wasn't *mining* it was *stealing* as many pointed out. But the really peculiar thing to look at was the formation of camps in assuming different responsibility for the owner as original contributor.

Finally posting this was motivated by a good friend of mine running a relevant open source test automation tool project tweeting this:

As an author of an open source test automation tool, I'm surprised how bad bug reports we often get from testers. I don't expect many users to be able to provide code contributions, but reporting issues ought to be one of their core skills. </rant>

— Pekka Klärck (@pekkaklarck) November 29, 2018

 Going back to my story to start this blog post, you can't really always expect that your users - that is what they are even if your project is free and open source - would take the time to isolate and report problems. And when you make it so, at worst you are like another open source maintainer who goes around bragging on quality of their code when reality is that their users just don't bother reporting but take the choice of just walking away.
  
I know how to write good bug reports yet I rarely do. I only do it when I get paid for it, or as a result of it I get something I need. I want to optimize the time I spend and a quick report on problems is the smallest possible contribution I can choose to take.

Information is valuable for a project that wishes for wider scale adoption. While there may not be direct money coming in from an free open source project, I find that many of the relevant creators have found a way of turning their thing into some income flow.

Say thank you for making you *aware* you have work you can think about doing, and stop blaming anyone who works free. I know it is hard to do, even when you have a paying customer.

The Rewrite Culture and Programming Ecosystems

With 25 years in testing and close collaboration with many software teams working with different languages, there is a particular aspect to software development that is close to my polyglot programmer heart. I love observing programming ecosystems.

The programming ecosystem is a construct around a language that shows in many ways. We see some of the aspects in jokes of how different programming languages approach things. I see it for now as a combination of at least the following:

• programming language
• preferred IDE
• 3rd party tooling and use of libraries
• community values
• culture of what you can do (without getting in too much trouble)

Moving between ecosystems makes you pay attention to how things have shifted and moved. The bumble bees moving between ecosystems look to be advancing things within the ecosystems, trying to bring better parts from one to another.

I'm thinking of this today, because someone proclaimed yet another rewrite. They will scrap all there was because figuring it out is too difficult and it is ugly code (tm) and write it again beautiful. I just think the definition of beautiful here is "I understand it", not "We all understand it". And my tester spidey sense is tingling, because every single rewrite I've ever seen results in losing half of the features that were not evident from the code,  but held in the tester memory bank of purposes why the software exists and flows for users it is supposed to be created for.

I realized rewrite culture is part of the C++ ecosystem a little more than some of the other language ecosystems. When in Crafter community we have the discussions of generally favoring refactoring over rewriting (gradually cleaning up), suggesting that in the C++ ecosystem feels like I'm suggesting something unspoken. Knowing how much the tooling differs for example for the C# ecosystem, this all  makes more sense. Refactoring C++ is a different pain. And it makes sense to move the pain in this ecosystem more towards those who end up testing it with a lot of contextual information.

And please, don't tell me that "not all C++ developers". Enough of them to consider it a common view. And not just in this particular organization.

We become what we hang out with unless we actively exert energy into learning new patterns that contradict what comes easy.

I love programming. And in particular, I love the programming ecosystems and how it talks to me about the problems I end up finding (through paying attention) as tester.

A lesson from my brother, the developer

"You never talk about your brother!", I was told yesterday as I mentioned I have a lovely brother who is a developer, just a little younger than me that he always needs to keep on competing with me and never quite catch up and who just do happens to work at the same company as I do.

We don't really work together. Work gives me just as much excuses to call him up as the fact that we're related, and both require conscious effort. My brother is lovely, and really really good developer. He works with identity management systems and I work with end-point protection, so he's on a component and I'm on a product. Recently, he's on a component that has been failing a lot in production and that gets easily blamed even when it isn't, and some of the illusions around that are so much easier to address because I can call him up whenever. 

A few months back, I called him as I was preparing a talk I wasn't particularly into doing. I had originally committed to the talk to support a developer who was new to speaking. They backed out, and left me delivering the talk by myself. So I called my brother to think through what had changed in the last 10 years. 

What he shared was foundational. He talked about how as a young programmer, he got to take a requirement and turn that into code. How most of his time went into writing code. How code he wrote was predominantly Java. And how now when someone joins in as a young programmer, they enter a whole different world. 

Most of a new joining programmer's life is no longer writing code. It is writing code in multiple languages. It is configuring environments (as code). It is tweaking parameters, usually not well documented, to get the third party components to work your way in your environment. And it's not that writing code is enough. You need to write tests. Unit tests. Integration tests. System tests. And as you're writing the tests, you need to explore to figure out all the things you need to test. 

Expectations for a young programmer has skyrocketed. We expect them to start more ready, and cover more ground. 

As a tester, I'm often worried of my mindspace, ability to track different levels of abstraction and keeping quality of my work on a level I can be happy with. Not as perfectionist, but as someone who aspires to be better every day. My brother, as a developer, isn't that different. The world is changing around us for us all. 

We're both asked more each day in our respective professions. The entry level requirements are going up. And with the next generations of future professionals growing through the elementary school now being taught programming from grade 1 onwards, it starts to make sense that programming is an entry level requirement for testers. 

It's more about the foundation, than the active use of it. Seeing the possibilities. Knowing to ask help instead of fighting alone. 

Test Automation Legacy Code

10 years ago I left an organization, that was top-notch in exploratory testing but had no test automation. With exploratory testing alone, I helped introduce the foundation for what would become more aimed for continuous delivery, introducing continuously delivering (with a lot of manual steps) to a beta program. The technology preview concepts and ideas still are easily recognizable, a decade later, without memories of history: it's just a way things are and have been.

While I was away, test automation got a foothold. Looking at it in hindsight, I'm happy I wasn't there to mess it up: great testers favoring the thinking part of testing and speaking up a lot about it are one of the most relevant blockers useful automation has, stopping automation being born while it's still learning its place and form. Lesson learned: give room for things to grow you don't believe in, and they may grow into things you do believe in.

Now that I'm back, and I look at the test automation generated and feel joy on the accomplishment of introducing that there. I did not do it. Or maybe I did, by stepping away and leaving the battle of opinions unbalanced, for the automation side to win. But it is there, it is doing real testing and while it has many many problems, it is a cornerstone of the way we build and release products.

In the 10 years, I've changed. I've come to remember that I was 12 when I wrote my first program. I've come to appreciate internal code quality, and recognize when its lacking. I've stopped looking at testing testers do, and started to look at programming productivity to produce the right quality.  I've trained with people identifying as a legacy code expert, and re-learned programming legacy code first, test-driven development second and always driven by hands-on work over reading about it.

This week brought me new appreciation in the role of legacy code in what I do now for our test automation system. I'm helping us clean up the mess, without removing the value so that we can add more value. I draw from lessons on legacy code, lessons on (test) product ownership, and intertwine those so that the automation we have would better serve a product line.

I look at this as lifecycle. There's someone to select (or create) the framework. There's someone to use that framework, adding tests to the best abilities they have, doing real useful work. And still, there's the time when the code running the test automation is legacy, still living and breathing, and needing attention to not block us from our future enhancement aspirations.

We're inclined towards a rewrite, while refactor is a better option. When the existing structure emerges from the mess of duplicated details, changing pieces becomes timely. Mending the systems, not making them.

Learning Programming Test-Driven

I've been delivering a test automation course, in a mob format. I get the whole group together, to work on test automation activities. We first get an experience that we share, and then we talk about what we learned and need to know about automation.

We've typically spent a couple of sessions on Selenium web driver, first just creating a test that runs, but soon after refactoring the tests so that we'd have more of a page object pattern in use. We spend a session on ApprovalTests, just to figure out what could be tested if we approached testing with creating and comparing to a "golden master". We test an API in a "fill in the blanks" kind of style. And finally, we spend a session starting a program blank, seeing where Test-Driven Development takes us.

The Test-Driven activity has turned out to be my favorite. I love how the tests grow with the application. I love how small steps end up taking us to a coverage we wouldn't create later on if we tested after. But what I love the most is the way the group - usually full of people who don't identify as programmers, some people who have never written code in their life - reacts to it.

We usually do very simple problems like FizzBuzz. Getting the 1st test out of the group asking for a single example is often the hardest part. Turning the example to code some syntax needs to be revealed, but none of the cruft around classes, just a single test. And when most of the programming in the IDE is learning to use the automatic generation of methods, people come out with a very different feel to programming than if they had to know how to write all the magic words around it.

We've done this in Python. We've done it in C# while I still had Visual Studio. We most often do it in Java. And there is little difference in these two when the full editor support is available.

The reactions of the learners I've worked with make me want to experiment with this more. What if we could teach programming so that we did not go through the usual moves of naming concepts, but we could teach test first and experience first. Naming what you did can come later. Even much later, when you've seen several examples of how some things are done or used.

Observations on Survivorship Bias in Programming

Programming is a fascinating field of study. For a long time, I was discounting my programmer abilities for never staying around one language long enough to get fluent with syntax, and if you need google to remember when others (supposingly) didn't, it must mean that I'm not a programmer.

Mob programming changed that for me. I saw that others needed to google heavily too. Just like me, they remembered there were many sorting algorithms, but needed to check how a particular one would be implemented - they knew, just like me, the word to google for. And obviously, it's not like that is a problem we need to solve every day in the real life of a programmer, that's where libraries come in.

There's still other things that come in as a little voice in my head, trying to talk down the programmer me.

• I don't take joy in all the same types of programming work as others around me do
• I don't pay attention to all the cool libraries that are emerging and their inner workings for comparison purposes, still often happy to go with what I got
• I'm more interested in mender than maker types of programming

I realized that instead of listing the things I do, my voice inside my head lists the things I don't do. And as so many women before me, when I don't tick all the possible boxes, I don't apply. Instead of a job application, I do this on what I identify myself as - usually as a tester, not a programmer. Yet recently working with my inner voice, as (polyglot) programmer in addition to all the other things I am.

There's a thing referred to as survivorship bias. It is our unfounded belief that when we are successful, the things we did are what are needed for success. All of this, while there might not be as strong correlation as we like to tell ourselves.

So if a programmer does well mostly talking about technologies in particular way, both they and others around them attribute the visible interest in technologies as a reason they are a good programmer. A new line to a list of what we must be to qualify is born.

If a programmer does well not collaborating with others, just focusing on solo work to think deeply around the problem, both they and others around them attribute ability to work alone as a reason they are a good programmer. A new line to a list of what we must be to qualify is born.

There's many behaviors we see successful people do. Without mobbing, the control on what people choose us to see is on them. But each thing creates a new line to a list of what we must be to qualify. 

Survivorship bias is strong in programming, and it results in lists that feel impossible to tick. And when the visible behaviors around you differ, it can be really easy to discount what you are.

We need to make it easier to be a programmer. It's not an end, it is a journey one can start. And there's many paths we can take. Be careful not to force the path you have chosen, be open to other options. 

Your stack isn't as full as mine

Recently, I've seen increasing amount of discussion on "full-stack engineer" coming my way. Just as it was important to me at some point to be identifying clearly as a "tester", I have now colleagues who find similar passionate meaning around the "full-stack engineer".

Typically, one of these full-stack engineers works on both front-end and back-end. So on the web stack, typically they cover the two ends.

An engineer wouldn't be properly full-stack if the stack did not include both dev and ops. So being DevOps is clearly a part of it. 

Some of these full-stack engineers take particular pride in including testing (as artifact creation) into their stack of skills. They can deal with testing so that they are not dependent on testers, and more importantly, so that they feel safer making changes throughout the stack that is getting too big to keep in mind at once.

The first place where the fullness of the stack starts really breaking is when we face the customer. Can a full-stack engineer expect to get all their requirements cleanly sliced, or should they also have capabilities on understanding, collecting and prioritizing the customer's explicit and implicit wishes? This is usually where a full-stack developer throws responsibility over to a complete product owner, who magically has the right answers. A Complete Product Owner is the customer-side match for the Full-Stack Developer.

And for me, the idea of being Full-Stack Developer breaks in another way too. The web stack isn't always the full stack. For me it most definitely is less than half of the stack. The system created with the web stack is just as dependent on the system created on C++/Python -mix than the other way around.

So frankly, my dear full-stackers. Your stack isn't full enough yet. Time to move towards polyglot. Onwards, to the unicorn state.

*said on a day I had to look at C/C++, Python, Groovy, JavaScript/Angular, Java, CSS for work, and C# for hobbies. I feel slightly exhausted but certain it isn't going to change for anything but wider.

Safe co-learning and learning about oneself

A few weeks ago I was asked to set up an opportunity to teach "Teaching Kids Programming" -course at a local elementary school in Finland while he was visiting. I contacted a local school, Ylä-Malmin peruskoulu, as I have my own son there on first grade and we set up a few sessions with 8th and 9th graders.

I volunteered to co-teach, but also felt somewhat of a fake. I love computers and software, but if you've ever read anything I post on my blog, I'm not a programmer. I've passed various courses on programming, even implemented occasional minor production features, but I love testing. Not checking (automatable part of testing) but testing - thinking and learning through exploring. Teaching programming, when I have high respect for people who enjoy that while I don't, it's a bit of an odd compilation. 

On the first class, I was walking around the room helping the students until I was at a point of me supposedly leading a part of that class somewhere in the middle of it. The first class was largest, loudest and had most difficulties in concentrating. I failed to get their attention and needed to give up - intimidated by the 8th graders. I could easily remember discussions with a friend of mine from high school who would become a teacher and me swearing I would never ever want to teach grades 7-9, the behaviour our teacher could expect from us back then was just this - not paying attention unless you deserved it. 

With failing once, I set out to not fail a second time, at least not the same way. I would ask to start the class, instead of jumping in in the middle. And then opting to jump out later if I felt I couldn't remember the material, as someone else's material is a very different experience than one's own. 

In retrospect, little did I know of what "co-teaching" would mean. It would mean that by Friday (3rd class), I would be co-teaching with a local teacher from the school and that by the last of four classes, Llewellyn would leave the class leaving us teaching. It also meant that the local teacher will teach more modules from Teaching Kids Programming -materials, as he was telling us he would run the course through spring semester with his computer science students. Co-teaching ended up being a great way of supporting us and enabling things to continue. 

All in all, this was a fun experience. But again the stuff happening inside my head puzzle me the most. I felt safe co-learning materials with the students. I realised again that I set my bar on "programmer" label quite high, and almost regardless of what kinds of programs I could write, as there were things I could not write, I would feel fake. I realised the bar is higher for me, and only set by me - perhaps a little by a brother of mine. 

I'm starting to feel that my year of exploring into code & programming will actually end up taking me deeper. I've found groups I'm comfortable with. I've found application areas I'm enthusiastic about (not checking!) to want to program. One thing has not changed though: I've always known it would be just a matter of choice to learn more about programming. Choice is a time-commitment though. It's always an opportunity cost - leaving out something else. 

I want to learn more together with my kids. Programming, exploring, different fun stuff we can do with technology and the wonderful application areas that I would feel particularly passionate about. Passionate enough to harness the tool of programming outside the "asking programmers do the programs" -idea that I've been working with so far, very successfully.