I was hired right after graduating without knowing anything about my company’s field. My manager was aware of this, but they didn’t mind it. One reason could be that everyone can learn virtually anything given enough resources. More realistically, in my case, I’ve probably provided enough evidence that I wouldn’t consume too many resources before becoming somehow productive. Retrospectively, it was easy to reach that stage because many small, independent tasks didn’t require a detailed context. In time by solving them, I laid the building blocks of my domain-specific knowledge, duplicating what my colleagues already knew. Task by task, I’ve grown my understanding and managed to attribute meaning to the data my code would process. The approach has benefitted both my team and me: on the one hand, I have been constantly motivated to learn by doing, while on the other hand, my team had the time to focus on tasks requiring more context. The limiting factor of this approach is that I’ve only got so far. Same as uni, where it’s better to go through the lecture notes before attempting the problem sheet, I’ve found that learning by doing is not a sustainable learning model. To go past the barrier, I had to delve into the complexity and find the right resources to help me navigate the maze. It turns out that navigating mazes is a valuable, encompassing, and versatile software engineering skill.

Uni was great at teaching me how to learn: I’ve progressed from considering the lecture notes the professors put together as a standard to researching papers and exploring fields on my own. Besides coding, this might be the most relevant skill I’ve been taught during my degree. I remember getting upset when the lecturer wouldn’t provide their notes to the class. Coming from pre-uni school, I expected there to be a single book containing everything I was supposed to learn. I had no idea that the more you progress within the school/academia ecosystem, the less each field is standardised. At the extreme, there could be multiple candidates for a standard, each trying to prove how they’re better than the rest. I have experienced this first-hand as I’ve progressed to more advanced topics. I have even taken part in a novel course linking CS to a humanities subject, the first of its kind. I was part of the group trying to define the standard! In the same vein, my dissertation has been the one part of the degree that has enabled me to spend considerable time researching cutting-edge knowledge in the field. The goal was to contribute to research, taking it one step further by sharing my results. I didn’t get that far, but the experience was formative.

Comparing school to my professional career, I’ve started on a similar trajectory. In the beginning, it was looking at and imitating others, effectively learning to use the vaguely right language my colleagues were using. Then it was understanding the terms to their core and forming a picture of the clear, undisputed territory by going through books and manuals. Then I moved onto the edge of the technology, for which the documentation had only a few paragraphs. Even StackOverflow was unaware of my questions. It’s the stage where only a few unpopular forums mention the matter, and the discussion doesn’t progress for more than a few comments. Finally, it’s extending the picture by consolidating or introducing a vague, under-used standard. I’ve only done this for one part of my job when enhancing the company-wide translation between languages. In my short experience, all projects go through this process, but, of course, to various degrees. The moment one realises this is how learning works, the moment they start appreciating the whole process more. From the beginning until now, embracing and exploring the complexity has been crucial for my job.

On the concrete side, I remember taking the step from learning from my colleagues to learning from books. I was stumbling through the company’s library and judging books by their cover. After gathering a pile of five, I chose the one with comparatively the best online reviews. I later discovered I made a good decision, as my mentor had read and recommended that book. But even if my decision had not been optimal right from the start, I would have probably learnt some parts of the field and then chosen a more appropriate source. Books’ suggestions and references list usually give a good potential next step when my reading stack gets empty.

To sum it up, learning and getting the context keeps me going. I would hate a job where I’d be doing the same thing on repeat. Lucky for me, most software engineering jobs are not like that. They were right when they said learning doesn’t end when the degree does.