My First Steps as a Mobile Developer

– or how I ended up hiding dirt in lockers and what I learnt from it in the process.

When I first set out in search of a temporary position within IT, eager to learn how to code, I figured it would be comforting to be working on something that was based on a binary wrong-or-right logic. With a background in marketing, I was longing for such a concrete set-up, freed from opinionated decisions, but instead dictated by the principle of functionality. Either it works, or it does not — there is no in-between and you get to know almost instantly.

(In order not to incur the wrath of fellow marketeers everywhere now, I must add the disclaimer that of course marketing also has quantifiable criteria on which to base decisions. Just… not as many and eminent ones).

Now, four months in I can confidently say: I erred in a lot of ways.

First and foremost, being told whether you are on the right or the wrong path is in fact comforting — however, mainly when you are on the right one and much less when you are on the wrong one. I spent hours googling the manifold error messages staring at me from the command line in bright red.

What no one ever tells you: the real troubles lie in between the white lines, rather than the red ones. In a way, red error messages are upfront with you. They tell you in a concrete and concise way what’s bothering them, making it relatively simple to fix (or at least google). If you were to personify white error messages, on the other hand, they’d be those snotty little creatures that let you clearly sense that something is bothering them, but they refuse to tell you what exactly. Much rather, they hide what is bothering them under lines and lines of messages, forcing baby developers like myself to wade through the output line by line, unaware of what they are looking for in the first place and (at least in my case) correspondingly unsuccessful in solving the problem themselves.

But let’s start from the beginning, rather than from errors and problems (a focus that developers are apparently especially prone to, as I was told). I partake in a young talents program at the Swiss Federal Railways SBB CFF FFS that consists of four rotations in different departments of our own choosing. In this context, we are encouraged to not only apply what we know, but gain work experience and skills in areas outside of our comfort zone. This opportunity at hand, paired with the importance of basic programming skills rising by the hour and my own being limited to formatting text with HTML tags, I set out in search for a team which would take a chance on me.

As expected, for the most part, people were skeptical. After fending off several attempts of nudging me toward business analysis projects in place of any sort of programming, I found a mobile development team willing to offer me the sought-after environment, with the liberty for self-learning, an independent coding project, and mentoring on the way.

My first six weeks in IT I spent working through an online Flutter bootcamp. Working through the lectures, I learnt about the fundamental role of widgets and Flutter’s cross-platform compatibility. I learnt how everything’s arranged with columns and rows, how to include images and animations, how to embed APIs or store user inputs in Firebase. After six weeks I received my certificate for the successful completion of the course and was equipped for … absolutely nothing in real life. Or at least it felt that way. Like I had only scratched the surface of an immense pond, where I didn’t even know how far down the bottom was. “I am aware that I’ve only completed a beginners’ bootcamp, with no expectation of knowing it all now — but I feel as though I know nothing!”, I told my senior co-developer. “That’s normal. I still feel as though I know nothing, too”, he answered with over a decade of working in programming on his back. It was a realization somewhat comforting and disillusioning at the same time, but ultimately typical for languages, whether programmatic or natural. In either type, knowledge becomes more extensive, but never exhaustive — how could it, given that languages are transient?

But of course, I wasn’t talking about those last couple of percent. I was talking about lacking the grasp of substantial concepts, such as state management. I spent a considerable amount of time trying to figure out how to make use of functionalities from other files and classes, an endeavour so seemingly basic and natural that it was frustrating failing at it. While googling possible amendments is always the first step (StackOverflow is your friend), having someone look over your code and point you toward your mistake is invaluable. Because no matter how many hours I searched the Internet and how many things I tried in my code, I did not resolve this basic matter. How could it be so hard referencing existing and working code?! One time after another, I got stuck at this point and depended on my co-developers to untangle the knot, just to feel absolutely helpless again the next time I needed to reference a class. Then, something strange happened: things just fell into place. I woke up one morning and implemented a feature, by myself, successfully applying concepts that I had been struggling with so far, as if up to that point my learning curve hadn’t had less gradient than the Netherlands.

But what did I actually code during my guest appearance in IT? Glad you asked.

A version of the iconic 90s game Minesweeper, thematically adapted to and hidden somewhere in the depths of the (company internal) Repair & Clean app. In other words: I virtually hid dirt in lockers. I started out with the UI elements, formatted the boxes (lockers) and a top bar housing additional buttons and displays. So far so good. But once that was done, things became more difficult. I had a fair idea regarding the game engine but implementing one myself was a different story. Luckily, as with most things, someone else had already done it — and posted it online. Eager to apply what I had learnt and full of ambitions, I intended to only sneak a peek every once in a while, when I’d get stuck while figuring it out on my own. This ambition lasted about a day.

Turns out, copy pasting constitutes a big part of a developer’s work, as I realized from my colleague’s reaction to my shamefully admitting that the code had not emerged from original thought: “Copy paste is the way to go; there’s no use in investing energy into solving something by yourself that already exists.” I guess ultimately my ambition could be regarded as a false belief, placing originality over efficiency — a philosophy probably no developer has the time for, given the shortage for this occupational group.

Speaking of efficiency: working in IT I was of course also exposed to agile working methods, namely an adapted version of Scrum. I learnt that the vaunted word agility does not necessarily entail efficiency. The team dynamic within an agile working environment reminds me a lot of gear wheels, with team members all working on small portions of a greater, narrowly defined goal. In this context, my team would hold daily, short stand-ups and weekly, day-long refinements. To stick with the metaphor, the dailies and refinements are the oil that keeps things smooth and ensures that everything’s properly aligned. While I get the theory behind it, I still doubt that having a fixed daily meeting where everyone summarizes what they’ve been working on in the last 24h is the most efficient way to go. Those dailies could have been a text (or a Jira allocation). And regarding the refinements — have you ever heard of such a thing as an efficient day-long meeting?

As mentioned before, efficiency is a principle held up high in programming. There is an incredibly tight focus on maximizing functionality while minimizing the number of lines of code. In daily business, this principle would often be transmitted to me via the words “yes, but…”, followed by yet another way to optimize the functionality-length ratio of (or in short: refactor) my code. In that sense: there is no right way — but many wrong ones.

One thing adding to the difficulty (and I would therefore not advise for baby developers as myself), was starting off with a package as my first project. It is insanely confusing that simple things that had worked perfectly fine during bootcamp would suddenly not work anymore, despite reproducing the behaviour that had worked dozens of times before. Documentation and articles on help forums are considerably scarcer for package problems and can be hard to find and solve when not that familiar with the documentation in general yet.

But at the same time of course, once having overcome these additional hurdles, it is great having coded a package that theoretically can be implemented in any app. Because ultimately, this is what I ended up with at the end of my 4 months in mobile development: a quirky game embedded in an official application that I can shove in people’s faces, saying “I made this.”

Key Learnings:

• StackOverflow is your friend — but so are your co-developers
• There is no right way — but many wrong ones
• Learning to program is an endless endeavour
• Programming a package entails some special quirks
• Agile work methods are not necessarily efficient
• You do not get cookie points for coding something by yourself that could have been copy pasted
• In IT, everyone is in fact always busy