It is a known fact that developers today have to keep up with technologies that pop up and trends in the industry. Junior developers have to do side projects if they want to advance their knowledge while they’re studying or in an entry-level position.
Many companies, such as Instagram, Google, DuckDuckGo, Atlassian, and more, acknowledge that side or temporary projects are a great way to not only develop employees’ skills but also keep them happy and motivated in the workplace.
At Gloat, we have taken a few steps forward and built a system to help people develop their careers where they want them to go. Of course, you have to practice what you preach internally as well. Gloat also encourages people to pursue what they wish in the workplace.
Today I want to talk to you about side projects and how I utilize them to advance myself, and share some tips on how to do so yourself. Doing side projects, alone or for my organization, has been the best way to gain new skills, and not necessarily technical ones. I’ve learned to code on my own using help from friends, family, and co-workers on the way.
Define a problem
The first thing is to really define the issue you’re trying to solve. A lot of ideas spark over time, but not all of them are worth the time and effort. Only work on well-defined ideas. What is a well-defined idea?
Small steps and easing your way in
That’s not so easy to answer, for me, at least. It’s having a real-world problem, big or small. The idea involves a technology that you already know in some way, that can help you jumpstart the idea.
For example, let’s say you know some Python and are trying to learn JavaScript as well, and you decide to build a web API in Node. If you look at your API and say, “I could have written it but in Python ’cause it’s too much,” then write in Python; why not? Write your POC in Python. Once you’re done, start converting the core of the POC’s code into the Node. Of course, it’s gonna take some time, but that’s alright, we’re here to learn :)
POC
The next thing you need to do is define some kind of POC. It’s usually easier when it’s a work-related side project, but it’s also possible with personal projects. Just ask yourself, what’s the minimum time and effort needed to see some results? Those results will give you confidence that you’re going in the right direction. It’ll also help you focus on the core issue, and all the other stuff will come later.
You want to be able to define a test that proves what you want to do has value and measurement. Then the POC gets boundaries. Once you reach a point where you can run a test, you stop to measure and evaluate your work and the future of the project.
The only difference between a junior and a senior is how good they are at Googling
Now that you’re done with the POC, you want to start working on the problem. This is not a system design blog, so I won’t go into the decision-making of those.
The title can be a bit misleading, maybe it’s not the only difference :) But when starting to learn new tech, don’t bang your head against the wall. Someone probably solved very similar problems before you, probably even someone in your company. If not, you’ve just got to find it online.
Copy/pasting is also a very important developer skill. If you have issues understanding some of the new technologies you’re trying to learn, go online. You’ll probably find hundreds of tutorials, Stack Overflow answers, and GitHub repos. Go to the top-voted ones, the ones published by known instructors or community members, that’ll help you verify they’re up to some standards. Copy their code into your machine and start running it. Line by line, if you need, put breakpoints into their code and experiment with it a bit. See what errors it produces and what API it exposes.
**I also like to search GitHub for repos that are doing kind of the same biz logic I’m trying to achieve. Since you’re coming from that knowledge base, those repos will be much more appealing examples.
The right people
When trying to build a project, it’s really not possible to do it alone. You might be a great student, but no matter the topic, you’re going to encounter limitations where you need help.
But more importantly, you don’t know what stuff you don’t know, meaning you might do some wrong stuff, such as design patterns, wrong tech, and inefficient code. A lot of the time, it’s hard to notice those mistakes unless you’re experienced. All of these can be prevented by getting help from others. It can be people you work with, people you’ve met during your professional life, or just friends and family in the field.
From my experience, people like talking about their work and their experience in it. Exploit this. Let managers, senior developers, architects, or just your co-workers, teach you. It’s so easy. It also helps develop a strong culture.
It’s not only about the tech
Side projects are much more than learning new technologies. They can have positive aspects for you personally and your soft skills.
Even unfinished projects have great value for you. It is very important to take time every now and then to evaluate what you did right and what you did less right, w bothers you about the stuff you built, and what’s the stuff you say, mmm, I like that. I’m going to keep doing it outside this project as well.
I do this kind of self-questioning on every project I work on.
It starts with forcing myself to find 3 things I did wrong and write them down. Then add 3 things that I did right and that I’d like to keep doing. Those are usually practices I picked up, and I see them as beneficial. I try to break all of the things I wrote into a cause-and-effect chain. Over time I try to see recurring causes, good and bad. I also try to find correlations between the bad and the good since a lot of the time, when things go wrong, it’s because I invested too much in the stuff that went well.
Dissecting cause and effect is hard and doesn’t always work, but even writing down every milestone that went right and the ones that went wrong will help you develop a sense of sensible self-criticism and find the stuff that still needs work in the project.
One example I have from my professional life is that I was asked to POC and build a new service for our infrastructure. It had to include a lot of new things for me: ElasticSearch, Kafka, and K8s. When it was done, I felt like I knew this tech. But problems started showing up. After a very helpful talk with my manager, I started writing down how the project went. We understood that monitoring and logging were lacking, but that’s easy to say. Trying to dive a little deeper, I realized that it was lacking because I was lacking understanding of what monitoring is in general. But that’s still not enough. I needed to break down that lack of knowledge. Let’s look at an example.
Cause: I thought I knew how my Kafka consumer works, and I’d written a unitest for it.
Effect: A system for tens of clients producing millions of different data points won’t necessarily behave the same as my test.
Breaking down the cause is easier than breaking down “lack of monitoring”:
“I want to know exactly how much data worked, how much didn’t, and the reasons.”
Taking that as an actionable item rather than “I should learn how to monitor my system,” why?
’Cause I can turn it into a Google search:
“How to monitor a data pipeline with Prometheus (the tool we are using, it can be whatever you use).”
Actually, my analysis isn’t good enough if I can’t turn it into a Google search or a question that another person can answer.
Wrapping up
In the end, this topic is highly subjective. While some find it a great way to develop their career, some won’t. Also, some organizations could find a way to integrate this into their culture. There are a lot more approaches on how to do side projects. I tried to give you some tools that helped me, and that might help you too. You gotta find what works for you. If you do, please share. I’d love to hear :)
