Today was mainly spent making the changes recommended in my IPM to my Tic Tac Toe. It’s hard sometimes when working on something on your own to spot the errors that someone else so easily can.

I’ve been feeling recently that, although I think I understand the SOLID principles and I think I have a grasp on design patterns and when to use them, I’m not sure whether I’m applying them to my code. If I’m faced with a SOLID violation within my code, I’m not completley sure that I can spot it straight away. When someone points it out to me, I can see it and usually know how to fix it, but I don’t want to need someone to have to point it out to me.

I know that this comes with practice, but sometimes I feel as if I’m simply delivering working code, when what I want to deliver is working, clean code. So how can I fix this? Firstly, I want to make sure that I understand the SOLID principles fully. Doing my blog post on dependency inversion and writing out examples of DIP violations and how to fix them really deepened my understanding of the principle, so I am going to commit to do the same for the rest of the SOLID principles. I would also like to write blog posts on design patterns, so that I can ensure I understand them and, more importantly, when to use them. Secondly, I need to practice more. When I work on a project I know that my desire to write clean code is always at the back of my mind. I need to try to bring it to the forefront. I need to force myself with each change I make to consider whether my code is SOLID and how I could improve it. I feel as if currently I am still in the mindset of just wanting my code to work and then considering whether my code is clean or not. Forcing myself to consider how to improve my code at every change, using the red, green, refactor loop properly, will make sure that it becomes second nature, and improve the quality of my code.

It feels good to have an action plan, and also a little more structure for some upcoming blog posts. I don’t think I’ll be getting each one up every day, because I find writing examples quite difficult, but hopefully I will be able to cover at least the SOLID principles over the next couple of weeks.

In the meantime, what did I learn today? Well, I heard a very interesting talk about pairing. I haven’t been pairing that much at the moment, which is not good for a few reasons. The first is that I miss it. I love pairing. It’s fun to work on a problem with someone else. There are so many possibilities for learning. You can learn a new approach to a problem, learn a new shortcut, learn another way to do something, a feature of a language that you didn’t know about, and you can get your pair to explain anything you don’t understand. Pairing is great. The second reason a lack of pairing is an issue is because pairing takes practice. The talk reminded me how hard pairing can be. It can be exhausting, working so intensely with another person. It really forces you to improve how you communicate your ideas, how to communicate when you don’t understand, and how to explain a problem to another person. Another feature of pairing that requires practice is learning to be ok with making mistakes infront of someone, and accepting mistakes made by others.

When you pair with another person, there is, of course, a sense that you don’t want to look like an idiot. There is also the knowledge that, at some point, you will probably make a mistake. It might be a mistake in your approach, it could be a mistake in your logic, it might be a typo or a forgotten bracket. I think you always will make a mistake, and learning to be fine with that takes practice. Making mistakes when your on your own is fine. You can fix it and no one will every know it happened. Making a mistake in a pair has a witness. And that’s great. You have someone who is working towards the same goal as you, who is going to help you fix your mistake. They’re not going to think you’re an idiot. A pair is a team, and everyone knows mistakes happen.

What can happen when you haven’t paired for a while, or perhaps have never paired, is that this fear of making an error infront of a colleague or peer leads you to dread pairing. I want to avoid this. It can be nerve-wracking to pair with someone who you haven’t paired with before, or with someone who you feel is much more experienced than you, because there is a feeling that you want to impress them. This, I think, is irrelevent to pairing. I think the key to pairing well, which was reinforced by the talk, is that you and your pair become a team and work on the project as that team. So in this context a mistake is not an individual’s error. It is something to be solved together so that the project can move forward, which just confirms that pairing isn’t scary at all.

So there’s a little ramble about how much and why I love pairing, and why I’m going to try to do it more.