My name is Tom de Ruiter, I’ve been working on iOS apps since I was 11 and I joined bunq as an iOS Developer about a year ago as one of the youngest employees at age 17. Apart from my age, what made me different is I’m completely self-taught, I do not have any Computer Science degree and started programming on my own.
When I finished high school, I started working as a freelance iOS Developer for various clients. I gained some experience about how a business would develop and structure a mobile application and because of that, I had some ideas about how bunq would develop its iOS App. But when I joined bunq and saw the codebase for the iOS application for the first time, a few big differences jumped out at me.
Depending less on dependencies
Before, when I started working on a client’s iOS App, I got handed over a big pile of files with a huge list of dependencies. Dependencies are basically small blocks of software that you do not develop yourself and are made available by someone else. Your development essentially depends on it.
Though this might save you time, it actually kills your versatility when developing new features. As soon as a Product Owner or Designer asks you to change something outside of the capability of that dependency, you’ll most likely have to redo it yourself. That’s why we try to keep our dependencies to a bare minimum. By literally writing every line we ship, we have one single source of truth (being ourselves) in case we hit bugs or other surprises in our code.
This also saves us precious development time by not having to read documentation and following a different programmer’s ideas while developing new features.
This was quite new for me. Most of my experience and those of developer friends I knew were using a lot of these dependencies. We thought this would improve our development time. When looking at the pros and cons now, I can say that developing everything yourself has certainly the most pros.
Merge requests and working as a team
In an environment where you’d mostly work alone, you barely ever have to deal with code review. You basically create something and immediately test and/or ship it without thinking twice about how you’ve implemented it.
To be honest, I didn’t fully know what code review entailed when I started here, but I was quickly confronted with it when I submitted my first Merge Request. This is a summary of the code changes you will make. Someone else in your team can take a look at these changes and decide whether to accept and merge the request or to reject it and leave extra comments on it about the way you’ve made these changes.
This can make sure that even before a structural flaw or bug will arrive in the app, it can be filtered out by someone else. My first Merge Requests had lots of comments in them, though this quickly reduced while I was getting more comfortable with the codebase.
Working together as a team was quite new for me, but code review certainly has made my code a higher quality and forces me to think thoroughly about a certain change I’ve made.
Adapting to a new environment
About a year ago, this was all new to me. It took a couple of months to really adapt to the new way of thinking and working, but now, I can say that it definitely improved my iOS development skills and they make a lot of sense.
Especially as a self-taught developer, when you have no real way of working except the one you developed yourself, it might feel annoying to have the change the way you work.
When you understand and see the reasons why certain things are better to do than other things, it’s a lot easier to accept the new way of working and adapt to it.
Tom - iOS developer
{{blog-cta-5-minutes="/blog-cta/5-minutes"}}
