8 things I’ve learnt from my first year in mobile development
Some reflections after transitioning from one discipline to another…
Richard Chernanko
Nov 26, 2021 . 8 min read
Some reflections after transitioning from one discipline to another…
Nov 26, 2021 . 8 min read
It’s a Friday afternoon. I’ve just made a cheeky cup of tea, and I’m in a good mood (my football team is yet to play) – it’s time to write.
I’ve not done this for a while, but a year into a new role is definitely a good time to reflect. This post will look at some of the things I’ve learnt in moving from backend to mobile app development, along with a few other random thoughts based on my first year at LOTTO24.
No, I’m not talking about the “we don’t actually want to score any goals” tactics of my beloved Tottenham Hotspur, but rather the fact that I’m in the process of making yet another transition into a different discipline of software development.
In the last seven years I’ve gone from:
And it’s this last one that I’m currently going through.
There’s always a question of whether it’s better to be a generalist or a specialist. Quite frankly, I’m not 100% sure on what the right answer is. It probably differs from person to person. My short-term take – I like to try new things, and so when opportunities come about to do something different, sometimes I just go for it. I loved test automation and backend development, but I think that it’s nice to build up a breadth of knowledge across disciplines. I can try lots and lots of different things, and then one day I can then potentially narrow down my focus. That’s how I see it anyway.
And so that’s essentially how a role in mobile came about. The opportunity to try something new was there (UI development), the company and its culture felt right, and so I thought why the hell not.
End of context.
Hold your horses Rich, this is actually a tech blog…
Here are my top 8 work-related takeaways on the transition to mobile app development and my first year at LOTTO24 (in no particular order):
This one doesn’t solely refer to the last year, but to the general concept of transitioning from one thing to another. Making these kinds of jumps is scary. Like my previous transitions, I had absolutely no experience in the thing I applied for. Throw in the fact that the job would be remote (I am in Hamburg but hey, Covid-19 restrictions), I was quite frankly sh**ting myself before starting the role. How would I fare?
Before accepting the job offer, I tried to make sure of two key things – were the people in my potential future team right, and would I be supported in my learning of a new discipline? From my on-site trial day, I knew the first part was fine. And as for the second part (here comes the sales pitch), I must admit that the company has been excellent. My colleagues and I have done countless pair programming sessions and they’ve always been there when I’ve had questions that needed answering, or to explain concepts that have not been fully understood the first time around. They’ve shown a lot of patience with me and this has been most welcome. Even working remotely has gone as smooth as I could have hoped for.
A year in, and I think it’s safe to say that things have gone ok. Having done this kind of thing a few times now, I’ve been fully aware that there are always going to be downs as well as ups. It doesn’t always run smoothly. There have been and will continue to be times where I am pulling my hair out. But hey, welcome to the world of software development.
To cut to the chase – if your attitude’s right and you’re backed by a good company and colleagues, the jump is not as big as you might initially think.
This has been an interesting one. As a backend developer, if you release a change and it breaks something, you can just release a hot-fix immediately. With mobile apps, this isn’t really an option. If you release something into the wild and it’s not working as intended, you then have to go through an entire upload / approval / release process again. In my experience, the process for Android is not too bad but Apple reviews can sometimes take the same amount of time it’s been since my football team last won a trophy (13 years and counting…).
This has definitely required a change in mentality.
Naturally, there are ways to mitigate the risks. We’ve a vast number of automated tests, a thorough manual testing process, we use phased releases and we monitor crashes and error logs after a release. We also have a proxy-server (Kong) that allows us to change the responses that are returned to our apps. But of course, sometimes bugs or unexpected knock-on effects slip through, and it can be quite annoying to then have to wait until users are using a ‘fixed’ version of the app and no longer the buggy one.
Swift is a nice language, I must say. Naturally I still need to wrap my head around its many intricacies, and of course, I have not learnt / do not know everything about the language, but my initial impression is good. The things I like the most are guard lets, enums and exhaustive switch cases. Especially the guard lets. Oh yes, I do love an early return, especially if it results in one less if / else statement. I frigging hate them.
It’s still taking some time for me to get fully used to things like UI view lifecycles and architectural best practices (e.g. MVVM), but this is just a question of practice makes perfect. I haven’t really had much of a chance to work with Kotlin for our Android app, but this also strikes me as being quite nice to work with. It’s definitely great to be working with what are considered ‘modern’ programming languages.
I honestly don’t even know where to begin with this one…quite frankly, I don’t like Xcode as an IDE. It feels ridiculously heavy and slow, like a dying-old man trying to run a marathon. The number of times I’ve seen that horrific colourful spinning wheel of death pop up on my screen – it drives me mad. The caveat here – I’ve never used an IDE for UI development, so perhaps this is just the norm. And quite honestly, I am used to using JetBrains IDEs and I am comfortable with them. That being said, I must admit that I have gotten somewhat now used to Xcode, and it does offer pretty much everything you’d want for iOS development in one place. But I don’t think I will ever fully warm to it.
And despite this, it has a big perk – it’s free. It costs nothing (minus a high-spec MacBook of course…). And that’s the thing I need to remind myself when whining like a spoilt brat (see above). Of course I could just buy an account for AppCode, but when everyone else in the team is using Xcode, I don’t think that this is a good idea. And like I said, I have gotten used to it, that’s for sure. But unfortunately, the fact that Xcode is free is something I am constantly having to remind myself when it either crashes or causes my laptop to burst into flames.
Pretty obvious I know, but not something I really had to worry about when building APIs. Of course, I needed to ensure some kind of backwards compatibility, but that wasn’t so much of an issue. But yes, if there’s a certain percentage of your users still using a 4-year-old operating system, you need to cater for them. It’s sometimes a little annoying as it can stop you from adopting newer libraries and frameworks, e.g. SwiftUI, but I must say that we are quite good at regularly checking the versions we no longer need to support, and then removing them. So at least we have a good strategy there.
I’ve had the opportunity to work on some features this year that have involved me interacting with things like App Center and fastlane. The latter in particular is just absolutely fantastic. It really can speed up your workflow and eradicate a lot of manual processes (I promise I don’t work for them on the side). I worked on a ticket that resulted in us using fastlane to automatically manage all of our certificates and provisioning profiles for our iOS apps. And this is just brilliant, it will save us so much manual effort in the future. Love it. Tools like this mean that you can spend less time on the dull stuff and more time actually working on your apps. So therefore, my first impression of the tooling available to the mobile community is very good.
I will focus on two things here – communication and delivery. I won’t talk about software design patterns and architecture etc, I think it goes without saying that e.g. the DRY principle is as valid in backend development as it is in mobile.
Over time, I’ve come to realise that one of the key things in any discipline is communication. It’s essential to make sure that everyone in the team is aligned and that we all have the same expectations, especially regarding how long something is going to take. Because if there is a misalignment, something is not right. And you know what, at some point the sh*t will hit the fan. I think my team is pretty good at this – we are a relatively new group and so we had a few teething issues at first, but we have gotten much better of late and are in a good flow. And that’s somewhat of a relief.
This year has also reminded me to always think about how to break down features into smaller chunks. This is true of even mobile development, where you might not simply deploy every tiny change to production. But by splitting things into sub-tasks, you may be able to release certain parts of the feature to users while continuing to develop the rest. Therefore, you start to see some value and receive some feedback much earlier. And you can also demonstrate that you’re making progress on something, which is always a useful thing to be able to show.
It’s interesting because I got pretty good at this in my previous role, but I think when you start something new, you sometimes forget the basics. You’re so focused on fitting in, you’re taking on so much new information, and you just want to get your head down and crack on with things. At the beginning of my time here at LOTTO24, there was an instance where I didn’t think about how to split things up and I then got frustrated when something took a long time to deliver. Had I thought about better splitting it up into deliverable chunks in the first place, the frustration wouldn’t have been present. I’m not sure why this happened to me, but it’s a good lesson learnt. I will 100% not be making this mistake again. Always think about how to split things up.
I am 100% sure that I am not alone in dawning upon this realisation in the last two years. When I worked in the office five days a week, I always walked at least an hour a day as part of my commute. Working remotely in this last year (especially during that slog of a second lockdown in Hamburg) has taught me that it’s massively important to continue with that. There was a period where I’d injured my foot after running and so couldn’t walk properly for a couple of weeks (and couldn’t run for a while longer). I got lazy and wasn’t leaving the house as much. And I then became shocked at how much the lack of physical exercise impacted my mental wellbeing. Don’t worry (I’m sure you’re not) – there were no major issues, all is fine, but I couldn’t quite believe it. Therefore, now I absolutely make sure I get my backside off the couch, and take a walk for at least an hour a day. And it works a charm.
And that’s your lot folks. The top 8 things I’ve learnt from this last year. Congratulations if you made it this far (I like to waffle).
If you’re also looking to challenge yourself, why not have a look at our open positions, Hamburg’s a great city 😉
Until the next time…
Nov 26, 2021 . 8 min read