John Dobie

Principal Java Consultant and Engineer, London.

Tips For Remote Pair Programming

I’ve been pair programming on a weekly if not a daily basis for nearly two decades.

In essence, it is a simple practice where two or more developers sit down and write some code together.

Over the last decade though, I have been increasingly leading remote teams which are split across the globe, across the country or who are just spending more time working from home.

This means you have to practice remote pair programming instead.

In these days of enforced remote working and remote onboarding, I thought a few practical tips might help those new to the practice of remote pair programming.

Pair Programming

I first came across pair programming in the extreme programming era.

Despite it being a simple practice, I never took to it right away. That was because I tried to use it for everything.

Fortunately, I quickly realised that this might not be the correct approach for the teams I was working in. We experimented and found that it added the most value in a number of specific circumstances.

As well as being great for building the very difficult parts of a system, it was found to be extremely effective in the onboarding of new members of the team.

At the moment, there are lots of people currently forced to onboard remotely. It’s really, really hard to onboard remotely, especially if there is a large codebase.

That is where remote pair programming can help.

Remote Pair Programming.

Remote pair programming is again, a simple practice where two or more developers sit down and write some code together.

The big difference is that you can do it from anywhere on the planet.

For remote pair programming to work, you only need to be able to communicate clearly about the code you want to discuss.

In practice, this just requires a decent internet connection and some simple software.

Remote Pairing Tips

1. Only simple software is required.

There are lots of goods tools around for remote pair programming but essentially you only need 2 things

  • A screen share to see the code
  • A decent voice connection.

As long as you can hear each other clearly and both clearly see what code is being discussed, your good to pair.

There are some great tools which certainly add to the experience, however you only need the above to start.

2. If you don’t have the above, don’t bother!

I hope this one is pretty self-explanatory. If you can’t see and hear what each other is doing, you can’t possibly expect a remote pair programming session to go well.

Do not try this with bad tools or a bad connection – life is too short.

3. Follow the rules for remote meetings.

A remote coding session is very much like a remote meeting, so treat it as such.

In the same way as you would with a remote meeting, make sure that you schedule your session well in advance and ensure that there is a defined agenda. Make it clear what you will be covering in the session.

It’s then up to you to make sure you join on-time and ensure you are somewhere quiet where the meeting won’t get disturbed. Remember your going to be on speaker most of the time.

4. Integrate code often so you can swap roles.

You won’t be able to swap “Drivers” when doing remote pairing unless you are on the same code. So you are going to have to check-in and push your changes frequently. The other pair can then pull those changes and you can swap roles.

TDD is really important for this. To make things crystal clear, you may also have to do a few more steps than would be necessary when not pairing. You want to make sure whatever is vocalising in your head, is clear to the other person.

5. Use Feature Flags

If you are making a large fundamental change or a change to a delicate area of code, the use of feature flags can really help. Just add a simple toggle to turn the feature on or off. That way, you can’t really break anything.

6. Do some prep

It can be painful to be part of a pairing session where the driver is jumping all over the place to remember how things work.

So do yourself a favour and spend a little time thinking about what areas you might touch upon and spend some time familiarising yourself with that area.

Get yourself set up with the correct source checked out and built, key files loaded in your IDE and have any relevant documents open etc.

This will make everything much easier and It’ll also make you look good.

7. Keep it to one screen.

This one is just a preference. I just feel it’s much easier on the viewers if you keep the screen share to one screen.

If you then just have a couple of apps open – say your IDE and a shell for your build, its much clearer and easier to focus on the session.

8. Make it social.

One of the best things about pair programming is that it’s social. Quite often when sitting together you might go get a coffee together before you start and have a bit of a chat. If its someone you don’t know, its a great opportunity to find out about them. If it’s one of your closer teammates, it’s a great time to catch up a little.

It’s never going to be the same remotely but it is still a good time to have a chat and bond a little.

Wrap up

Every team will find their own best way of remote working and it will take some time. I hope that you might save time in finding your rhythm by following some of the tips above.


Full-Cycle – Time to drop the Ops in DevOps?

