It’s been a wild time this summer at FreeAgent: four-day weeks, Edinburgh flooding, people gearing up to return to the office, and in the meantime you have me, the remote software engineering intern, working away in his little corner of the FreeAgent world. But before all that, who is this wee guy? Well, I’m Fraser Dempster and I spent 12 weeks of my summer at FreeAgent.
Excuse me, I’m lost (virtually)
It didn’t take long for me to mess up. On the first day I was late to the induction with the other new starters (of which there were nine). I hadn’t managed to find the email to join the first ever call, so in one sense you could say I was lost, albeit virtually. I had already missed a major part of my first day – great. But after that it was go go go – from creating accounts to setting up my workspace and completing onboarding tasks, there was a lot to do on that first day. Having been to university, I was used to being spoon-fed my admin work, so the change in pace was drastic.
Meet the mobile team
After that first day, it was time to meet the mobile team, which had always been fully remote – veterans of the working from home culture. Aside from their remote experience, I felt spoiled to witness how adept the team were in their respective fields, evidenced by the jargon exchanged in that first call. The team dynamic relied on variety – from product manager and designer, to iOS and Android software engineers, there was a lot more involved in a software development team than I imagined, and I was impressed.
So I wondered how things really worked within the mobile team. I looked for more information regarding the mobile app, which led me to the product manager (Roz). She kindly shared the “mobile roadmap”, whereby, firstly, features are proposed based on analytics and user requests. Then, these proposals are studied and better understood through Figma (a collaborative prototyping tool) designs, time estimations, and value to users, and if all goes smoothly, the properties of a mobile feature are assimilated and eventually developed by the software engineers. The process is perfectly streamlined in order to prevent inefficiency within the team and to maximise output of impactful features. One of which I was about to undertake.
Spending category report – ehm, what?
My summer project. What’s it all about? Making use of user data, many new banking models incorporate categorised spending reports to aid users in accounting for their spending. I personally valued this feature, as did users, and that is what I would be working on this summer. To prevent any frivolous attempts at further describing the feature, the Figma design created by our amazing designer (Barry) is attached below.
The process to achieve that design begins with an Application Programming Interface (API) to input all the data displayed on the screen. An API is like the waiter you tell your order to – it collects your order, informs the chef, then consequently serves up your meal. When the API was ready, the mobile development would begin. This was split into two phases – the first one for creating the list, titles, and URL button from the design above – everything excluding the graph. Hence, the second phase would be solely focused on developing the graph, due to its complexity. The initial design, for example, required horizontal scrolling and an accompanying gesture hint, but as time went on, requirements changed and the design reflected that, as I explain later on.
API building
Building an API was an entirely new experience for me, as was Ruby on Rails, so to get started I was recommended to do the Ruby on Rails blog tutorial – which I highly recommend for any aspiring Rails developers. After that, I wrote an API specification which detailed a summary of how the API would function, the request URL, and the response schema. The response schema detailed an example of what the returned JSON object should look like. Shortly, the API will be made available to our API users. After having the specification reviewed by the team, and addressing any questions/concerns, it was time to begin creating the API on Rails.
The process of doing that involved understanding the Rails architecture. Namely, the Model View Controller (MVC). The MVC separates the application into three parts. The model is for handling data and business logic, the controller is for handling the user interface and application, and the view is for handling the graphical presentation (in my case the JSON object).
To tie that into what I was doing, I used the controller to grab the previous six months from the present date because whenever a user opened the feature, we would show six months by default. The model was used to do the calculations and logic so that the data was ready to be displayed. For example, mapping the months to the correct time period of the report, or getting the appropriate title for an item using the current company and nominal code. Lastly, the view was used to format the returned JSON object in an intuitive way, preparing it for adoption in the mobile app.
In the meantime…
Aside from developing the spending category report, I had the opportunity to discuss my project at the Engineering Forum. The Engineering Forum is a weekly meeting for engineers to share a specific technical topic, something they learnt that week, or for interns to showcase what they’ve been up to – that’s where I found myself. It was a great opportunity to be able to practice public speaking over Zoom and I learnt the hard lesson of not knowing my jokes’ comedic effect as there was minimal visual feedback from the audience and mics were muted. Alas, it was really fantastic to share with everyone how to create an API endpoint for the mobile app and it really helped me consolidate my knowledge as well. On top of that, the feedback was rewarding and I enjoyed answering a few questions on the topic too.
Android development (Part 1)
The FreeAgent app is native to both iOS and Android. After discussing it with my manager, we decided it would be best to develop the Android app as I have a Samsung phone. The app was written in Kotlin, which was unfamiliar to me, but I was assigned one of the senior Android developers (Moh) to buddy with me, which helped immensely. Setting up the app was simple: download Android studio, clone the repository, and plug in my phone (to use as the emulator for the app) and it was ready.
Having experienced learning a new architecture for Rails previously, I felt more equipped this time to tackle the Android codebase and architecture. The native Android app uses the Model View Presenter (MVP) architecture. This differed from the Rails MVC in that the presenter dealt with all the business logic, receiving the desired data and formatting it for the view. The presenter also communicates with the view through an interface which allows for mocking of unit tests. The model defines the data to be displayed and the view handles where the data should be displayed.
Having that understanding down, the next step was to dismantle each part of the design. At a glance there were two text boxes holding the month/year and total spending for that month, a list of the categories with their corresponding spending, and a URL button. Having the API ready to go, the mobile app needed to be able to decipher it into something it could understand. To do this, I created a ‘repository’ in the codebase that would grab the API data and translate it into an object the app could understand. Once that was done, the display needed to be created to look as similar as possible to the design.
The trickiest part was the list of categories in the design. Since the list in the design had to be dynamic (always changing in size) it could be anything from one item in size to 2,000. This means there is the potential pitfall that if you try loading a huge list, the app could slow right down, and that isn’t what users want. Solution: RecyclerView. A RecyclerView only loads items as it needs them, meaning that a massive list would never load all at once. Bingo!
The extra buttons in the screenshot above are to allow navigation of the months, since the graph didn’t exist.
A lesson learnt
When the spending category report matched the design (aside from the graph) I thought I was done with part one of Android development. How wrong I was. After boasting to the team of my success, the real work began. The mobile team tester (Jess) got down to business. And after testing my feature, there were a boatload of bugs that needed to be addressed. So I got back on the grind. And this process repeated itself until most bugs were ironed out. But then I had to create a Pull Request (PR), write up Pre-production testing (PPT) and also fix the tests I had previously written, which all took time – around an extra two weeks.
Finally, after part one was done, I had the pleasure of reflecting on my experience in the team’s retrospective where I wrote in the “went badly” column that “the spending category report was delayed”. In response, Joe, an Android developer, told me that “the last 10% of the work takes 90% of the time” – a rule that will stick by me throughout my career as a software engineer. Thank you, Joe.
Android development (Part 2)
Having spoken to the mobile designer and other Android developers, the design of the graph had to be changed. It was decided that instead of a horizontal scroll, the graph would use two buttons to navigate between six-month periods, as this eliminates any uncertainty in utilising the feature from the perspective of a user. Everything else was to be kept the same.
The toughest part was drawing the graph, as this had to be done manually on Android using Canvas. There were similar examples within the app already that I leaned on for support, and I was assigned a new buddy (Joe), who always helped me clear any blockers I had. To do the positioning, I had to create a ratio that each bar and bar gap would abide by so that the graph would be drawn equally on the x-axis. To draw the height, I used a simple formula that would divide the absolute value (amount) of each bar by the maximum value between all six bars and then multiply that by the height of the canvas area (where the graph could be drawn). The last thing was making the bars clickable. To achieve this, each time a user lifted their finger off the screen I looped through a list of bars that had the same x-coordinates of each bar and the max height of the canvas and detected whether there was a specific bar within that column. If there was, the bar would be highlighted and the data displayed would change.
Remote working
The elephant in the room, specifically my room, is remote working. This hasn’t been the conventional in-office internship and that changed a lot of things. There was no ‘watercooler chat’, lunch with colleagues, and my job commute was precisely three seconds from my bed (I haven’t been late to work yet). At the beginning, it was tough working remotely because a lot of problems were amplified due to the uncertainty of being a newcomer. FreeAgent, my team, and the culture really supported me in navigating remote work, and here’s how.
Frequent one-to-ones with my manager (Anup). These helped give me a sense of direction while working. Whether it was with the project, presentations or just to satisfy that social itch, these meetings were always welcome and encouraged me to approach fellow programmers and other mobile team members.
The culture of helpfulness. There has never been a time throughout the internship that I felt isolated and unable to ask for help, thanks to the team and the culture cultivated here at FreeAgent. However simple the question was, someone wanted to answer it, and that made me feel comfortable at my virtual workplace.
Town hall. Prior to starting my internship, I was intrigued by the town hall concept, but I know much more about them now that I’ve sat through a number of virtual town hall meetings. The cooperative culture is evident and inspired me at the end of the week. It also helped me stay curious and apprised about other teams’ events.
Keeping a diary. From the beginning, I kept a daily diary to track what I had been up to throughout the internship using Notion. Diligently, but also in a relaxed manner, I documented my highlights. This helped consolidate what had happened during each work day and gave me time to reflect on how it could have gone better or worse.
Meeting the other interns. Having weekly meetings with the other summer interns was a good way to loosen up and share what each of us had been up to during the week. The environment promoted was relaxed and everyone was in a similar situation where they were learning new things.
Concluding my summer internship
It’s now time to trade my FreeAgent summer for an academic winter. No more town halls and virtual coffee chats. I’ve also met and said goodbye to fellow colleagues who left during my internship, to whom I wish well. Everybody I have met has shaped my knowledge and understanding of software engineering one way or another, and that will undoubtedly influence my career. I’ve tackled challenges and expanded my skills. Thank you, FreeAgent.