Tips and techniques to suck at your job and blame Pair Programming
A developer pointing out something to another developer at an upside down screen
- Part 1: Pair Programming
- Part 2: How to find the best context for Pair Programming
- Part 3: The Power Of Pair Programming Lies On The Execution
- Part 4: How to do Pair Programming The Wrong Way
I have written about the abstract definition of Pair Programming, how to find the best context to apply it and tips on how to do it efficiently.
The problem is that Pair Programming relies on a mindset, and therefore many companies and teams are doomed to do it wrong without even knowing it. They hate and yell at it like kids that received a new broken toy. The purpose of this article is to sum up the most efficient ways to do Pair Programming the wrong way.
Force Pair Programming to the throat
Each individual of the team should be forced to do Pair Programming. Preferably in a predefined time where management knows it is the best time to program in pairs with lower initial time cost, like outside working time, at lunch or when somebody else doesn't have anything "better" to do.
To do it wrong, Pair Programming should be forced to the throat as much as possible, preferably when the company doesn't need to pay anyone to do it
Control and demand result ASAP
Pair Programming promises to write software faster at a lower cost. The key here is forgetting about the ramp up specific to each team and strictly measure the time in which two developers spend doing the task.
Management should make sure that the developers doing Pair Programming are mentally able to understand that the company need results and it's the company's money that is being spent. This will definitely make them much less efficient because they will be stressed with the pressure of delivering and force them to provide sub-optimal results that will confirm to management and all developers involved that Pair Programming doesn't work.
Pressure is the best way to pretend you are encouraging someone to work harder and faster
Two developers doing the job of one
It should be clear throughout the team, the company and all of its subsidiaries including partners that Pair Programming is, literally, two monkeys paid to type with no brain activity doing the job of one. Therefore, the rest of management should take great care in demanding Pair Programming only when necessary. That should be made clear through personal communication, e-mail, Skype or whatever communication medium available, preferably social networks for exposure.
Keep in mind that it's not enough to do Pair Programming wrong. Everyone need to share the crap mindset of the company and expose to the world that the culprit is Pair Programming. Always. It is never the company culture because the company culture is always perfect.
Always try to be better than your peer
Pair Programming should be the opportunity for a developer to show off their skills in using unknown features specific to the language both are working with. If the pair questions this great feature with no apparent benefit at all, call them stupid for not understanding such basic concept and praise them for being able to learn with the best developer of the country.
Never acknowledge a useful information your peer tell you. Always pretend that you knew all along and was just testing them to see if they would say it, preferably if they hold a more senior position than you.
Always pretend you know any useful information that someone tells you
Tell what to do, never ask it
Always tell the pair what to do and do not accept suggestions. You should be the one telling what to do. Always use the most complex solution to show off your amazing knowledge of the syntax of the library, framework or language both are working with.
If the pair questions the attitude, tell them that principles in software engineering are also applicable for real life. The principle you are applying by telling what to do is called Tell, Don't Ask.
Prefer pairing with beginners
Always prefer pairing with beginners over someone that knows what they are doing. If possible, scare the beginners out of how good you are so that they leave the company before they have any opportunity to take your job.
The other benefit in pairing with beginners is that for any questions they ask you can make up answers and they will never know that the answers are wrong! Never suggest for both of you to lookup on the internet for an answer to make sure, tell them that you already know the answer and therefore looking for it is losing double the company money. Tell that you two are already doing Pair Programming which is spending the company money twice, looking for unnecessary stuff will be more damaging and might get both fired. Also, tell that nobody should believe everything they see on the internet.
Assume that failing to answer a question should be considered worse than providing the wrong answer
Do not give out core business and technology information
If the pair asks for a business or technology information give it in a way it is so abstract that digging into the details will take too much time. Ask them to believe and learn with you when you tell what to do so that when they get the same problem again they will know the answer because you helped them.
Make fun of your peer
One of the best things to do is laughing off a newbie or (preferably) an experienced developer when they get something wrong.
If you have to explain something twice, laugh on the fact you are explaining twice, something you never needed to when somebody was explaining something to you (you always got it on the first explanation).
Treat Pair Programming as something fun, make fun of your peer for trying to do Pair Programming correctly
Assume everyone wants to test you
If somebody better than you technically tries to ask for help, assume they are trying to test you and it can be dangerous because they might expose you. Find excuses not to pair and instead ask them to review your code after you have made a lot of changes. When you make a lot of code changes with a lot of wrong premises, it becomes hard to be rewritten because the cost of code review is much bigger than when a problem is spotted early in pairing. Besides, if somebody suggests rethinking the architecture, you have the excuse for the managers that the “code is working” and therefore they will just have to accept your poor architecture because it’s a lot of work to change what is already "working" at the eyes of someone that is technically incapable.
Refuse any architectural or maintainability suggestion
Do not accept suggestions for improvement of the architecture and maintainability from any of your peers, unless that will make the end result of your code break something that is visible to someone technically incapable, like the management.
When your Pair suggests maintainability or architecture improvements, assume it’s only their opinion and demand being more objective on what really matters for the company, which is a "working code".
If a suggestion is only visible or understandable technically, tell to the management that the one suggesting the change is incompetent because they are making up suggestions to appear "smart" and they are using company time and money while doing that.
“Money”, “Cost” and “Loss” are very important words to shout out once in a while in the middle of pairing. Prefer bringing it when shareholders and management are near to hear it.
Take great care when doing this one because somebody else might agree with your peer and that will weaken your argument to management. One solution for this is being friends with everyone and take disagreements as an inexcusable personal attack and violation of trust.
Conclusion
The title of this article is How to do Pair Programming wrong. But honestly, with these tips, you will be doing a lot of things, except Pair Programming.
None of this is even close to what Pair Programming is, but sadly there are many companies and teams that insist on doing in a similar way. Fortunately, they are doomed to fail permanently and be out of the market soon. But if you as a developer keep working with those companies and don't start to look somewhere else to work, they will not be out of the market and will be kept alive in an almost-dying state to foster this kind of poisonous mindset for the time to come.
Do a better thing for yourself and your career and stay away from people that think like this.
Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook or Github.