Full-Cycle Teams

When I first started as a developer, everyone was a “full-cycle[1]” developer. You did the front end; you did the back end; you did the database; you released to production; you owned the production support.

This was known as Dev, and everyone worked that way, even if it was pretty poor compared to what we do now.

Over the years, each of the above tasks has become increasingly complex. The gap between each of these activities has widened and specialisations have emerged. This has led to some of the above tasks no longer being considered part of the standard development cycle. Many of these tasks now come under the purview of DevOps.

The Rise of DevOps

The rise of DevOps has finally brought focus to all activities across the whole SDLC. It is clear that there are benefits to returning to what Netflix label “full-cycle” when you look at things this way. Once again teams cover both the Dev and DevOps side of things and manage everything including production. By embracing DevOps to such an extent, all of these activities just becomes part of Dev again. This is the full-cycle way.

Supporting The Team

However, if that is to be done, the team need to be given the time and support to allow them to do a successful job.

The first problem is always the tooling and the skills required to use that tooling. Building and supporting a production system requires skills beyond that simply required to build the UI and Services. Nowadays you often need a good knowledge of pipelines, containers and infrastructure and getting that knowledge is not easy.

Building The Pipeline

As with all difficult things, the best way to deal with them is to do them every day. For me, building and owning your pipeline is the first step in that journey. By owning the pipeline you have to understand the complete journey that all of your deployment artifacts take before being built and deployed to an environment.

There are always problems in pre-prod environments, and by having to deal with them daily ensures that you fully understand the pipeline. You are also more likely to fully automate if you have to use something every day. That’s where integrations into your other tooling such as slack or custom bots can also off payoff.

Monitoring, Alerting and Logging

Once you’ve built your new system, you are going to have to look after it. The best way to do this is to make sure you build in the Monitoring, Logging and Alerting (MLA) capabilities that you need, right from the start. I cannot stress highly enough how important it is going to be to take a look at a dashboard and see exactly what is going on with your application. You might not get to a single pane view of your entire system from front to back but you must have a simple capability of viewing its overall operation. If you cannot do that, you cannot effectively support your system.

There are many great tools to help with this in a Microservice environment. But there’s a good chance that your Microservices are not generally going to be the problem. It’s often the case that it’s a downstream system that causes the issue. With decent MLA in place, you can pinpoint the exact system causing the issue even when it’s not one you’ve built. Then with some simple synthetic tests in place, the whole incident can be sorted without involving a million unnecessary people. The tests return to green, and all will be well in the world.

Production Support Tickets

So you’ve got your skills, tooling and MLA all sorted – what’s next?

Well, possibly the biggest mindset challenge for teams is the change to treating production support issues as day to day work. In general, people see production issues as either red or green. Production is red if it’s on fire and it requires immediate treatment. Otherwise, production is green and can be ignored until someone else sorts it out. That’s really not going to fly with full-cycle.

Production support issues need to come into the team’s backlog and be prioritised and worked on exactly the same as every other piece of work. This may require a piece of custom tooling to link production support ticketing and day to day tooling. Then it can all be easily managed as the same work. It is also essential that it is dealt with on a daily basis and by the whole team.

Full-Cycle Is Intense!

Full-cycle is pretty intense – especially when combined with out of hours support. It can take a toll on a team, leading to burnout and higher turnover. By putting the right strategies and incentives in place, you can mitigate the chance of this and keep everyone happy.

Is Full-Cycle For You?

After reading all this you might be thinking, “this is not for me!”. That might very well be the case. In the same way that there are pros and cons for full-stack, there are tradeoffs that you have to consider when for full-cycle. Some devs just want to do dev. When hiring, just make sure you get people that are really bought into the idea.

Whilst it may not be for everyone, for curious individuals who like being in charge of their own destiny, full-cycle is the ultimate way to work.


[1] Netflix – Operate what you own.

Full-Stack – Developers are not fungible.

Going back a decade or two, developers were typically considered as fungible.  There was a misconception that you could take any developer and replace them with any other; the same as you could with a pound coin.  Obviously, it was nonsense, but more than a few people have ended up in the wrong team because of this.

