Pair-programming is a great strategy for us to foster collaboration, communication and come up with better results overall:


Fewer bugs and errors are introduced as a result (significantly reducing development costs and directly addressing some of the cards raised)

Provides a space to align and prevent conflicts later (also more consistent code style)

Reduces dependancies ("lottery factor") over time as more people get onboarded to the features

Creates a shared ownership and shares responsibility

Stops from going down the wrong path for too long. When people work on their own, they sometimes get stuck on a problem, with a partner you are more likely to try different solutions


There are great resources on pair programming out there to get inspired. For example on 

 or watch this great talk on pair programming by Brigitta Böckeler:


We encourage all our engineers to join forces and code together as often as they see fit, even across teams and disciplines. In order for such an exercise to be fruitful, it is important to remember that not everyone has the same approach to coding, problem solving and learning, and that differences in domain and technical knowledge play a big role in whether or not both participants will benefit from the session. To make the most out of pair-programming, please consider the following guidelines:



Define upfront the duration and scope of the session. Is it going to be for a certain amount of time or will it last until the whole feature is being done (with appropriate breaks)? Make things clear from the get-go to avoid mismatches in expectations in terms of what is being achieved.

Let the least experienced engineer (whether it’s in terms of domain/product or technical expertise) be the one with control. Because they are the one with the steeper learning curve, they might be slower which is why they should lead the pace. Having the most comfortable engineer being the one with keyboard control leads to a spectating session, not pair-programming.

Regularly asking for confirmation or feedback to make sure both participants are on the same track and no one feels lost. For longer sessions, do not forget to suggest or ask for small breaks. Pair-programming doesn’t mean having tunnel-vision for hours on end.

Pair Programming

 in the face of uncertain priorities and product potential while maintaining 

A form that one fills out to track code changes in a codebase

A place to argue about, assert or defend the merits of one’s choices

The way to merge into a deployment branch

Collect as many changes as possible to deploy at once

As engineers, the quality of the codebase is one of our core responsibilities. Code reviews are the final line of defense before code enters a codebase.

Think of a time when you merged something and later revisited it to improve the quality, stability and maintainability of code. I don’t know about you, but in my experience the chances to do so are far and in between.

Once code is in place, it becomes a challenge to address issues that do not break core functionality. The natural outcome is to add a 

 ticket into the backlog somewhere. It is hard to prioritize these because there are other priorities that take precedent.

At limehome we are a fully-remote agile team, we want to take advantage of what code reviews have to offer. Rubber stamping or bypassing code reviews is not too different from merging to your 

Code reviews encourage early failure and this is a positive downstream effect for our end-users. To that end, our customers and branding are at risk if we opt to fail later. How does this scale our organization and engineering talent?

By sharing feedback before code is merged, it becomes a learning opportunity for the 

, all engineers are empowered to review and gain visibility in other projects

, it is known who is accountable for a code change and all the context that comes with it

 that something was merged that everyone feels good about



To set the stage, let’s take a look at what each actor can expect to achieve in this process:

They want this to happen quickly to unblock self

Feedback is desired on the implementation

Confidence to merge and shared accountability on the code change

Someone else to understand the code written

Feedback to meet quality, maintainability and stability standards

Understand the codebase and recent activities

More than one reviewer offers additional perspectives


All engineers are expected to play both parts at some point, regardless of experience and tenure. The desired outcome is for 

all viewpoints, experiences and knowledge


How does one author an easy-to-review MR?

A long MR does not do favours to those involved. It requires more time and overhead to review due to sheer quantity. This results in time spent crafting an MR, false approvals, quality leakage and significantly longer turnaround on reviews. Not only will the first review take long, subsequent comments will take longer to review.

As a reviewer, feel empowered to request breaking down of an MR into smaller MRs. Otherwise, the duty of a reviewer cannot be reasonably fulfilled. This is a collaborative effort, so be prepared to support the author.

The reviewer should have all the context required in your MR. That includes a clear description, test instructions and any caveats. Be aware that someone reviewing your MR may not be from your team. If it is a small enough change, any engineer can assess the quality of your work. If that is not acceptable, be specific about who the reviewers should be.

As an author, preparing an MR with sufficient context and selecting the right reviewers will prevent questions and comments like:

“I don’t know about this project/this codebase.”

Be careful with how many and which reviewers you select


There are no hard and fast rules here. When requesting reviewers, be cognizant of the reason they are there. Perhaps they have specific knowledge that is needed or that they are part of your immediate project team.

