Starter info

If you already know about me, you can skip this section
Firstly, I am a student of a Software Development degree. I will graduate in 2 more semesters. I am currently in my 2nd semester of co-op. In Winter 2021-2022 I have taken a course called "Open source Project", which involved all of us students working on this single open source project - Telescope. This project uses React, docker, docusaurus, supabase, and other tools. In the end - it was up to us, students to take it in a direction we want to evolve it in.

Real experience

So what was so special about that class?

Team size

Firstly, it was the amount of people working on a single project. That semester - it was 17 of us. So far the biggest groups we ever had were of 4 people. We had longer projects before, where we did planning and implementation over several semesters within the same group. However, it was never that big before.

This emulates a more realistic work environment. Currently, in my co-op, I am a part of a ~20 person team, all have their roles, but all work on a single tool. We all communicate between each other, ask for help, information, updates, arrange meetings and get to know each other.

Existing codebase

So far in our college assignments, even if those were larger projects, and even in our personal projects - we always had to start anew. No matter what our task was, we create it from 0, and usually we get pretty familiar with our own code and tools.

With Telescope - that was way different. We already had a working application that was handed onto us by the previous class. We had a lot of code, tools and decisions that we have never seen before, and we had to adjust to that environment. We also had many of their older problems, bugs and unexplored directions.

That, again, simulates a realistic work environment well. You will be new in your team, while they all have made a lot of progress. You will see their code and will have to understand it, and change it to add your own improvements. Learning to integrate into an existing environmnent is a very useful skill to develop.

Freedom of exploration

With college - you don't get much freedom. Most of the time - you have a specific task, with specific instructions and concrete tools to implement it. We did have some freedom in our other classes... sure. In our larger project, we got to decide what to develop. However, time and knowledge constraints usually led us to choose a familiar path. If we want to deliver a product for a grade - in the end we better stick with a tool we can rely on.

Telescope, however, embraced exploration. Not only we didn't have a definite task - we were the ones to decide what the tasks will be. We got to choose what to work on personally, and could even come up with tasks we would assign to someone else. It's not only the tasks, but also the tools. Want to add a completely new framework? Use a new language? No problem. It's on you to make it work, but it is allowed and is supported - us, students, like new toys to play with. If you yourself get excited with using this shiny new language - others will get excited to help you.

Management

Now, my favorite part.
In college, we never get to be the boss. You usually deliver to your professor. And even on your co-op, or some freelance work - you are usually the newcomer, the noob, the lowest of the foodchain. You are never the one to make decisions.

Telescope made us temporary managers. We had to lead weekly meetings, and were responsible for that week's progress. You had to know what was going on. You had to make sure people do their jobs. You were the one to say - "no, let's focus on this and not that". And it was awesome.

Now, don't get me wrong, it was terrifying. How - me - a student that knows nothing will lead other people? I just got here, guys. However, let me explain how and why exactly it was awesome. Or, at the very least - useful.

Dev VS Manager

I, as most of us here, have always thought - "Management? Who wants to do that... What fun is it to talk to people who do the work? It's much cooler to be the one doing the work, actually coding." Until.. I tried to be one in Telescope. And I realised - somehow, I want to be aware what's going on. I want to know what our progress is. I want to prioritise directions that are essential.

Firstly it was because all of those things mentioned... WERE WRONG. I see a documentation problem, and I WANT TO FIX IT. And NOBODY ELSE DOES! It has to be me. To fix those things, you need to know what's going on... so, ok. I gotta find out what's going on. I need to ask people, read code, talk to them. BECAUSE NOBODY WILL! And as I'm fixing all these annoying little steps, I realise I'm actually doing.. management. Since I am learning what everyone is doing, getting just enough information to be aware, but not deep enough to actually code - I get to be aware of everything.

In Telescope usually people would go into their own niches. They will explore a new tool, or develop a new service and will become "kings" in their own little kingdom. Now, suddenly, we have technically a large project - but in reality - we have many newly established kingdoms scattered all around. And nobody else knows what those kingdoms are, except their kings. How would anyone figure out the direction to go, if nobody is aware of the whole picture? People need to communicte somehow. And I was the one to get this information out of them.

Once I know the information - I can inform the rest of the kingdom. And then - we can make our decisions.

I can't exactly put my finger on why this is cool. But I keep getting compelled to establish paths of communication, softening the edges of the development process and filling in the gaps of unknowns. If not cool - it for sure is important. It has to be done.

How it improves you as a developer

It's very likely that my excitement didn't transfer onto you. I get it - planning, meetings, documentation, talking to people... - isn't fun. But let me tell you how it helps you to have such an experience.

In the work environment you will likely have a manager. You will have some kind of meetings, some kind of communication between other members.

If you ever have been in that role yourself - where you had to know what is happening, and you just had no idea. Here you have a deadline, and you're responsible that this team of cogwheels
deliver the product - how do you even figure out if you're doing well or are fucked? Now, suddenly, you need to know what is going on. You need cogwheels to communicate to you their progress, direction, problems. You need meetings.

As a developer it is easy to get annoyed with management. Sometimes because the management themselves actually suck. But sometimes - you really gotta understand the other side. Once you understand what they want to hear from you; once you've had experience of the one who's asking and getting unclear answers - you start to change the way you communicate yourself.

Let's make a web dev analogy, wee!

You have 2 application endpoints: front end and back end API. You need API calls to transfer information between them.

You can just dump everything in a JSON and forget about it. You can send just a single thing. You can make a request once a week, once a day, or every second. What, in what format, and how often do you actually send it? You need to know what the API is expecting. You need to know their data format. You need to know why API even asks you for data in the first place. You are the front end, and the manager is the API. Or - the other way around, if you'd prefer to be the back end. No matter in which environment - you need to know what both sides are sending and expecting. That is how communication works.

Communication is, truly, essential. As long as you have a team - you need it. Somewhere in your career you might want to advance onto higher positions. Those usually involve more management the higher you go. A senior developer. A system architect. A team lead. Higher knowledge, higher responsibility, higher salary. If you plan to grow - this is the path. And it requires to learn these skills of management, planning and communication. The better way to show your employees you are ready for a raise - prove you already have these skills. Show them you meet the requirements. And they will notice. Because other developers - won't.

And that is how the experience of being in a manager position improves you as a developer.