You’d imagine that kind of thinking would be long gone. But I still hear it from time to time, sadly.

What is a Dev?

What is a dev? I’m going to massively simplify things here and describe a dev as someone with a “particular set of skills” in a defined range of tools and languages. That’s generally how hiring is initiated. A list of the skills required is converted into a job advertisement, and candidates with those skills apply for that job.

Developers are not fungible

So if it were that simple we could simply hire the first person that matched your job advertisement right? And yet no one does that. That’s because we implicitly know that it’s not all about the skills. It’s about their attitude; it’s about their personality; it’s about their history. People are much, much more than the set of skills that they possess.

Not Fungible


Full-Stack is a rough term used to describe someone who is equally comfortable doing both the front end and server-side development.  In truth, very few people are equally comfortable with both, and they tend to be stronger in one area or the other.  However, if they can pitch in with both activities, it provides much greater flexibility in terms of planning.

“Full-Stack” is the new fungible.  Again, there is the misconception that anyone full-stack can do any full-stack job and that they will do both jobs as well as a specialist.  Obviously, this is also nonsense, because there are many stacks, they are complex and they differ enormously. 

It’s a massive leap for a full-stack C# and PHP Developer to jump into a full-stack role using HTML and Java. And it’s even harder for a developer to move from a standard monolithic stack to a cloud-based stack.  Full-Stack does is not always equal to full-stack.

That’s not to say a full-stack developer in one stack couldn’t do the role of another – good people are good people. If this is a long term hire and there is no urgency, this could be fine. But if you are hiring for a project that requires urgent delivery, you need to hire someone with the same skills that the project is using.  Even in teams that use identical stacks, there will be differences in the ways of working.  But this gives you the best chance of finding someone who can hit the ground running.

Why hire full-stack?

Full-Stack is popular because in terms of planning it creates the most flexible teams. It means anyone can pick up any task that needs doing.

However, it does come at a cost. In some cases there can be an order of magnitude difference in the time it takes a full-stack developer to complete a piece of work over a specialist in that area. There may also be complex design or coding issues that require a specialist to design or unblock and they can be beyond the skills of someone full-stack.

Full-Stack vs Specialist

Hiring full-stack requires a long term investment in people.  They need to develop both the technical skills required to build the software and the knowledge of how that software works.  This is difficult enough when only dealing with one discipline. Learning it front and back will take longer.

I’ve done a combination of roles; full-stack developer; a specialist in a larger team of specialists; in teams which had both. None was particularly better than the other.

It really depends on how fast you need to go, how the split of the work looks and what your long term aims are for the team.

John Dobie.

Smashing Iteration Zero

Iteration Zero is your chance to set up your project for success before the mayhem starts.

By building a “walking skeleton”, you can do this right from the start.


I find that iteration zero is a very rewarding time in a project. It’s a good time to bond with a new team and to get things done that literally aren’t on a schedule.

When talking about iteration zero, people tend to concentrate on the project side of things. Instead, I will concentrate on the build tasks and show how you can use the “dancing skeleton” pattern to make sure you start that you start your build in the right way.

Doing The Right Thing From the Start.

I’m a big fan of the principles behind initiatives like the 12-factor app, or the AWS well-architected framework. Their checklists and principles try to make it easy to make sure you’re doing the right thing.

They’re a little more detailed for our iteration zero purposes but there will be some overlap. For now, we just want to get the basics down.

The Walking Skeleton.

So where do we start? Well for me the main aim is to get a “walking skeleton” moving. That is a thin slice of the application deployed to a dev environment.

It might something as simple as a “Hello World Microservice”. But to get there, you will need all of the following.

  • A Repo for your code.
  • An environment to run that code.
  • A Pipeline to deploy your code.
  • Different style tests running.

Indirectly this will involve you considering the following

  • Configuration of the application.
  • What frameworks to use.
  • Choosing a branching strategy
  • Working out your monitoring, logging and alerting (mla)
  • Chat channels, distribution lists etc
  • ….. etc etc