However, more reviewers may lead to a situation with too many cooks and opinions. It is certainly not forbidden and may in fact be warranted for a critical change with a broad impact.

If you were to look at this code again in a year or if someone new joined the team and looked at this code, would it be easy to work with?

It is clear when feedback requires or does not require an action

Waiting for one is asynchronous and does not block work

The reviewer is comfortable with sharing constructive feedback and asking questions

The stakeholders of impacted code are in alignment with the approach and implementation

The stakeholders of impacted code believe that it meets our quality standards

Redirect the review to someone you know can do so

Comment in the MR why you cannot perform the review

DM the MR author with your reasoning why you cannot perform the review


These actions should be taken immediately and reduce both the author and reviewer’s overhead. It allows the author to take an action and get unblocked as a result. In a way, it’s an example of actionable feedback…

Feedback, even outside the context of a code review, should be constructive and actionable. Without a recommendation or clear action, asynchronous communication is subject to misinterpretation. It is important to be objective. By sharing reasoning, risks and impact of a suggestion, the receiver is more likely to understand that perspective. If the feedback is ambiguous then one can expect the same on the receiving end.


Looking at the code sample above, an example of constructive feedback might look like this:

Code Reviews

We used to have long regression testing sessions before each release. I remember staying late, ensuring everything was running smoothly and that nothing was broken. Releases were always stressful for the QA and other engineers. We had a rotating release manager to coordinate the release, and a release call was held before each deployment. With weekly releases on a fixed schedule, QA had to be always available to catch any major issues before or after the release, making taking more than a week's vacation difficult. We wanted to be the first to know if something went wrong, not our customers.

The entire quality process was a headache, and what made things harder was the lack of testing at the implementation stage. This often resulted in QA engineers taking on the role of quality officers and spending more time following up on fixes and validations instead of enhancing testing strategies.

We also monitored our Change Failure Rate (the percentage of deployments causing a failure in production), which ranged between 40% and 60%. This wasn’t good enough, so we knew we needed to change something.

Over time, we expanded the QA team, assigning a dedicated engineer to each team. But this didn’t fix the problem, because the real issue was deeper. What we needed was a shift in mindset.

We started highlighting the importance of the testing pyramid, frequently discussing it with the engineering team to ensure everyone was on the same page. As you can imagine, mentioning it once or twice wasn’t enough but eventually, repeating it paid off. The goal was to also focus on testing at the lower levels such as unit and integration tests so that our pyramid wouldn’t look like an “ice cream cone” anti-pattern that leads to relying too much on manual testing. As Martin Fowler says “If you get a failure in a high-level test, not just do you have a bug in your functional code, you also have a missing or incorrect unit test.” By addressing small errors early, we can often prevent larger failures.

As part of this shift, we also reassessed our automation tools. Initially, we used Robot Framework, but due to its limitations and the need for more robust and scalable automation, we later switched to Cypress and eventually to Playwright for end-to-end and integration testing. This transition allowed us to achieve faster, more reliable tests and better integrate with our development workflow.

While we've primarily followed the Testing Pyramid, the Swiss Cheese Model, introduced by James T. Reason, provides another interesting way to think about testing layers. In this model, each level of testing is like a layer of Swiss cheese, with holes of different sizes. These holes represent potential gaps in coverage. If the holes align across the layers, defects can slip through the entire testing process. However, if each layer is covered with sufficient tests, the chances of the holes aligning are minimized. This increases overall defense, making it much less likely for a bug to reach the end user. Although the Swiss Cheese Model is typically used in risk management for more complex systems, it, much like the Testing Pyramid, emphasizes the importance of testing at multiple levels, as no single test can catch every defect.


Together with the department leadership we set the goal to adopt a shift-left approach in testing across the department. Shift-left describes the mindset that quality is a shared responsibility, involving everyone from QA and developers to designers and customer support. However, this shift was very challenging, because ownership of testing was believed to be the responsibility of the QA team, rather than a shared effort.

To make it work, we took a step further by organizing workshops and knowledge-sharing sessions within the team to show, in practice, what QA does, how others can support it, and the importance of everyone contributing to the quality of the product. Despite a slow start, the shift gradually encouraged stronger collaboration, enabling developers to play a more active role in testing and taking on greater ownership of their work while allowing QAs to focus on writing automation for end-to-end tests. By shifting testing to earlier phases such as during development and at the integration stage we were able to catch issues sooner, improve code quality, and ultimately reduce the time spent on manual testing later in the process. Alongside this, we implemented trunk-based development, and continuous integration practices, which supported our shift-left mindset. By merging smaller, more frequent changes, we could test and deploy faster, improving agility and reducing the risk of large, complex releases. 


