Let me tell you about my worst day at FreeAgent.

At the start of June, I was eager to get started as the newest workflow intern, the team responsible for user-facing admin features. The first couple of weeks were spent bouncing between inductions and tech issues, but I finally found my feet at the beginning of week 3. Ruby was starting to make sense, my tech was up and running, and I’d wrapped my head around the project I’d be working on for the next three months.

The first few features were easy enough to implement. At FreeAgent, we split our work into tickets: small chunks of work that keep the development process swift and flexible. My confidence was solidifying after a few runs through code review and testing. I could actually do this! As week 4 passed, I started to feel properly independent, I had picked up the pace, and everything was full steam ahead.

So of course, week 5 was when everything went wrong.

T-minus 10 minutes to disaster

The first serious ticket in my project was a database migration, to add two new tables required for my project. Migrations are the solution Ruby on Rails uses to update the database structure. With a huge database shared between over a hundred engineers, proper migrations are essential for keeping everything synced up and running smoothly. During week 4, I had written the necessary migration code, tested it on my local environment, and sent it over to Ops, the team responsible for running migrations on the central server.

On Tuesday, I got a ping from Ops. My migrations had been run and everything was working fine. I had the go-ahead to merge my code into the main branch of the FreeAgent repository.

This code had already presented several issues. The previous week, I’d had to update it several times after realising the database tables contained fields I didn’t need. On Monday, I’d accidentally imported 200 commits and tagged every single team in the company for review. That misstep had taken an hour-long call with a colleague to fix. I’d been staring at this code for over a week, desperately wishing for it to be finished.

You have a merge conflict

They’re the words every software engineer dreads. Most of the time Git feels like magic, but merge conflicts turn it into a curse. I was not to be deterred. I clicked through to GitHub’s conflict resolution page. The cause was obvious: somebody else had run a migration after mine had been written, so there were edits to the database file I was missing. I added the appropriate fixes, and clicked submit.

Git cheerfully informed me that something had gone wrong, and I should try resolving the issue via the command line. I opened VSCode and re-applied the same fixes, then pushed to the remote. This solved one issue and immediately created another: my commit history now had two extra commits, and I didn’t want to pollute the central repo’s history. I attempted to squash my commits together. It failed.

This time, Git didn’t even have the decency to explain what I’d done wrong. It did, however, inform me that my merge conflict had somehow rematerialised. After two days of wrestling with uncooperative branches, I was on my last straw. I was tired, frustrated, sick of looking at the code and completely out of ideas.

Help arrives

After a deep breath, I sent out a call for help. First to respond was my assigned buddy; after trying and failing to resolve the issues, they pulled in Chris, another engineer on the team with more Git knowledge. Together, we spent an hour squashing one bizarre issue after another until finally, the merge conflict was gone for good. That just left a veritable swarm of ugly fixes that needed to be dealt with.

I worked on cleaning up solo for another hour or so, then ran into the same problem as before: I reached a commit that just refused to be squashed. By this point, Chris was in a meeting, but my deskmate Simon (who’d been watching me suffer through this all day) leaned over and asked if I needed a hand. Together, we managed to get the last dregs swept up – but in the process we wiped away the review approval I needed to actually merge the code. Josh, the reviewer who had okayed my branches in the first place, promptly jumped over from the other side of our desk bank to re-approve everything and walk me through the best way to run it all the next morning.

At this point, the clock was ticking past five. I was exhausted, hungry, fighting off a headache from squinting at the screen and utterly embarrassed at how much of everyone’s time I’d taken up. I went home, and went to bed.

A good night’s sleep

At 8:55am the next morning, I turned on my laptop, merged my code, and watched as it went off without a hitch.

Eating breakfast, I finally internalised something incredibly important: “failure days” do not make you a failure. Despite how awful I had felt, everyone I asked was completely willing to help. Whether you’re an intern or a senior engineer with 20 years of experience, everyone is always learning, and everyone gets stuck sometimes. The worst thing you can do is suffer in silence. Even with the myriad of problems I encountered, it only took a day and a half to solve. If I’d tried to fix everything on my own, it could easily have ballooned into a week of lost progress.

As an intern, failures feel especially gutting when you’re trying so hard to make a good impression. Remember: engineering is a team sport. Setbacks are hard, but they can be dealt with. So when you hit your own worst day, just take a deep breath, ask for help, and keep going.

Featured image from WOCinTech on Unsplash