The work calendar
At FreeAgent, we work in intervals of sprints (2 weeks) and cycles (which are made up of 4 sprints – adding up to roughly 2 months total). In a cycle a team typically aims to complete 1 larger project, and during a sprint a team aims to complete sub-tasks of that larger project. This helps construct timelines and structure for product managers and engineers to work within.
In between cycles, leadership takes time to reflect on progress. Product managers and engineering managers plan the next cycle, and this leaves engineers with some free time outside their regular work.
Coming up to the end of my first cycle at FreeAgent, my manager informed me of the amusingly named ‘Wiggle Week’ before the start of the next cycle.
What is Wiggle Week?
Wiggle Week gives teams some wiggle room to adjust when transitioning to the next cycle. It’s also a chance for engineers to work on something different from their normal routine work. This could be creating a new feature, or fixing a bug that has bothered them all cycle. The extra time could also serve as a buffer, if a project didn’t go to plan in the previous cycle.
There is a Notion board for all the ideas people across Engineering have come up with. Some examples are, updating our developer website to the modern FreeAgent style, and rejuvenating the FreeAgent game that engineers use to learn about the application. Interns can also contribute to this board, and we’re in a unique position to offer insightful and helpful suggestions as we each have a fresh pair of eyes to go over the codebase.
When I came across the board, there was a plethora of ideas I could help with. But with so much choice, how could I decide what to work on?
Deciding on a project
When deciding what I should pick up here are some of things I took into consideration:
- Ability – Generally speaking you should stick to something within your comfort zone, especially if you want to complete a project within the 5 days of Wiggle Week. For example, if you’re used to working on the main Rails application, it makes sense not to implement a change on the mobile applications! That’s not to say, don’t branch out to other teams, cross-team collaboration is encouraged.
- Scope – Assess the scope of the project. Although one week may seem like plenty of time, it’s important to factor in planning, designing, and time for code reviews and pre-production testing. As a lot of engineers will be working on their own projects. it may take longer than usual to get a code review, or a design signed off.
- Interesting – Work on something you genuinely find interesting and will enjoy! There’s no point dragging yourself through Wiggle Week working on something you find dull.
Being an intern for the Banking Integrations team, I was used to working on the main Rails application, so I felt most comfortable taking on something in that codebase. One project that seemed to tick all three boxes was updating the default validation messages which we show to customers when an error is detected on a form submission.
Old validation messages
The mission was to make error messages more user-friendly without having to completely overhaul how they’re created or displayed. Despite appearing as a straightforward modification, it was an interesting multi-layered problem. The code needed to be designed so that updating the message again in the future would be much easier. In addition to this, we had to release changes gradually to ensure we didn’t break all the validation messages at once.
Assembling the dream team
Although I could have chosen to fly solo, I thought I would take this opportunity to work with my fellow intern Owen from the Workflow team. Having someone else to bounce ideas off and brainstorm with was particularly nice, especially because we were in the same boat being new to the company.
As interns we did lack context and experience, but this was even more reason to dive in and try to learn something new. We needed to do more research and ask a lot of clarifying questions to more seasoned engineers throughout the process, so it ended up being a fantastic learning opportunity. We were able to branch out to other teams and utilise different perspectives.
Defining the problem and solution
Before jumping into the problem, we had to really understand what needed to be done. Notably, we were trying to futureproof the message, this meant we had to design our solution in a way where it would be easy to update the message later. As a starting point, the Notion card had a comment from another engineer on how this change could be implemented.
After some initial discussion, we fired a message to them for some clarification. This raised a few more questions, and with some additional help from our respective teams we then clearly understood what we needed to do and how to do it. We also spent time splitting up the work and co-ordinating pull requests (a request to merge proposed changes into the main codebase). I cannot stress how important these discussions and questions were. FreeAgent has such an open culture where you can always ask for a hand if you are stuck.
It was eye-opening to learn how each team works a bit differently. For example, the change we were working on was closer to the Workflow team’s focus than any other’s, so we followed their structure for pull requests. Workflow was more strict about having small changes that are easier to review, descriptive commit messages, and linking to previous work.
Initially I found this quite frustrating, especially considering I didn’t have to take these into account as much when working with Banking Integrations. What I learned is that each method of working has its own merits. Having small pull requests meant we were less likely to trip up during code review, and because they were self-contained they could be reviewed and released independently. I came around to seeing the value in this structure and even implemented some aspects of it in my project, for example I dedicated more time to having descriptive commit messages and pull request descriptions. Collaboration and communication is so important in this role. Helpful comments and descriptions lead to less friction in communication and ultimately greater efficiency for passing code reviews and testing. As a point of comparison, we ended up with 7 pull requests, whereas if I was making this change through Banking Integrations I might’ve only had 3.
Releasing the changes
After implementing the solution, passing code review and pre-production testing, we released the changes and lived happily ever after…
Well, almost – following up on changes is incredibly important. Informing the relevant people is essential, especially for customer-facing changes. For this work, we let the Support and Product teams know about the changes we were making. In addition to this, our visual regression test suite, which compares screenshots of the app, needed to be updated to recognise our changes.
New validation messages
Finally getting to the win, product designer Andrew who prepared the new messages, mentioned me and Owen during the Weekly Wins of our company-wide Town Hall. Weekly Wins is a segment of the meeting where we celebrate the accomplishments that occurred during the week. It felt incredibly rewarding to be acknowledged in front of the whole company.
Wiggle Week is a brilliant opportunity to work with another team and try something new. I learned about how Workflow operates which led to me changing the way I approached work. I highly recommend you try to implement something similar in your own work!