Test Visibility and Real-Time Monitoring

As part of our continuous improvement efforts, we also integrated Datadog with our CI to monitor test reports, providing better visibility into test performance, reliability, and flakiness. With the testing dashboard, we can now easily track key metrics like execution time, failure rates, and overall success rate helping us to optimize testing and improve CI pipeline stability.

As I mentioned earlier, we used to have weekly releases. Since switching to trunk-based development, we deploy to production more than 50 times weekly.

We also significantly increased our end-to-end automation coverage, allowing us to release more confidently and efficiently. When we transitioned to Playwright, we migrated everything and rebuilt our automation structure from scratch. Now we've reached nearly 80% automation coverage, a remarkable milestone.

By embracing automation and continuous deployment, releases have become routine rather than stressful events. This shift has improved our release speed, and increased confidence in every deployment.



Our journey has been long and challenging but also rewarding. We’ve built a stronger, more efficient process that benefits both QA and the team. However, this is just the beginning. We continue to refine our process to make deployments even smoother every day.

The Evolution of Our Release and Quality Process

. It explains how as a manager, you should not try to manage your time down to the minute, but instead focus on managing your capacity.


It’s a good principle, and something that can be more widely applied when looking at engineering teams and how their work is planned. It can be extended to sprints as well as longer-term plans as well; if you allocate 100% of your time then any interruption (a hotfix, waiting on 3rd party, an outage, etc) causes things to slip and means that overall delivery is delayed.


Building in some "slack capacity" also allows you to tell a better story - it's much nicer to say "we delivered X and Y this cycle, as well as W which was unplanned", versus "we delivered X and Y, but failed to deliver Z which we had on our roadmap, because of unplanned work required for W".


This is important for building trust in being able to do the things you put on your roadmap. And yes, we work agile, so roadmaps are more guidelines than promises, but that's not how our monkey brains work (we see shiny = we expect shiny) and so roadmaps tend to be more “real” than ideal

work expands to fill the time allocated to it

, so if you just have empty slots then you'll find your deliverables always seem to take up that extra time. This is deliberately not the purpose; you want to keep the time for 

 interruptions, not just regular work.

There are various strategies to compensate. The general idea is to not have unallocated "free-time", but instead have a backlog of 

 tasks that still bring value - small things like automations, paying off technical debt, or even time for learning.

The trick is to make sure the spare time is still 

 time - this is something you can see when one of your reports wants to learn something new, and so you allocate some time in the sprint for personal development (e.g. Friday afternoons).


If you just free up time, it takes a very disciplined person to actually use it for progressing - most of the time it ends up being used for product work, or vague "learning" that doesn't result in anything in the end. If you treat it as a task (eg: 1 chapter a week) then you can get further (further than just "read this book by X date").

If you make sure that slack time is still planned, you keep your velocity. It's important though that this work is low-priority (and small enough!) that it can be dropped easily, without impact, when you need the extra time back.

If each person in the team has a time reserve, and then a reserve for every sprint, and then also reserves in the cycle, doesn't that mean we will barely deliver anything? Well, yes but also no - looking at the backlog it may seem like fewer things will be delivered, however in reality you would not deliver a full backlog either. Having fewer items with higher confidence is more honest to reality, but gaps in the backlog don’t mean that stuff isn’t getting done either!



And this is why having a groomed backlog is important - if you actually finish on time (or even early!) it should be easy to pick up the next impactful item

 - anything delivered is now a bonus. If you actually need the buffer time, your overall commitments will not be impacted and it means you're able to deliver what you planned with minimal delays.

view-of-a-desk-with-a-calendar-and-a-planning-journal

Managing team capacity and building in slack

Whenever we are exploring a new problem we want to ask ourselves whether it’s a solution that we should build ourselves, or whether we should instead purchase something off the shelf from an existing provider.


To help guide us in the decision we look at several factors along a scale with building it in-house on one side, and purchasing a solution on the other. The scale purposefully does not have a “neither” or “average” option in order to better guide our decision making. Rarely will “neutral” be the correct evaluation when taking all the factors into account.


We have created a template and when using it, it is not unexpected that some factors fall on either side, however when taken as a whole it should hopefully become clear what is the right path.