By following the simple process of building this thin piece of functionality it will force you to address most of the common issues you are likely to come across in the wider build.

Everything will become more complex as you move towards a production environment, but by having your walking skeleton you will be in a good place.

Making your skeleton dance.

So you’ve got your application building and deploying to your dev environment. What’s next?

That’s easy, it’s time to make your skeleton dance into production.

I’ll leave the master of patterns, Dan North, to explain this.

Dancing Skeleton Pattern – Dan North.


Git Info Endpoint in Spring Boot

It’s really useful to have a simple way of seeing what code you have deployed.

Any Spring Boot application can add a simple git info endpoint using out-of-the-box actuator functionality and a simple maven plugin.

This allows you to do a simple curl on a URL and see exactly what version of your code is running by exposing the git info.

Step 1 – Create a Simple Spring Boot Application

The following command will use the spring initializer project to create a new spring boot application and place it in the /springboot directory.

curl -G -d dependencies=web,actuator -d baseDir=springboot -d groupId=com.sdbc | tar -xzvf -

Step 2 – Create your git repo

Run the following command to set up your git repo

cd springboot
git init
git add --all
git commit -m "initial code"
git remote add origin ./.git    # keep it all local

This will look as follows.

This enables the plugin to pull back the git info for the project.

Step 3 – Add the Maven plugin

Add the following plugin to your pom.xml.


The plugin will automatically add the build information to a file in the target/classes folder when you build your code.

Run the following command and then check the properties.

mvn clean install
Properties File Location

This contains all of the following information.

For full details on the plugin see the references below.

Step 4 – Expose the information.

By default, a Spring Boot application hides the info actuator endpoint. We generally change this in properties. But for this blog, we will just pass it as a property when running the application.

Start the application as below.

mvn spring-boot:run

You can then hit the endpoint in the browser.


git info exposed

Check the reference on the plugin to see how you can customise this information.


Metrics For Leading Remote Teams.

Looking After Your Team

If the last year has taught us anything, it’s that we need to look after each other.

That’s particularly difficult when you work remotely and never see each other face to face.

This post will explain how as a tech lead you can use some simple metrics to help spot when your remote team might need a helping hand.

The Tech Lead (or other)

As a tech lead, you are uniquely placed to make sure that everyone in your team is comfortable in what they are doing. Part of your day-to-day is to track what everyone on the team is doing and to help them get it done.

In the office that’s easy. You have regular chats where problems are discussed and additionally, you can easily spot any negative body language. It’s normally then a case of getting to the bottom of the issue and sorting it out. That’s just a given.

But how do you do that when you are remote working and never see each other face to face? It’s much, much harder to get that nuance from any kind of video call. I also think people are less likely to open up as they would in the office over a call.

Communication is always a tech lead’s go-to for supporting their team. But when that is difficult, you can look at some key metrics for making things easier for your team.

Using Metrics.

These are just simple measurements that anyone can look at to see what’s going on in a team without impacting the team.

You probably look at these already – you might just need to look more often.

They should only be used as common-sense measures to see if you need to focus more on helping in that area.

Number of Meetings Per Day

The number of meetings per day can affect a whole team or just certain members of a team who have ended up being drawn into too many things. But it’s definitely a metric you need to reduce.

In the office, it’s easy to see when people are away – when working remotely you need to check your team’s calendars to make sure your team is not spending too much time in meetings.

If they are constantly swamped then this is my simple take on meetings for a development team.

Unless your job is defined as “to be in meetings all day”, then if you are in meetings all day, your obviously not doing your job!


And yet, this happens all the time – especially at the start of projects.

So to reduce the number of meetings per day – just block out the team’s afternoons. Call it ‘focus time’, ‘development time’, or whatever.

This will immediately reduce the stress on any development team and allow them to concentrate on what they consider their top priority. I also guarantee it will increase your velocity.

People outside of the team might complain at first – don’t worry. They quite often end up doing it themselves after seeing the benefit of this pattern.

Hours Worked Per Day

