What my first job taught me about process

3i Solutions was my first job. I worked there part-time from September 2022 to April 2023, while I was finishing university. It was a good learning experience, with good parts and bad parts, and I want to be honest about both.

The project

3i is an Albanian company. It had a deal with a UK company whose app is used by hundreds of schools. The app existed as two separate apps, one for iOS and one for Android. Two apps meant two codebases, so every feature and every bug fix had to be done twice.

Our job was to bring both into one React Native codebase so it would be easier to maintain. That’s the usual reason to pick React Native: one codebase and one team, and a change ships to both platforms at once.

What went well

We did it. The move took about half a year, and at the end there was one app instead of two. Maintenance got a lot easier, about half the effort, because a fix now landed on both platforms at once.

We also added Sentry, which reports crashes with the stack trace and the device they happened on. Seeing crashes and their causes helped us cut them by 25%.

There was no backend work, because we used the existing endpoints. That limits how much you can change, but most of them were fine, and it let us focus on the app.

For me, the biggest thing was ownership. I was still a student, and I was working on a production app that real schools used every day. I didn’t have much React experience, and even less React Native, so I learned both by doing, on a codebase where my changes went out to real users.

What was hard

The same ownership had a downside. The team was two fresh graduates, me and one other, owning the whole project. A senior engineer got involved maybe once a month, usually to do a big refactor. He was also the only one reviewing pull requests, so most of our code went out with very little review.

There were no standups, and the work was quite ad hoc. There were no automated tests either. A QA team tested by hand, which catches a lot, but only what someone thinks to try. And we didn’t use Expo, which today I think is close to the only sensible way to do React Native, because it handles builds, native modules and updates for you.

The result was an app that worked, but with no shared standards in the codebase, so it wasn’t as clean as it could have been.

Most of this came from the setup: a small team, two juniors and a part-time arrangement, on a fixed project for a client. Nobody was doing a bad job.

What I’d do differently

If I did the same project today, I’d change a few things early. I’d start on Expo, so the time goes into the app instead of native builds. I’d add tests from the first week, even just a few. I’d ask for regular reviews, even short ones, and the two of us would review each other’s code in the meantime. We’d agree on a handful of code standards before the codebase grew, and we’d have a short check-in a few times a week, so problems came up early.

How I work now

At Canonical it’s very different. We have proper code reviews and standups, and testing was part of the project from early on, which I wrote about in [Testing a large React app].