We have a central purpose and central business goal, and applications that don’t differentiate us in our core business should be bought. A good rule of thumb is that if we cannot find a provider “off the shelf” in the space of what we want to do then we should probably build the capability in-house.

Cost is often the most visible driver in build vs buy decisions, however initial cost to build/buy is only a small part of the equation. Once deployed, application costs include maintenance and changes. We should take a look at the total amount of resources and people needed to maintain each solution. These extra costs often also include more time spent by the team as well as the knowledge burden of learning about more tools and systems.

Tech people want to innovate, create and “wow” the customer. But wanting and having the capabilities to do so are two different things. If we have a culture that does not foster innovation, speed, agility, and fast delivery, then “Buy” should be the first option. This can be true in general for the organisation, but if the team responsible is new (or even yet to be formed) then we should consider “Buy”. If we have a proven record, then all options should be on the table.

If we know what we need it is much easier to compare to existing solutions. In cases where requirements are not well understood or are evolving, building (at least to minimally viable product level) is often the best route. This will often be the fastest way to discover what it is that we actually need. However when looking at solutions the minimum-lovable-product (or MVP) should include both functionality and architecture.

If the package fits the business and technology needs and the software provider has a good track record, buying will almost always be faster than building. An exception is when the “critical few” requirements are much smaller than that. If the “critical few” are smaller enough subset, then building a MVP may be quicker, at least in the short term. This is all about how fast we can have a solution that brings value to the organisation.

Build vs. Buy Decision Making

It's a truly serious problem. How many cat memes have been implemented into your code lately? Have you replicated Google's 

 on neural networks and unsupervised learning to identify and find cat videos?


Luckily, there's a solution for that! The internet is chock full of ways to catify your tech skills, or simply give you the ability to catify them yourself. 90% of the internet is cat related anyway.

Take for instance, 

. This website is a riff on Google's work, generating cat images with neural networks. This skill is obviously something that everybody needs to know. After all, if you cannot generate cat images using a highly sophisticated deep learning technique, you're clearly falling behind in the technical world. Plus you can learn the super popular language Lua, and work with some Facebook open source! And obviously, if you don't know Lua, can you really claim to know tech at all?

Then there's 

, which generates cat gifs on demand. You get a cat gif, you get a cat gif, EVERYBODY gets a cat gif. It's relatively simple to contribute to this project and get a feeling of accomplishment. Submit a cat!

If you'd rather just leverage this cat gif tool, there's a front end website you can simply embed in your website. Sure, it's a .net, but not all technology is perfect (remember zip disks?).


. No website is complete without appropriate error notation and recognition of your HTTP codes. And pretty much everybody who knows ANYTHING about tech, leverages the codes of http.cat. It truly marks you as a first rate technologist.

Http.cat is also a great learning opportunity to remember and learn the lesser known HTTP codes, like 422, 509, and 200.

These are just projects that I've discussed with other technologists in the past 24 hours. You can do whatever you want implementing cats! Someone in my friend's company wrote a script to auto add 

 to their pull requests.

It's so popular there's even a company CALLED 

, that develops IT Infrastructure solutions for other companies. No, I'm not entirely positive, but I think the CEO of this company is in fact run by business cat. He's been out of a job since leaving Miaoco.

If you haven't been working on integrating cats into you tech, you're falling behind the learning curve. You can do whatever you want, in whatever language you want -- but the job is to spread and promote the usage of cats on the internet. It's a great learning experience, and a must for a burgeoning (or established) technologian.

 Adding More Cats to Your Tech

When you’re starting a new project, you’re faced with a lot of questions - you need to understand the problem you’re trying to solve, how much effort it's going to take to solve it, and the benefits you’re going to get from the solution


I like to think about problems as a comparison between the opportunity cost and the amount of knowledge about a subject. The point in time when the project starts is reflected in the opportunity cost; you need to obtain a certain amount of knowledge before you can make a plan and choose a path to execute on.


At the beginning, if you're able to seize an opportunity you might achieve a lot of value output. For instance, getting a new UI library out in a moment that teams can immediately use for an upcoming migration can create value. Whereas rolling it out in a few months later could have almost 0 value (if not negative!), as teams could be past the time of needing it and may even have to spend significant effort switching to it.


When it comes to knowledge, generally the longer you spend researching a subject the more you know. You may not be able to know everything, but the deeper you get into something, the more you understand edge cases and nuances, and give more and more precise estimates.