Since lockdown, we have all been there. You get up and get your morning coffee and then you sit down to check your emails. Before you know it, it’s time for one last check of your emails, before going to bed.

It’s not good for the individual, it’s not good for the team. It’s just not good for anyone and it’s really hard to see when everyone is remote working.

But there are always signs……

Keep an eye on emails, chats, and check-ins for the team. If someone is clearly working to the above schedule pattern, then you have to look after them and get them out of it.

Anyone that suggests that this is a normal pattern of behavior, is not a friend of anyone.

Productivity – LOC, Number of PRs, etc

Now, these metrics are the ones that have been used mainly for evil in software engineering. We are going to use them for good.

Firstly you can use them to check if someone is doing too many hours and stop that. You’ll see the check-ins night and day. OK in the short term – in the long-term, not so much.

Secondly, we can see where people are struggling to get work done and are not asking for help.

Everyone in a team works to a different rhythm – they have a bit of a productivity fingerprint if you like. It will depend on a number of factors including what they are working on and who they are working with but it’s easy to see.

More significantly for us, it’s also affected by both mood and when people are running into problems and not asking for help. An unexpected drop-off in productivity is generally easy to see and is a good time to chat and offer some assistance.

As a simple example, take the dev that might give a positive update during a remote standup – but you can see that nothing is being checked in. It might be that they are blocked and not asking for help?

In the office, they would probably come over and ask for some help. Alternatively, you would see some anxiety and offer to help. It’s not so easy to detect remotely.
But it is easily spotted in your repo.

Wrap Up

The above metrics are no substitute for talking to your team as much as you can, but they may help in identifying some unspoken issues.

Essential Reading For Java Developers

Coding Style

These are the books to read when you are starting out and want to improve your skills.

Clean Code

Code Complete

The Pragmatic Programer – 20th Anniversary Edition

Test Driven Development: By Example

Head First Design Patterns

Refactoring: Improving the Design of Existing Code

Advanced But Essential Reading

Design patterns : elements of reusable object-oriented software

Refactoring to Patterns

Continuous Delivery

Growing Object-Oriented Software, Guided by Tests


Agile Testing: A Practical Guide for Testers and Agile Teams

ATDD by Example: A Practical Guide to Acceptance Test-Driven Development

Growing Object-Oriented Software, Guided by Tests

xUnit Test Patterns: Refactoring Test Code

Designing Systems

Domain-Driven Design: Tackling Complexity in the Heart of Software

Patterns of Enterprise Application Architecture

Building Microservices: Designing Fine-Grained Systems

Service-Oriented Architecture: Analysis and Design for Services and Microservices

Service Design Patterns

Enterprise Integration Patterns


Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition

Sorting Dropbox photos by year and month with Golang

This Golang program will organise all of your dropbox photos folder and move them into folders based on year and month.


You can automatically upload all of your phone’s photos to dropbox. However, for some reason, it just doesn’t organise them. Perhaps there is a hidden option, but I cannot find it.

You end up with all your photos in one directory – in my case, it was 1000’s over many years which make it hard to open the folder on your computer.

Camera uploads folder has hundreds of files

Sorting The Files

Fortunately you can see that dropbox timestamp the files. This means you can take the following file as an example.

2019-03-06 20.07.12.jpg

Sorting into years.

Taking the above file as an example it would be nice to have a top-level year folder first. This could then go in the 2020 folder.

Photos sorted into years

Sorting into months.

Next it would be nice to sort any given year into months. I prefer them numbered so they can be ordered.

Photos sorted into months

Coding in Go

Golang allows you to create a cross-platform executable which will run on both Mac and Windows.

It only took an hour to write something to sort the files in Go to process the files as above.

The full code is here.

Running The Executable

Download the above code and then you can simply run the executable from the bin directory and point it at your camera uploads directory.

dropbox -uploadDir="D:/Dropbox/Camera Uploads"

Take a look at your dropbox folder and you should find all of your photos are neatly arranged.

« Older posts

© 2022 John Dobie

Theme by Anders NorénUp ↑