DEV Community: Riya Dattani

Deep dive into pair programming

Riya Dattani — Thu, 13 Mar 2025 13:57:15 +0000

Before I switched careers into software development, I didn't have a clue of what a complex system looked like, how they are created and the effort spent building them. I had a misconception that programmers spent a lot of time writing code independently. When I started learning how to code and speaking to developers about their experiences, I was quite astonished at the collaborative culture within software development. In my job, I continually interact with other developers, the product owner, the UX/UI designers and sometimes the stakeholders of the product we are working to build. I am encouraged to not only share my thoughts on technical aspects, but on UX/UI prototypes and on the value of the features we are building for our users. My role as a software developer is much more than just coding. In this blog however, I want to focus on how developers collaborate through pair programming.

Pair programming

Pair programming is where two developers work together to solve a problem. Whilst there are advantages to pairing most of the time, I think there are some occasions when it is better to work individually.

When it is suitable to pair? Well, it depends on what the specific task entails. Is it a laborious task of deleting dead code or is it a new search feature? There are some tasks that are just not worth the time of two developers. One of the developers is likely to sit and stare at the screen watching the other developer continue with the task. I put together a non-exhaustive list of questions that I would ask myself to determine if its worth pairing or not:

Is it beneficial for another member of the team to have context of the code that will be added (or refactored)? Knowledge sharing is encouraged so that every developer is familiar with the entire code base and is comfortable enough to pick up any ticket on the board.
Is this a learning opportunity for another developer? The work may not be something new and shiny but say you had a new joiner and you were touching some part of the code that would help them understand the project better.
Can the work be broken down into extremely small tasks where it makes sense to divide and conquer rather than pair? For example, it might make more sense to divide a bunch of small UI tweaks if they are relatively straight forward.
Is this a growth opportunity for a budding developer to work on a task individually? It is liberating and exciting for a novice to tackle a challenging task themselves. It is an opportunity for them to make mistakes, learn about their thought process when analysing a technical problem and get feedback on their work.
Are you in the mood to pair? This is a tough one because it is so subjective. Some developers would love to just plug in their headphones and get on with their task. Some need a social break because pairing can be extremely exhausting since you have to communicate for long periods of time over difficult code stuff. Pairing contributes to overall productivity but up to a certain point. I think you can experience diminishing returns when it becomes tiring and you cannot optimally contribute. I think most people can sense when this happens and they should just be honest about wanting to branch off and work on something solo.

Types of pair programming:

1. Driver-navigator

This is a classic pair programming style. One developer is the person on the wheel (i.e. keyboard) and their role is to type code. The other acts as the "observer" and their role is to review the code on-the-go and navigate the driver on what to code. This exercise should involve the navigator explaining how they plan to solve a problem and prompt the driver to codify that idea. The navigator should avoid dictating the code word for word to the driver. I think this pairing practice is useful when a more experienced developer is coaching another developer on how to code.

In my opinion, 20 minutes or less is a reasonable amount of time to write some useful code. These short sessions encourage developers to make small, iterative changes because you would ideally want to integrate that code often. Switching between the two roles is important because the perspective on the code is different. The drivers job is to think about the nitty gritty of the code at hand. The navigator can think more strategically about the bigger picture such as potential obstacles that might arise.

The key to pairing is to switch roles frequently.

In practice, these guidelines are not always strictly followed. There have been a number of times in my own experience where a developer and I have not switched roles for an hour or even more sometimes. Those sessions drained us and rendered us unmotivated. Ultimately, since the work still needs to be done, the solution is less thought through and important steps such as refactoring could be missed out of laziness. Switching roles increases the participation from each developer and thus the energy levels.

2. Ping pong

Ping pong pair programming is a fun way to program and it revolves around writing tests. In this style, developer X writes a test and developer Y writes the code to pass that test. Developer Y then writes the next test and developer X has to write the code to pass the test. This is a great technique because you are following Test Driven Development (TDD). TDD is a whole other topic in itself but, writing tests that reflect the desired behaviour is a good tool to design good, modular software. Read this post written by my colleague if you are interested in a convincing article about TDD.

This is my favourite pairing style. A major plus point is that the developer writing the test is focusing on writing a useful test without the solution in mind because the solution will be implemented by their pairing partner. This leads to clear, understandable tests and therefore a good chance of well-designed production code. I like how the code can evolve in an unexpected way when bouncing off each other's code and tests.

