Magic tricks are awesome… well some magic tricks are, when pulled off so well that the audience turn a blind eye to the actual trick. A magic trick that causes awe is one that changes how our world works. We as human beings understand logical flows in our day to day activity and magic can sometimes alter that. It creates a sort of, ‘wait, that’s not how my world works’ alteration in how we logically perceive what should have happened when the magician revealed the card we kept so dear to our mind when asked to pick one from the deck. This actual change in perception sparks interest, you, we, they, want to know more, we want to know how this became possible! This sort of change in perception, and interest in wanting to know or learn more is common throughout most of our life, it has even been seen in children as young as one years old. But how do we create that sort of excitement in our day to day working lives, that eagerness to know more about what is going on. But on the other hand, sometimes change can be too impactful, we can’t go from Waterfall to SCRUM in one swoop! How do we introduce change such that our intended audience don’t notice they are changing!? Sometimes it’s the magic trick that creates the want for learning, but once we are on that path to learning, how do we learn more without learning too much in one go or maxing out our own Brains RAM. Let’s attempt to break this down.
We as human beings are afraid of change, it’s an epidemic! So how do we introduce change, such that the change is not even noticeable? Take for example, if you have a public profile living somewhere on the internet, let’s say Facebook. Over the years you may put up a new profile picture or 2 or 20, but interestingly if you take a look at these profile pictures over the years, you will see change in how you look, but you won’t have noticed this change. But how? Well, simple, because you see yourself every day, so the change becomes hidden from perception. This phenomenon is known as Change Blindness, there is a test that is done to demonstrate this, called the gradual change test. This test will take for example a picture with many objects in it and gradually take one small item away from the picture, for example a tree, a bird flying by, or the colour of a house. Then after a little while the test will stop, and then compare the picture at the beginning with the picture as it is now, it can be quite surprising how different the two pictures end up, but you may not have noticed the changes. So we need to be able to extract this kind of gradual change and bring it into our everyday learnings, but the question then is, how do we break something down so small, that the change is so unnoticeable, like how your appearance changes without you even batting an eyelid?
We start by looking for the low hanging fruit, the kind of changes that can give us these quick wins with little or no friction in adaptation. Let’s say our goal is Continuous Integration and Continuous Delivery or perhaps even Continuous Deployment. We are not going to down our tools and try and look for the best process or new tool out there that is going to give us CI/CD out of the box. Although of course some tools, practices and processes will claim such can be achieved with their offerings. But it doesn’t work that way, introducing CI/CD in one swoop is a big change and can be very impactful, it’s the kind of change that will end up with the developer maxing out that psychic RAM and not being able to process anything else. We analyse our threshold of perception, what are the small changes we can add to our day to day workings, such that we don’t notice the gradual introduction of change. For example, adding weights to a bench press one pound at a time after each set and stopping just before the point of noticing there is too much weight to lift. In CI/CD we can start with automation (I’m not talking environment automation, though that would be one of the end goals).
Before we even get to any kind of code integration using the likes of TeamCity or AppVeyor, we begin with test automation. Having red or green tests highlighting changes in our code base being run as part of our build and compilation whereby one test fails highlighting a simple impactful integration change, we fix, we learn, we move on to the next thing. But the important thing is, we know automation is important for CI/CD, but we are starting very small and having the automation of our code through tests and the beginning of demonstrating its potential value. This is the very first step in our CI/CD process, we then move onto committing the code to source control and having our CI implementation pick up those changes etc. This way we can look at the bigger picture of wanting CI/CD but break it down in such a way that we start from the lowest of the low hanging fruit and gradually introduce these changes one by one, one step at a time so developers are not aware of wholesale changes to their workflow.
Another helpful method of bringing in change, is when we don’t learn as individuals, but more so via group learning, this can be in pairs known as pair programming or also using a technique taken from Aikido, known as Randori (also known as mob programming). A useful exercise for this can be by helping improve a developer’s productivity by learning refactoring shortcuts. By applying mob programming a group of developers could sit around a computer whereby in similar fashion to pair programming, one person is the driver and everyone else are the navigators. As the driver types in code, one person could point out a shortcut way of typing out a using or try-catch block, the driver would type this in. Then when the time comes again, that a try-catch block is needed another person in the group might point out the shortcut, this sort of effect can continue to happen until everyone in the group gets it. The knowledge in a group learning setting is much more powerful than any one individual and we help share the knowledge gained along with the traditional benefits of a pairing exercise.
The great thing about a mob programming exercise is that external people will want to know what is going on, they don’t need to be fellow developers either, they could be QA’s or managers. You see a group of people generating excitement at learning new techniques from each other, people outside will want to know what is going on, they will want to sit with the group and find out what is so fascinating, it’s human nature. It’s the same as when you are at a conference, you see one room full of people waiting on a certain session to start, where as another room with one or two in attendance, you are going to want to know what is going on in the full room and will gravitate towards that very room before even considering the nearly empty room. Continuing with the topic on the power of group learning, sometimes it’s useful to have what we may call an expert in a certain aspect of our day to day working sit with us while we write software. Let’s say we have a QA manager sit with us and watch as we write our code and tests, we will naturally try to write better tests and cover more aspects of testing such as happy and sad paths, the QA manager doesn’t have to say anything, they can just sit and watch. This technique is known as holding the space, whereby the developer might feel like they are being judged and must prove themselves worthy of knowing how to write good clean code and tests.
Another area of gradual change is the adoption of the agile mind-set, a term first coined by Linda Rising. Using the agile mind-set, is where we try to adopt failure and problems as opportunities to learn and move on and make better but in a continuous iterative fashion, a belief that we can all improve over time. There are many developers out there who believe they are born with talent, these are the kind of developers that will not adopt the agile mind-set. This is simply down to the fact that failure might highlight a weakness in their practices, so they will back away from anything that looks like failure and not realise it as an opportunity to learn. Research has seen that children as young as three years old having strong opinions of themselves and therefore not trying new things.
At the beginning I briefly mentioned our brains RAM and its ability to only store a certain threshold of information at any one time. We need to be mindful of this, if we try to learn too much in one go, we reach a breaking point, become stressed, tired and nothing else will get stored. We need to be able to take breaks when learning new things, or even better, develop habits, learn a little bit about something new each day, take a break, rest our brain and learn to keep up that learning the next day. The same can be said when you work out in a gym, you can’t continuously work the same muscle, it will become tired and weak and you will eventually stop. The next day you can’t get back to the gym and work the same muscle aiming for the same outcome, rest is so important for all muscles, including your brain. By practicing more often, your brain will create pathways, linking all the little things you learn each day and you develop muscle memory. If you break the learning down into small iterative day by day habits when picking up some new technique, eventually you won’t even notice yourself doing it, just like those pictures of yourself over the years on Facebook. And the most important thing is, you won’t max out your brains RAM and will have room to do much more.
With anything, it’s important to keep your habits going, it’s like having a clean kitchen, if you continue to keep it clean, even after just having a cup of tea and cleaning up immediately afterwards, then it will be much easier to clean your kitchen the next time. However, if you miss the beat once and let a mess build up, it becomes much more difficult to clean up the next time and you will be more reluctant to clean it up. It’s the little bits, like clean and testable code, it’s easier to continue adding little tests each time we write new production code than retro-fitting them after, we are more reluctant to sit and write tests for hours for code that has built up, than a couple of minutes writing a test to cover a few lines of code.
In summary, it’s most important to keep change small, simple and iterate continuously with little to non-existent friction.
Thanks for reading and keep building awesome.
Until next time!
Ian B
P.S. You can also find me on Twitter: @ianaldo21
Ian Barry 