(Cross-post) A Day in the Life of a Software Engineer at Freetrade

(Cross-posted from https://blog.freetrade.io/a-day-in-the-life-of-a-software-engineer-at-freetrade-a39a590d7ffa)

I joined Freetrade as Senior Software Engineer in October 2018. We’ve got a huge amount done in that time — the company’s moving fast!

But behind the bustle of getting big features shipped, I wanted to give people an insight into what an individual day’s work looks like on the engineering team.

Here’s my typical day as a Software Engineer at Freetrade.

(My) commute

I commute by bike 90% of the time. The Freetrade office in Shoreditch is about 10km away, so the showers at the office are essential. There’s also a space to lock bikes safely off the street (no-one’s getting my bike)!

If I’m not biking for some reason, then the bus takes a bit longer but is a good chance for reading and Anki flashcards.

Morning reviews

The time in the morning before stand-up(s) is good for getting up to speed on emails and Slack, reviewing the JIRA board and responding to Github pull requests from other engineers. I also tend to pull the latest changes of the project I’m working on and run its test suites to make sure cosmic rays haven’t introduced any regressions since yesterday.

The other essential thing to check in the morning is my Freetrade portfolio — it’s good to see what’s going on after the markets have been open for a little while.

Stand-ups

We split stand-ups by vertical to keep them short and relevant. Currently this means there are four stand-ups of ten minutes each.

Three stand-ups are for the Invest, Discover & Insights and Growth verticals, where we keep track of progress within the vertical and address any blockers.

• Invest vertical: work on the investment platform
• D&I vertical: build insight and analytics features for the app
• Growth vertical: grow our customers

These stand-ups are attended by a mix of engineers, designers, stakeholders and anyone else interested in the projects being discussed.

There’s also a separate bugs stand-up which focuses on triaging new user-impacting issues so we can decide how to deal with them most effectively with the help of the Customer Operations team.

We’re quite strict with the timings for stand-ups. Rambling daily meetings are a common affliction in software engineering teams!

Each stand-up is capped at 10 minutes, even if it means cutting off the conversation. So far this has been effective at keeping each update concise and making sure there’s time to hear from everyone present.

Writing code

After we’ve updated each other in stand-up, I’m keen to make some more progress on our projects. Our software engineering processes are covered in more detail elsewhere on this blog, but I’ll be:

• Implementing features
• Investigating and fixing bugs
• Writing documentation and RFCs
• Writing and running tests
• Making deployments
• Reviewing logs
• Asking and answering questions
• Making and reviewing pull requests
• …and more 💪

RFCs (Request for Change and/or Request for Comments) are an important part of our engineering process.

An RFC is a shared document describing a problem and setting out a proposed solution. Other team members are invited to comment on both the problem and proposed solution, which gives a chance to make better decisions early on. Maybe someone points out that we don’t need to solve this problem right now or that it isn’t even a real problem, or can suggest ways to make it easier to solve.

It’s a bit like a pull request for an idea, with similar motivations.

With an RFC at the beginning, pull requests and peer review come in later in our software development process. Once a reasonable part of a solution has been implemented, we submit the change for review by other engineers. Again, this gives a chance to make improvements or perhaps even reject the change before it gets merged and makes it into production.

As with an RFC, it also gives everyone a chance to stay aware of what is going on in a project.

Automated testing is another essential part of how we do software engineering at Freetrade. We have large suites of unit tests that run quickly and provide low-level coverage across the codebases, and smaller amounts of higher-level integration tests. All of the tests are automatically run against each PR by CircleCI, with the status reports appearing on the PR and also in Slack.

Adding, tweaking and maintaining these tests is an important part of all our development work.

Interviews

As Freetrade is hiring, I generally run or attend several interviews a week. These can be earlier stage video hangouts interviews, or later-stage onsite coding and system-design interviews.

We design and document a clear interviewing system to keep things consistent, which means less preparation and reviewing time is required for each interview once you’re up to speed. Google Hire also helps us run our hiring process efficiently and effectively.

Whether I’m interviewing a more junior or more senior candidate, I always learn something, whether it’s in the range of software projects, languages and approaches that candidates use, or the way candidates solve different problems and see different situations.

We try to get all engineers involved in interviewing quickly by shadowing other interviewers first, before running interviews themselves. This spreads interviews across the team and ensures there is wide participation in how we consider candidates.

Lunch

Being based in Shoreditch means there’s a lot of lunch options within a few minutes’ walk. I tend to bring lunch in most of the time due to the influence of Mr Money Moustache (leaves more money to put in stocks!), but I often join others going to Spitalfields Market, Box Park or one of the many other places nearby.

1-to-1s and OKR tracking

One-to-one meetings are an important part of the management culture at Freetrade, and most of us have a one-to-one with our performance manager every week (as well as all our other daily interactions with them, of course).

We also use Lattice to help us plan and track our goals as part of our OKR (objectives and key results) framework. This lets us collaborate with the rest of the team in reviewing progress on team and individual OKRs. Lattice also keeps track of points of discussion and feedback for one-to-one meetings.

On-call bug swatting

We rotate on-call responsibilities with PagerDuty around the engineers within each vertical. One part of being on-call is tackling bugs during working hours to allow other engineers more time to focus on project work. Depending on the vertical and what bug tickets are currently open, the amount of bug swatting work varies, so the on-call engineer might switch from project work to bugs at 4pm.

Engineers at Freetrade are encouraged to take ownership and autonomy, so the best way to balance bugs and project work while on-call is down to the judgment of the individual engineer and their team.

Friday demos

There’s a company-wide meeting every Friday afternoon, including demos of what each vertical has been working on. It’s great to see our work in action in front of a real audience, and the demos can also have a focusing effect on working pragmatically.

Team socials

We make sure that team social events are part of our goals every quarter, so there are regular team drinks and bigger team outings after work. These are good for getting to know new team members, as our team is growing fast!

Last time, we played shuffleboard. Curling is up next (not the network kind).

If you want to work for a fast-growing team working on a very meaningful problem, check out our roles here.