The well-known TDD steps should be followed:

Red: write a failing test
Green: write the minimum amount of code to pass the test
Refactor: refactor the code to improve your solution

One of the important steps to remember is the refactoring stage because it is your moment to design well! You have reliable tests and working software so refactoring should only improve the quality of your code (if done correctly of course). Can you spot a pattern in your code? Can you extract some code to make it more readable? Are you injecting dependencies in a function or a class? Are you following SOLID principles?

3. Diverge-converge

This is not a very well-known technique but it is something I picked up whilst I was at a coding bootcamp. This technique involves two developers diverging out on their own to figure out how they would solve a problem and then converging back together to discuss and decide what they will implement. I think this technique useful when there is not a concrete plan on how to make something work. This method is suitable if the task requires a lot of research or reading through documentation which is more efficiently done solo rather than in a pair. The developers could perform a spike to see if their solution actually works (a spike is experimenting/exploring with some code). However, once you figure out something viable, it is important to bin all that code and start again using TDD.

Before and after pairing

There are different pair programming methods to code together. But when picking up a task, there are other important ceremonies before and after coding.

Kick-off: Fully understand the use case by fleshing it out with the rest of the team including any non-devs that can provide more context. I find breaking down the scenarios into a test case structure e.g. "given, when, then" is quite helpful. Think about any dependencies you may have beforehand e.g. how are you going to integrate with an external service?
Start pair programming
Definition of done: Once you finish a story, run through a sanity checklist (approved by the team) to determine if you have sufficiently done the task to an agreed standard with your pairing partner.

Silos

We talked about how developers can work together but I think it's interesting to note why working in silos can damage overall output.

A developer can be shoehorned into building one specific part of the system just because they are most familiar with it. What happens when they leave or are on holiday for an extended period of time? Other team members are likely to take a long time to familiarise themselves with the code and question some decisions (especially if they are not documented).
A developer can miss out on instant feedback and may need to wait for a pull request (PR) review depending on the teams workflow. Having another pair of eyes providing instant feedback and understanding the thought process is more efficient than reading a PR and requesting changes (and then reviewing subsequent changes on top of that). In fact through pairing, there would not be a need to raise a PR since your pairing partner has worked on the code with you. If you pair regularly and trust the developers on your team, why not consider trunk-based development? Make small iterative changes and really practice continuous integration by working on the most recent codebase.
Two heads are better than one. To design code that is sustainable, scaleable and all the lovely things developers want, you need to think about it. Discussing ideas, possibilities and architecture with another developer usually always produces a better outcome.

Benefits of pair programming

Knowledge sharing. Mitigating knowledge gaps leads to better decision making, increases the ability to work smarter and faster as a team and increases engagement.
Coaching and mentoring opportunities. More experienced developers have a chance to nurture less experienced developers and hone in on their coaching or teaching skills.
Increased communication. It is an opportunity to ask questions and discuss the reasoning behind the code. If you can explain the code to another developer well, it probably makes sense. If you can explain the code to a non-techie, then you are definitely doing something right - it's a very useful skill to explain code in lament terms.
Create and build relationships with other developers. You are likely to talk about other non-work related things and connect with your colleagues on a deeper level. Having this strong synergy and an open, comfortable relationship within a team will foster a fun culture where people enjoy coming to work, trust each other and thus accelerate productivity.

Overall, I think pair programming can be quite enjoyable if done correctly. Here are my top tips to pairing:

Don't hog the keyboard. Switch roles often and work in small steps. Maybe try to use the Pomodoro technique?
Take breaks! Thinking, talking and typing can get exhausting so it's refreshing to take frequent short breaks.
Are you in a "pairing mood"? If not, be honest about it and maybe work on something that can be done by yourself for a while.
Rotate the pairs. Anchor a story to one developer but change their pair partner everyday. This spreads knowledge and forces the developer anchored to the story to reevaluate and reinforce their decisions by explaining them again.

Riya xo

IntelliJ Shortcuts (for Mac)

Riya Dattani — Mon, 09 Dec 2024 10:49:24 +0000

Be an expert at using your tools so you can concentrate on solving problems! I couldn't find a short and practical IntelliJ shortcuts cheat sheet, so here are the ones I generally use, categorised by activity.

