“There’s nothing I find more rewarding than going home feeling I’ve gotten something done"
Celebrating the release of a brand new fix to office-wide applause, before clocking off for the day (on time!) to go relish your achievements. It’s the dream for many developers, but here at FOODit, it’s a near daily thing.
Thanks to our use of the continuous delivery approach, a healthy respect for remote working and a fully loaded coffee machine, efficiency is king at FOODit, meaning our developers spend more time writing satisfying code, and less time knee deep in tickets. We spoke to Anca, one of our top developers to find out why she loves working here, what her day is like and how Krumpet the office pug handles the daily standing ovations the team gets at 5pm!
"I get to be very productive”
“One of the things I love about working at FOODit is that I get to be very productive,” says Anca, who’s one of our in-house developers. She’s been working here at FOODit HQ, nestled in the heart of Shoreditch, for just over a year now. “For us, it can be less than one day cycle from starting work on a feature to sending in to production.”
The life and times of FOODit’s backend developer team
It wasn’t always like this though. Since FOODit started in late 2013, how our dev team works has evolved along with our needs as a company - which have changed quite a lot, as you can imagine! When our founder Rif packed it all in to set up FOODit, we had next to no employees, and after some experimenting, we decided to outsource the development work to a team in Australia called 3Wks. They worked with the cloud-based Google App Engine, which you can read more about in ‘How I build the same MVP 3 times’
We’ve always prioritised working with Google App Engine, so all our data, from this blog post to our CentralDish app is kept on the cloud. Because we want to focus on delivering our products (rather than maintaining our infrastructure), we get a lot out of Google Cloud Platform’s suite of integrated products. They’re immediately available, maintained for us, and because we use lots of different services, we can pick which one we need to address our individual challenges. We particularly love DataStore, BigQuery, and the Task queues.
Using the Google Cloud Platform
What we love about it, and what we don’t love quite so much about it...
Even though we had a really smooth set-up with the Sydney team, we always knew we’d need to bring our dev team in house so they could work alongside our product managers and designers. Soon, we were totally focused on finding the right people for our new in-house dev team.
Which brings us to Anca, who was one of our first in-house back end developers.
How Anca found FOODit
Anca has been working in our dev team for over a year now, but she found us almost completely by luck, much like how she got into programming.
“I know most developers have this cool story of how they wrote their first program at the age of five, but I got into it almost accidentally.
In Romania (my home country) you need to pass a few exams to get distributed into the high school ‘specialisations’ - sort of like A-levels. So I ended up in the Mathematics and Informatics class, which in my hometown was considered to have the best teachers. I realised I really liked programming and so ended up studying Computer Science in university too - and the rest is history.”
When we met Anca years later, it was all because of our use of Continuous Delivery, a process where code is constantly pushed out and published. It’s a rarity for a tech company, and it’s exactly what attracted Anca to us in the first place.
"I wasn't really looking for a new job. Then I noticed FOODit's Continuous Delivery dashboard"
“I was at the Silicon Milkroundabout jobs fair, I was just having a look around. I wasn't really looking for a new job. Then I noticed the Continuous Delivery dashboard at the FOODit stand, so went over to find out more.”
Why our dev team works so well
When Anca joined us as a developer, she became a part of a team that’s always striving to improve its processes and cut down on unnecessary extra work, aiming (eventually) to become one super slick, well-oiled machine.
There’s lots of ways we do this. Our morning stand-up helps keeps lengthy, frustrating meetings to a minimum, while demoing new features to the whole company every day at 5pm - often to a round of applause - makes for a properly satisfying finish. We also use Slack to keep in touch, and have a very healthy respect for remote working.
When you have colleagues interacting with each others code on an hourly basis, it’s crucial to work closely together. “We review and discuss each other’s code in a very collaborative way,” says Mick Dudley, who leads the development team.
"I get to solve cool and diverse problems"
Combining teamwork with a richly challenging role is something Anca really appreciates:
“Not only do you get to solve cool and diverse problems, but you always have to strive to write your programs in such a way that the next person looking at your code will quickly understand and change it. Writing software can be highly technical but it’s also an art, so you need to be creative too.”
My life as a dev for FOODit
We’ve asked Anca to let you know what a typical day is like, so you can get a feel for the rhythm of what goes on behind the scenes.
Getting to the office each day
Every morning, I get on my bike (even if it’s raining) and blitz past the tube commuters and cars stuck in traffic. By the time I get to the office, I’m feeling so awake I don’t even need a morning coffee. We also have secure bike storage in the office so I don’t have to worry about my bike being stolen.
Sometimes I work from home. I’m so pleased that everyone at FOODit is offered the flexibility of remote working, and our work set up means I can write and push code from any computer.
The morning stand-up
The atmosphere in the office very much depends on what time I arrive. Usually, it’s after 9am so it’s already bustling with people going about their day.
Our office is the opposite of quiet, but then again so is our work schedule, so it feels more natural to hear people talk than just quietly tap at their keyboards (which would probably even be a bit unnerving!)
We do a morning ‘stand-up’ where everyone quickly summarises what they’ve worked on the day before and what the plan is for the day ahead. We have a couple of people working remotely so everything is done over a video call on Hangouts. That way we sometimes get a little bit of Spanish sun through Joachim’s camera or a taste of the cold in Russia (Semyon sometimes wears a coat in the summer).
Thanks to this, we rarely need to have those impromptu time consuming planning meetings that every developer always tries to avoid at any costs.
Then we do a review of the code we want to push in production on that day. It’s a good way of touching base with everything everyone has been working on, and it means that we quickly get familiar with the new code.
Breaking for lunch
Lunch time is usually the time for catching up on some reading on my Kindle or tech articles people link to on Slack. I’m quite lazy and don’t like to spend time food hunting, so I’ll just have a sandwich or a salad.
I have to stress that compared to my foodie colleagues, I’m pretty unusual. Compared to me, they’ll always try out the latest lunch menus on CentralDish or one of the many open air food markets around the office.
Then after lunch, I usually sit down at my desk with a tasty coffee and happily code away that day’s piece of work.
My daily workload: test, code and demos
There usually isn’t a ‘big’ task for me to work on, and a side effect of us releasing so often is also that our tasks are usually day-sized. So most of the time by the end of the day I’ll have finished developing and testing the feature or bug fix I’d started on that morning. There is nothing I find more rewarding than going home feeling that I got something done and ready to go live the next day.
Given that we have both a front and back end team, new features affect both, so we always plan for each team.
We keep our code in Git, allowing us to make all changes for a task on a branch on our local machines, and also keep a history of the commits (very important!). Then, when we're happy with the changes, we'll push the code to the remote Git server.
Once that happens, our customised Continuous Integration tool, which runs on Jenkins, will automatically run a series of tests against the new code - unit tests, integration tests, smoke tests. Or if it’s for the front end, we’ll run a functional test with Selenium and Protractor.
The final bit is the code review, which we do through pull requests on Github. Thanks to its interface, we can approve and merge changes into (the common) development branch while we are still in the code review meeting.
Finishing the day with a round of applause!
Demo time is at 5pm every day, and it involves showcasing the new features we’ve recently released. It usually triggers a round of applause from everyone and the occasional indignant, but very cute barking from Krumpet, the office pug.
I try not to stay late, so I usually leave around 6pm. We rarely get production incidents, though they will sometimes happen, and in that case one or two people will stick around for a bit longer to try and fix them. After work I sometimes head to the gym, spend time cooking with my boyfriend or going out with friends.
Why working at a startup is different
From my POV, working at a startup means I have more responsibilities than in a traditional corporate environment. Things change much more quickly.
In terms of my skills, I get to write more code than at my previous jobs, thanks to being able to ship features faster. I’ve learned a lot from my teammates too - both in terms of software craftsmanship and also how they go about tackling harder problems.
"Being part of a startup is really exciting”
I wouldn’t be able to pick just one favourite moment that happened since I started, but I was very happy when our integration with a new payment provider (which I had done the backend for) went in for production without a glitch. So many things happen every day that it’s hard to single out my favourite moment so far.
It can be really challenging dealing with constant change though. As a startup, we’re doing a lot of experimenting, so often we have to write code that we already know is going to change pretty quickly. This is also a good thing, though, because it forces us to think about good, flexible design which ultimately leads to better code.
