Subtitle: For doing better solo programming
This time I want to write of a big change that occurred in my way of working during this professional year.
The shift from a derived XProgramming methodology, including a strict pair programming centered way of writing code to a more common, solo programming way.
(If you don’t know what XP is or why this guy here consider it so radical and important, take a look at this)
At first I wanted to write a confrontation post between Pair and Solo with an emphasis on what is good in one against the other.
And with Mohammed Ali and Rocky Balboa pictures.
But during the writing of that first version I’ve realized that is not what one is or what the other is but actually what the first gave me of good for doing better the second.
The Truck Number
Project’s Truck Number = The number of devs that must be hit by a truck before some knowledge on the project is lost.
With pair programming (PP from now on) you, team member, after some time, are more or less the same in terms of importance of your mates.
If from one side this could sound quite depressing and demoralizing as you are not the Expert Of That Thing™ anymore (and so you cannot display any new fancy title on your LinkedIn profile) on the other it allows to delegates everything could be of your personal concern to whoever you want.
Supposing that a codebase has been fully developed in PP with pair rotation, every member of the team is able to quickly understand any part of it without reading any sort of documentation.
But this is not only related to how to write code but also to who ask for clarifications.
The guy next to you is always the right guy.
In my experience in 3 different teams working on 3 different projects using different technologies and different “visions” on how to write good code, PP helped me a lot to reach full productivity in less than 2 months.
And here for full productivity I mean being able to fully understand the business, the code visions, being able to join tactical meeting and say “can you please shut the fuck up?” to someone (in a polite way of course…).
And about the documentation, most if it was a daily journal that every couple used to write at the end of the working day.
The journal contained the outcome of the day, new ideas, plans for the day after and problems.
Of course there were some specific docs about APIs, procedures and whatever but I can say that the journal was the most important one.
I think the journal really fits with the concept of “incremental documentation for an incremental development” because it’s literally incremental documentation! Take a look at this.
So, enjoy your holidays and leave the code with the guys, they will have fun together!
Shared Codebase and the Team
I don’t know if it’s common or not to every dev to work on a codebase shared between more than 4 people.
I’m currently working on a codebase that is shared between more or less 12 devs (with some random commits from Poland or from the past) and the divisions between the teams and which codebase they touch is more than foggy, kind of shared/not shared I would say.
Is more than common when you find a piece of code that you are not suppose to touch and has not been wrote by someone in your team to just pass over it without caring, and the end is ‘ok’ to think that is not of your concern.
For peace’s sake maybe.
Pair programming showed me that when a code is shitty is shitty and you should not stay silent before it.
And you have to tell to the guy who wrote it why it’s shitty.
Because that code is also yours code, you are working on it and the results of your team depends also on that smelly crap from hell of a giant switch/case.
Simple as that.
Which means that all the team must have the shared target of improve it and improve itself as a devs team.
By studying and sharing knowledge.
Because at the end, after some time, is not only about sharing code but is about sharing successes, sharing failures, sharing skills, sharing commitment, sharing trust.
Being part of the Team.
(PS: never used Rubocop or any static code quality analyzer with PP, they are good but not really necessary with the right discipline)
From Brat to Senior
One of the best part in my opinion of PP was the mentoring.
And it’s also the one that put me in the most angry work situations ever.
Because when you have to work side by side with some fresh hired post-degree junior dev with overgeneralization and comments mania and you are the sheriff in town it’s always hard to keep your common pace slow.
But you have to, because this new kid is going to be part of your team.
And one day he will be as fast as you.
Ok, maybe this is a bit too romantic but the point is the same.
It’s just impossible to not learn something doing PP, maybe that something is not that much if you are the Senior in the pair but for sure for the other there’s no better way to grow as a developer than to be mentored in this way.
And there’s no better way to understand what are you doing as Senior than explaining it to someone.
And it’s also a great way for getting a free cake-of-gratitude-for-da-masta.
Pair Programming is tiring AF.
Because you have to deal all the time with another head, fighting sometimes, interrupt his sleep others.
And if code quality and the red-green-refactoring cycle have teached me something for sure it’s
Fuck man! Keep it simple!
Huge artifacts with absurd combinations of configurations, flavours, colors are really not necessary to the 90% of the situations.
And for the remaining 10% there’s an external module.
If I have to deal with my pair why should I lose time to implement the most complex solution, test it and fight for this stupid idea?
Probably I just need to detach from the keyboard for some minutes.
Probably I just need to kick his ass on Mortal Kombat X.
These are the results of my experience with this interesting way of doing software in team.
I don’t think is the best way ever but if you are having any kind of problems in your team related to social dynamics or knowledge sharing maybe this jabber I just wrote could be useful to you somehow.