Three Important Things I’ve Learned As A Dev Since Joining AND Digital

14 August 2017 | David Garvie | About a 6 minute read
Tags: Code, containers, dev, develop, developer, Development, DevOps, devs, Digital, Docker, pair, process, Product, Programming, Software, tech, test, Upskilling


When I started at AND Digital I completed a four week bootcamp as part of joining the company. Part of this bootcamp included two ‘Product Developer’ days aimed to further our learning by presenting us with various challenges. These challenges involved unix scripts, test driven development and I was formally introduced to Docker, a piece of software for managing containers.

The core principle of Docker is simple – “run any app, anywhere”. Traditionally, a lot of things usually need to happen for dependencies to be installed in the correct run time environment and then your code to execute as expected in that environment. Using containers can make this process repeatable, predictable and easier.

Think of the steps involved in cloning a repository from a github and then running that software. For a simple javascript application you are more than likely going to require:

  • git to clone the repository
  • npm/yarn to install dependencies
  • webpack/gulp/grunt/sass to build to build a production ready version of your app
  • a specific node version to execute code
  • a datastore (mongo/redis/mysql) to read / store data from

All of these dependencies (and their dependencies) require specific versions, sdks, etc. When you begin to consider all the things which need to work just right for an application to run then it is no wonder you will likely face a member of your team saying the dreaded “it works on my machine”.



Containers allow an easy way to manage those dependencies. Instead of testing whether your code works in your local development environment, you are testing whether your application runs in a container that has defined dependencies. I can’t emphasise enough how important this change in mentality has been for me as a developer. Although devops has become a buzzword, it does promote a number of principles. The most important in my opinion is to simply care about the product you are building.

If I care about my product then it is unacceptable that it cannot be deployed and scaled easily. Instead of merely writing my code and passing it over the fence for someone else to deploy, it forces me to take ownership and ensure that I am delivering functioning, deployed software.

Test Driven Development

I used to believe unit tests were a form of reassurance. They offered quick feedback that any changes I made had not impacted any of the other code in unexpected ways. I had written unit tests but not fully committed (or embraced) Test Driven Development (TDD).

My understanding of TDD is that you create tests which fail before writing code. You then write code which allows these tests to pass and stop coding. You may refactor your code so that it is more readable or efficient but no new functionality is added to your code base.


In the age of Google, stack-overflow and an abundance of online tutorials, it is easy to look for an easy answer and look for a ready made solution. We can copy and paste boilerplate code, reuse examples and get some pretty powerful stuff up and running fairly quickly. TDD brings some balance to this by really making you think about the task at hand. Before we can solve the problem we truly need to understand the problem we are trying to solve.

This is the power of TDD, it forces us to break large complex problems into smaller manageable chunks. You don’t build the whole complex piece of machinery but the small parts which allow the machine to function. When we understand the problem and start to tackle it in a manageable way, we become more productive and effective developers.

I believe TDD has also made me produce better code. Making my code more ‘testable’ naturally encourages modularity and reusability. Writing complete and explicit unit tests provides documentation and allows other members of my team a way to understand what my code is supposed to be doing. Oh, and as an added bonus it still gives me the quick feedback for when my changes unexpectedly break something.

Pair Programming

I really enjoy putting my headphones on and listening to music when I am working which is pretty unfortunate as I’ve rarely had the opportunity to do this since joining AND. Instead I’ve had to communicate, listen, learn and teach all whilst producing software. This is challenging but hugely rewarding. Pair programming is when at least two individuals work together to create software. Usually one person will ‘drive’ and the other person reviews the code as it is being written.


Software is made by teams instead of individuals. People within a team have different knowledge, experience and skills and this should be exploited as much as possible. It is simply unrealistic to expect to learn everything (there really is a lot and there are only so many hours in the day) so it makes sense to rely on the abilities of others. On-boarding, upskilling and having people leave a team can be extremely costly in both a fiscal and productivity sense. It is paramount that knowledge is shared amongst everyone in the team so that if a member of the team moves on, the impact can be kept to a minimum.

I have had the pleasure of working with others with both more and less experience than myself and learned a huge amount as a result of this. I have been taught how to create Docker containers and shared with others how to manage state in react applications with redux. I have found sharing knowledge with others to be the most rewarding. By allowing others to drive and reviewing their code, it has allowed me to remove myself from the detail and focus on the bigger picture – what is my partner really trying to achieve with this line of code?

Sharing knowledge forces me to consider frameworks and general coding practices in far greater detail. I have found my knowledge on a specific topic to have really grown when others ask me a question that I do not know the answer to. Reasoning, investigating and discovering this answer has really helped me expand my knowledge in areas which I already believed myself to be proficient in.

Working through particularly challenging problems and experiencing the shared joy of resolving those problems can do wonders for team morale and really accelerate trust within the team. If there is a sense of unity when working towards a solution or resolving a high priority bug fix then this has been warmly reflected upon in team retros. Although my time listening to Spotify has been greatly reduced since starting AND it is a price easily worth paying to enjoy the far reaching benefits I’ve found in pairing.


Read More From This Author

Share this blog post

Related Articles


We’re looking for bright, dynamic people to join our team!

Discover More Roles