Seizing opportunity and gaining more knowledge are in obvious, productive tension. This is represented by the graph showing the relationship of opportunity and knowledge in regards to value creation over time. 

As time goes on the opportunity slips away, while your knowledge increases.

When you first start at T1 you know nothing, but it's probably the time in which any action you take would have the most impact. The direction is unclear, at this point estimates tend to be fuzzy, and because the impact could be large, a wrong direction has a large impact down the road.


On the other hand if you spend weeks or even months researching something, then by T2 you will have all the knowledge to make a very accurate roadmap with great estimations, but the opportunity to have any impact has passed.


Where you want to be is somewhere around the intersection of the two lines at T3, or even earlier! It's good to have some knowledge to be confident you're not going in a completely wrong direction. However, you also have to acknowledge and live with a level of uncertainty. By starting to build something at that point, you can start having an impact.


Finding this point is hard, and is not an exact science. Thinking about this opportunity cost and value creation helps to push for a bias towards action to take the risk and get the reward.

When to start

Lying awake at 2am, unable to sleep and smelling the bananas in the kitchen getting riper by the minute, I did what any reasonable person would do and attempted to make banana bread. Attempted, of course, because articles are rarely written when something mundane goes as expected.

Banana bread is a relatively easy recipe, which I had done dozens of times before. However when I checked the oven 30 minutes later everything was not right as the bread was stubbornly lying in the bottom of the pan instead of fluffing up into a proud loaf. Clearly, a mistake had been made. And herein is the first lesson -


constant monitoring, and alerting when something isn’t right. If you’re able to detect defects early you can often prevent the problems getting out of control



When running software a sudden lack of (log) volume can be an indication of something seriously wrong, which is often an overlooked symptom when compared to a sudden increase in volume. The underlying assumption however is that, like baking, there is a certain amount of volume expected.

In the case of bread a rise is expected, but only because you know that of course it will! But if it was the first time you had ever set foot in a kitchen, would you be able to tell if it was normal or an indication of a pending calamity? This is the same for metrics;



you need to understand the system before you can tell when something is unusual


So as soon as I was alerted that something was wrong, it was time to debug. Unfortunately an oven door stood between the problem and me, which was vaguely reminiscent of attempting to debug a remote host with nothing more than a VNC connection to the rack.

Since running hands-on diagnostics was out of the question, my only option was to turn to the documentation. When I baked my first loaf I followed the recipe exactly. I carefully measured the ingredients, set the temperature just right, and double checked each step. But after getting familiar with the process I started to rely on the recipe less and less..



When you do a process enough it becomes repetitive, and when you stop paying attention and that is when the mistakes creep in.



Research shows that checklists improve outcomes. Doctors and pilots use them, and so should we as engineers. Going back to the recipe it became immediately obvious that I had missed a crucial ingredient. Now to simply put the fix into production…


In normal circumstances you’d make sure to understand the remediation steps to a problem, and clearly communicate with your stakeholders about the process. In this case I patiently told my stomach that it will probably not get exactly what was promised - but it will just have to finish baking before we can check.


Sometimes solving problems takes time, and sometimes there is nothing you can do about that.



If a server is restarting there is no amount of bash magic to make the platters spin faster or the network interface to come up sooner, but the one thing you can control is the expectations.



Clear communication during the incident helps make sure that everyone is aligned and aware of the timelines and steps being taken



Once it had finally made it out of the oven it was time to reflect on these lessons, because each failure is a learning opportunity, and a good postmortem is about identifying the faults in the system and not assigning blame. It would be easy to say that because it was 2am and I was already sleep-deprived that it was a bad idea to start baking, however a better approach would be to have a post-mortem:



Always ask: how was it possible that the mistake was made in the first place, and how it could be avoided in the future? What factors lead to the situation?


The root causes for this outage of banana bread include the fact a checklist was skipped because it was a routine procedure. Ingredients were missed because they were not stored together. Banana bread was happening at 2am because.. well basically because the desire was not dealt with sooner in the evening.

In this case I made some systemic changes by writing out the recipe and tacking it to the cupboard where I store the baking ingredients so that it would always be immediately visible. I also moved the baking powder to the same shelf as the flour, as they would always be used together.

And so while baking and engineering are sometimes worlds apart, there are lots of things we can learn from each other:

Constant monitoring, and alerting when something isn’t right. If you’re able to detect defects early you can often prevent the problems getting out of control

You need to understand the system before you can tell when something is unusual