Comfort for the future you

I am always stupid in my own eyes when I look at the code that I wrote 6 months ago. I do get it, but I would have liked to have written it better, in a more elegant fashion. I always have mixed feelings: I feel good because it means I learned a lot in the meantime, but I also feel like I haven't done a good enough job. This is a problem for any content creator, writer, programmer, and so on. Let's learn how to create comfort for our future selves by putting quality first.

Code is more often read than written

We often look at some of our older code and reading it is difficult. We know that we work in a complex domain, where we need to know so many things just to get started. We need to know the technology, the syntax, the business domain jargon, and so on. Considering that we know all that, it still so happens that older code (even from a few months back) is very difficult to understand.

The question is: why did we write such a bad code? It has happened to me more than once when I have had to look at some older code, got annoyed, and said this code is a mess. Then, when I looked at the author, it was none other than me. This illustrates that I'm maybe a better programmer now than I used to be. Or, it says that I needed more improvement feedback on that code, either via a code review or a strict pair while writing it.

If, during our pair programming sessions, we focus on the readability, clarity, and usability of the code at hand, we will certainly have better results in the long term. It's often not enough for just one person to write the code and ship it. There are always improvements that we can make to that initial code.

Think about all the people who read your code, and how much time and effort would be spared if we took the time to write some code that is easy to understand. Of course, this comes with a cost, but we need to balance the time it takes to write the code and the time we imagine will be spent reading and understanding the code.

Pair programming comes with some help for this situation. One of the navigator's main jobs is to read the code over and over again, from top to bottom, and think about how easy it would be to understand it. Then, they need to stop the driver and come up with improvement ideas on naming, domain jargon, coherence, brevity, and so on.

Exploratory testing with pair programming

Imagine that you have a programming task and a tester sits next to you, immediately testing the code you have written. Well, that might be an exaggeration, but at least the tester is doing a live code review with a clear focus on testing.

The tester's mindset is to think about how the system under test would be destroyed, while the programmer's mindset is to think about how the system needs to be created. Without a doubt, a programmer is highly optimistic and believes all will be good. A tester is highly pessimistic and sees potential cracks in the system, including errors, issues, and so on. This optimist + pessimist couple is great because together, they can spot the correct implementations, errors, defects, or bad names from the code.

Exploratory testing is a way of testing where test cases are not created in advance and repeated, but rather the testers check the system on the fly. The tester looks at the product or explores it, with the fresh eye of a new user that will not respect the direct, clear path of using the system. A tester would try to fill in wrong data, or almost wrong data, go back and forth through the user flows, they might refresh or write really fast in some areas, or click on a button frequently, all to see what might happen and to explore if the system was taught to be resilient enough in such circumstances. Exploratory testing requires a different mindset, and it involved a lot more than what I've just stated. But there is a clear difference between checking a system based on a set of plans and checking a system by using exploratory testing.

When talking to testers who are experienced with doing exploratory testing, I have often heard that code review is a form of exploratory testing, but on the code. Furthermore, on-the-fly code review is an improved form of exploratory testing. Testers might call this format of pair programming (programmer driving + tester navigating) exploratory testing as well. It's revealing that this is the form of exploratory testing that has the fastest feedback loop of seconds or minutes.

Using exploratory testing techniques on the fly, while the programmer is writing the code, is the fastest way of minimizing the number of defects that occur when a tester is involved.

Next, we'll explore how to interact with peers who are not specifically from or understand the workings of a technical world.