The nice thing with chess is that there's no age limit and ageing is not as big of a problem as in other disciplines. I have a neighbour who is 75 and he's still chess-beating me from time to time!
I see many similarities between chess and programming.
Recently, I've been working on improving my chess to reach the next levels. At the moment I have the title of master candidate (ELO = 2140). My goal is to get to the international master level in the next 5 years.
This year, I started trainings with a professional chess trainer. I have just finished another session. Part of the lesson was very inspiring to me. It was about things that could be also applicable to programming and our "careers".
Let me share some of this with you:
It's you who must control the current chess position and not the other way round. You need to be 100% sure that you know what this position is about. There's no place for "maybe".When I heard that I immediately knew that was similar to my views about programming, especially about any kind of refactoring. There's no place for "maybe". You need to control the codebase, not the other way rounds. There's no place for "let's run it and see what happens". It's all about confidence.
The next quotes are more about the chess training, but also relate to the moment of playing the game:
Don't move the pieces on the board until you have all prepared in your mind.
You need to see the final position after each variation - you need to see what is your goal. There's no places for surprises.
Be honest with yourself - do you know everything? Do you know what's your target position? Work on it for as long as needed to be certain.
In refactoring, there are some moments when you can just be creative and move code around to see where it "fits". However, most of the time, you need to know where you're going. Why are you moving the codebase from point A to point B? What is the Z point? If you're planning a bigger change - you need to envision what's the shape of the code, after all the changes.
Motivation is a huge part of chess. The same with programming:
Simplifying it a bit - there are two ways of motivating yourself - 1. "I'm the winner", 2. "I just need to make the next good move". It's best to balance those two ways. If you're relying more on the first one - you risk losing the fun and enjoyment. If you're more into 2 then you risk not improving yourself, not having goals.
Whatever is the result of the game, you need to enjoy the process of playing. Excitement is a big part of improvement. There's no place for stress.
My chess work this year reminded me about some things that could be of use in programming:
- Programming is a long-term discipline. It's never too late to improve.
- Having a trainer/mentor/coach is super-important. They can help you track your goals, spot your weaknesses, focus on your strengths
- Set your short-term goals - what do I want to improve at *this week*?
- Set your long-term goals - where do I want to be in 5 years from now?
- The better you are, the more you enjoy what you do.
- The more confidence you acquire, the faster you are.
- Frameworks/technologies/libraries/languages - they come and go, as with some chess openings. No need to focus too much on them.
- Choose some other programmers who you want to follow, whose style fits where you want to be. I will never be Kasparov or Tal or Shirov, but they are my goals when it comes to the style of playing. The same with programming - I will never be Martin Fowler, Greg Young, Uncle Bob - but they represent the style I want to be better at.
In other news
- We've updated Developers Oriented Project Management (our book about working remotely, asynchronously and without project managers) with 40 Slack protips and 2 bonus chapters. I am sure you will find them useful.
- Responsible Rails got one new story. Robert wrote how Resque and Ruby together trolled us, leading to orphaned temporary files on utility servers. As usually there is also an advice how to avoid that kind of problems in the future by using certain coding patterns.
- I've been using mutation testing recently to cover an existing Rails application with tests. Expect more on this topic soon! Mutation testing is one of my long-term programming improvements.
