My experiment to get the most out of my side job

A side job as a student. It’s great to learn things next to your studies, but it can also be a burden. How much time do you even have for a side job? And what kind of job are you applying for? What do you want to learn? Even if you’re only working 12 hours a week, can you add value?

I learned all the ins and outs of Easy LMS and grew as a back-end developer

Personally, I wanted to do something that has added value next to my studies in computer science. Easy LMS, being a software company, seemed like the perfect fit! After my 6-week summer internship, I stayed for 12 hours per week, the number of hours I had left next to my studies and other activities. For a little over a year, I learned all the ins and outs of Easy LMS and grew as a back-end developer. Together with my team, I worked on so-called stories with new features or other improvements, coming directly from clients and impacting people from literally all over the world.

Learning stagnated

I noticed that my limited hours started to conflict with my desire to develop myself

After running through the process of developing new stories with my team for a little while, I noticed that my limited hours started to conflict with my desire to develop myself. One of the first signs of this was the fact that I could not always finish the features or bugs I worked on. The team simply had to wrap up stories while I was not working to meet our aim of finishing a story in four days. In essence, not a big problem, except that I couldn’t see and experience some critical steps required to make a new feature work and keep the code quality high.

Duplicated work

Let’s make my point more explicit with an example. I once was busy with a new feature that allowed clients to send notifications more easily. I worked on this for three-quarters of a day, and at the end of the day, I felt I was almost there. But time was up, so I went home. The two days after, I was off. When I signed on again on the third day, I saw I had been working in the wrong part of the system. During my days off, my colleagues were progressing with the story. They wanted to complete it to bring it online, so they continued with the things I worked on. Pretty much all of my code had to be redone by a colleague since the part of the system where my code should have been, required quite a different structure. Not a problem at all, but still quite a shame! I could look at the pull request (PR, the final code changes) and see how my colleagues solved the problem I had worked on, which allowed me to learn a lot.

Sub-optimal feedback

Another limitation was that I could rarely see direct feedback on code that only I had touched. Of course there were code reviews, but this was also on code that was touched by others. Furthermore, I also received feedback along the way, which made it more difficult for me to see what I could improve specifically. Of course I looked at code reviews, and of course I could see what the code of my colleagues looked like, but this is not the same as fully developing a story on my own and then seeing where my code lacks quality. Together with Markus, my colleague and coach, we concluded that this way of working was flattening my learning curve.

We decided to start quite a rigorous experiment

Experiment!

We decided to start quite a rigorous experiment. While we are usually very keen on working in teams to be able to learn from each other, from now on, I would be the only developer working on my stories. This would force me to run through the whole process. From the moment a client comes to us with a feature request to the moment that same client can use their requested feature.

New process

Alright, my own story. How do we start? How do I scope this? What steps are necessary? Which parts of the process are not relevant? Are there rabbit holes in this story? Only a selection of the questions that were crossing my mind, now that I worked more individually. At that moment, we had two different flows for such a story: the simple flow and the full flow. The simple flow was meant for smaller improvements (like some settings not being saved correctly or an invite link that leads to a 404: Not found error) and should be finished within two days, including everything like discussing, scoping, developing, testing, and deploying. The full flow allows you to spend more time on the improvement, which is usually a bigger one like creating a preview for a Course slide builder and can take up to four days. We decided that I would start with stories in the simple flow to make it easier to keep an overview.

Learning opportunities arose

At the start of the experiment, I decided I would just start by writing a plan for the solution and then start looking at the code to see what I could do, and it would flow naturally from there. This didn’t turn out to be the best way though. I needed four days to run through the whole process completely. Twice as much as was ‘budgeted’. Not a problem, as long as I would learn from it.

I did! The following story took me 3.5 days. Baby steps are steps nevertheless! However, now I missed a step of the process. In this story, I added a new text label for a feature. These labels are translatable and should always be checked by a native speaker, which I am not. When I moved my story to the following stages of the process, I noticed I came across the status In label review. I knew of the existence of this state, but what it would entail? No clue. Naive as I am, I decided it would probably not be a problem if we just skipped this step, so I pushed it through. New feature online! Another happy client!

However, the next day that I was working, I saw a message from a colleague: ‘Can you still add some information for the label review? And next time, don’t move it to the next state. This causes me to do some extra work ’. Oops… Apparently, that step was actually important. Another learning opportunity…

Learning accelerated

I saw that the slope of my learning curve was rising again

Several other things happened, but Markus and I saw that the slope of my learning curve was rising again! I finally received code reviews on code that only I touched, significantly improving the quality with which I write code. Furthermore, I slowly started to become fully aware of the whole process and all the different paths within it. I was getting better at scoping and making trade-offs and spotting risks and (virtually) impossible requests. After only two months, I grew enough to finish most stories within the budgeted two days while also delivering quality solutions.

We look at how every individual can thrive the most

Seamlessly working part-time

Within Easy LMS, we look at how every individual can thrive the most. This differs per person and can even vary from time to time for the same person. The beauty of this solution for me at this time is not just the fact that it allowed me to grow as a developer. It also allowed me to find a way to work only 12 hours a week (of which I can only spend eight-ten hours on these kinds of stories) without holding my colleagues back. I can receive code reviews asynchronously and ask for help when I’m in. But when I’m not in, my colleagues don’t need me to see where I left off and where they could continue.

We virtually now had two teams within a team that could work in parallel while still having the advantage of sharing knowledge and collaborating. Which eventually does not just benefit my performance at Easy LMS but also in my studies.

I can increase my software development skills without having the need to have a fixed and over-predictable schedule. During an exam week, I can work a little less. In easier weeks, I work more. My colleagues are not held back when I’m not around, and neither is my learning when I am around. A win-win!