The OG shortcuts

SHIFT + SHIFT - the IntelliJ search for anything including files, actions, symbols etc... press tab to be more specific.
OPTION + ENTER - gives you a list of things you can do depending on where you are. For example, if you are in the middle of an argument list you can put all arguments in one line or multiple lines or add the argument names. This is one example of MANY. Just keep pressing it.
CMD + SHIFT + V - a log of all the recent things in your clipboard (this is interestingly one of the most useful things).

Navigating the code

Hopping around the codebase to follow a trail is probably what you spend a lot of your time doing. You
might as well be super efficient at it!

CMD + B - declarations of the variable/function
CMD + OPTION + B - implementations of the interface/function
CMD + U - go UP to the interface it implements
CMD + E - got to recent files
F2 - go to next error
CMD + 1 - view project sidebar
CMD + [ - back
CMD + ] - forward
CMD + F12 - view the structure of the file
CMD + SHIFT + BACKSPACE - go to the last edited bit of code
CTRL + SHIFT + DOWN/UP KEY - hop down or up the methods in the file
CMD + UP - navigate up the hierarchy
CMD + , - IntelliJ settings
OPTION + F12 - go to terminal
CMD + W - close tab

Refactoring

Ninja developer level.

OPTION + T - when your cursor is on the function, this shortcut will give you a menu of what you can do (some of the most common ones are listed below)
CMD + SHIFT + V - extract to a variable
CMD + SHIFT + N - inline variable
CMD + SHIFT + M - extract to a method
CMD + F6 - change signature of the function (it will automatically update it everywhere it's used)
SHIFT + F6 - rename variable
F6 - move class/interface/function to a different file
CTRL + OPTION + O - (not zero but the letter "O") to optimise imports
CMD + SHIFT + DOWN - when your cursor is on the name of the function/class, use this to move the whole block
CMD + SHIFT + ENTER - IntelliJ will autocomplete the block like "if" or "when"
CMD + OPTION + SHIFT + L - reformat the whole file
OPTION + OPTION + DOWN KEY - multiple curses in the same location on the next line
OPTION + UP/DOWN KEY - Expand/shrink highlighted code within bounded contexts
CMD + SHIFT + F - find all
CMD + SHIFT + R - replace all
CTRL + G - highlight text and use this shortcut, it will find the next bit that matches that code one by one with a cursor and then you can edit it

Tests

CMD + R - re-run the previous test
CMD + SHIFT + R - run the test your cursor is on
CMD + N - in the test class, this shortcut will provide you with a menu of options to create test/setup/teardown func
CMD + SHIFT + D - debug the test you are on

Actions

CMD + SHIFT + A - the ultimate shortcut to access the IntelliJ action window. Once you are here you can search for any action you want to do. Here are some of the ones I use:

Enable soft-wrap
Split screen and move right
Open blank diff window
Zoom

Git

CMD + T - git stash, git rebase/merge, git pop - done automatically
CMD + OPTION + N - when you are on the git window, use this shortcut to create a branch
CMD + K - commit
CMD + SHIFT + K - push

Create your own

Templates

You can do magic. You can create templates linked to particular words. For example, you can configure IntelliJ to spit out this code when you write the word "test":

@Test
fun `$NAME$`() {
    $END$
}

The cursor will automatically be at $NAME$ so you can immediately type out the name. When you press enter, the cursor jumps to $END$ which will allow you to land in the right place to write your test.

P.s. this particular helper already exists in IntelliJ (listed above). Within a test class, use CMD + N and a list of options will pop up to create a test / set up / tear down func.

Settings -> Editor -> Live templates -> Kotlin (for example) -> Add a template

Keyboard shortcuts

Settings -> Keymap - this is tricky because there could be clashes with other MAC/IntelliJ shortcuts

Practice makes perfect

Refactoring golf is a fun exercise to practice!

Bonus - Google Chrome shortcuts

CMD + T - new tab
CMD + SHIFT + T - re-open closed tab
CMD + [ - back
CMD + ] - forward
CTRL + TAB - hop to next tab
CMD + W - close tab
CMD + N - new Chrome window
CMD + BACKTICK - tab to other Chrome window
F12 - open developer tools
CMD + TAB - go to different application

If you know any other exciting shortcuts, leave a comment.

My journey to writing my blog in Go

Riya Dattani — Wed, 14 Apr 2021 18:12:09 +0000

Originally posted on www.riyadattani.com

I built my blog (www.riyadattani.com) from scratch, without a blog engine. I used Go to build it and some html + css to make it look pretty.
This is my first personal project in Go, in fact, its my first personal project on a live
website. Tweet me if you have any feedback whether its kind, mean or funny!

So I made the decision to make a blog in Go because it was different language to what I normally use at work (Node) and
when I was introduced to it, it felt fun and simple.

First attempt

Once the decision was made, the question was where do I begin? I surfed the web and looked for other desirable blogs. I gathered a list of my favourite features and thought I would figure out a way to replicate them. I wanted very cool
features like an animated background and an interactive interface such as a built in game. These features sounded
fabulous but in reality, they were a nice-to-have rather than necessary. Frankly, the more I thought about what my blog
should look like, the more I ventured further away from the purpose of the blog: to share articles. "Agile" developers
would say I envisioned a shiny gold standard website rather than a MVP (Minimum Viable Product).

I started building the Hello World version of my site and I cheated a little by not writing any tests. Not very long after, I frantically searched for tutorials to get me these fancy features. I was directed to multiple plugins, I
read a lot of stack overflow and I spent most of my time searching for resources on google rather than coding... I
eventually got frustrated. Naturally, I didn't want to open the project anymore because I didn't really know what to do
and where to start.

I needed to go back to the basics and start simple.

On a fine Hackday, I was experimenting with Hotwire and Go with my colleagues. We built a simple todo list app with
basic CRUD functionality. Thanks to the fast, non-hassle set up to get a website up and running in Go, once the bare
bones were wired up, we iteratively fleshed out all the routes and basically built the app in a day. The simplicity
inspired me to start building my blog again. The process felt easy, simple and doable. I wanted to restart building it
using the same strategy and foundation.

Second attempt

Before my second attempt, I reflected on my previous approach/process and learned from my mistakes. Here were my
learnings:

Remember the purpose of what I am trying to build. As a programmer, we should focus on WHAT, WHY and HOW we are
going to solve a specific problem.
- What: I want to build a blog where I can share articles of topics that I am interested in and I am learning about.
- Why: I want to build a network and connect with people who have similar interests, share knowledge that other people might find useful and practice communicating through writing effectively.
- How: I made a decision to not use a blog engine and to build the blog from scratch in Go in an iterative way. Whilst a blog engine would easily achieve my goals, I would not have gained this invaluable learning experience.
Decide on the MVP: I wrote down 2 features which I think I need for my blog to be functional.
- A home page which has a list of my blogs in descending order by date.
- The blogs are links that open up on a separate page.
Write tests or you will regret it in the future.
- Go through Learn Go With Tests to learn how to test the code correctly in Go.
- What would be included in my acceptance test? Do I need one?
Have a process and develop it to be more systematic.
- Github Issues: I used these to keep a backlog of tasks, bugs and general thoughts that need doing especially when they crop up in the middle of something else.
- Continuous Integration:
  - I tried to apply some processes from work to make it as easy as possible to continuously integrate my code to the live site. I created a github action that builds and deploys the code, every time I push to master. I always work on master.
  - I took this opportunity to learn more about docker. I used docker to build my code in a container and this is used by Heroku when deploying my site.
Don't bother following a tutorial. Figure out what you want to build in the simplest way possible. I started with a
hard coded blog list on the site and then aimed to replace it with non-hard coded blogs.

In retrospect, I would have still done things differently if I took another shot at creating this blog again. I guess
that's the best (or worst) thing about software development - nothing is perfect and there is always room to improve.
Looking back at my second attempt at building this blog, here is what I would've done differently:

TDD it. No, I mean actually TDD it. Yes, I realised that writing no tests would hurt me in the future and make me less confident in my code, but I still did not strictly follow TDD. I added a couple of tests with respect to my router after writing it up and I realised I probably would've created a better solution if I had tested it first.
Don't get obsessed over the CSS - this can be done over time. The perfectionist in me was running around in circles. Instead of focusing on the most important task, I wanted to make the site look pixel perfect.
Get feedback on the code and the design as soon as possible.

In hindsight, building this blog has been a fantastic learning experience! I felt technically challenged and I learned about the process of creating a website from scratch to live.