Developing developers and continuous learning
Programming is easy
Unfortunately, programming is not a natural skill. One can't help but wonder if it is because humans invented both computers and programming languages. No one is born to be good at programming. Getting good takes a lot of practice.
This text exposes how we at Parakey try to learn and improve our skillset as developers and become great at programming and working as a team.
Reading is an excellent habit for learning new techniques and ideas. Every developer should probably read more books than they are doing. So how can your team (and company) help and encourage this habit?
Starting a book circle is one way and something we have been doing to great success for a couple of years now.
Once a week, we discuss for 30 minutes a chapter in a book we have read. Reading the pages during work hours is encouraged, and one can also join the discussion without reading the chapter (but one should then read it retroactively so as not to fall behind). The book circle is where many conversations occur about how we work and how we can improve.
We try to choose books on relevant and related topics to our current workflow and domain. For example, we wanted to improve our user stories and planning, so we read User Stories Applied.
Mob programming code-katas
Sometimes it can be fun to go a little crazy and write some code just for learning purposes and then throw it away without remorse when the time is up. That, my friends, is what a code kata is.
Once every second week, we take a code kata problem, pick a programming language, and attempt to solve it using mob programming.
During the mob programming session, the focus is on learning only. We do all our katas using TDD (Test-Driven Development). It gives people who are unfamiliar with TDD a safe space to practice. Sometimes it can be fun to add constraints on the solution like no/minimal mutation or using recursion.
We have a dedicated pair programming station equipped with two chairs and a big screen to make it easy to engage in a pair programming session. Pair programming is a great way to share knowledge and help your colleagues.
Pair programming is not mandatory, only encouraged. It's important to realize that sometimes people like to work on their stuff and not worry about another person. Also, not all tasks are efficient for pairing.
All code goes through a code review before being merged into the main branch. The review is an excellent chance to keep your colleagues up to date on your work and get a fresh perspective.
Code reviews before merging have downsides. Getting feedback can be slow. We try to mitigate this by keeping our pull request small and doing a live review when the issues become non-trivial.
Live reviews can be spontaneous, asking if they have time to talk and then work through the problem. Or, book a time for it if you know beforehand that you want to go through the code live and discuss your solution with someone.