Last month marked my 5th anniversary at Netguru. It’s been an incredible adventure so far with a new set of challenges waiting for me every day. With this post, I would like to sum up a few things I have learned during this period. Where do I start?
People come and go – it’s quite a common pattern. I have often seen people work shorter than 5 years. I don’t think that this is particularly good or bad – it’s rather a matter of expectations and how the company aligns with your own vision. In my case, I found what I was looking for. Actually, I found it a couple of times.
It all started with one project. I was thrown in at the deep end and began to deliver real value to the customer from day one. I was pumped. Previously, I had worked with academia and seeing the tangible value of my work wasn’t a common thing. I immediately fell in love with building things, bringing value and learning about new tools and techniques. Coding professionally gave me a sense of “good fit”, I was happy with my “technical usefulness”. At the same time, the client was happy about the project’s progress, and my bosses were happy about my results. I feel that those three things were the key factors that made me feel that this is the career I want to pursue.
After a few months at Netguru, I went for my first Ruby-related conference in Poland: wroclove.rb. This was my first experience of a big event with dozens of other professional developers who write code for a living. Hearing about their experiences, discussing the projects they worked on, talking about the way they lived... All that made me realise that being a developer is fun and that we aren’t boring at all! This was also the moment when I understood that a developer doesn’t have to know everything about building computers but is rather a person who can make computers talk the way it’s useful for particular needs. I have been really proud of being a developer since I got back home from the event.
I wrote a couple of apps from scratch, but I also worked with the code inherited after other developers. Terms like “legacy code”, “spaghetti”, “fat models and fat controllers” come immediately to my mind. Was I complaining about them? Of course. But after some time and project-switching, I realised that they’d shaped the code I write now. After dealing with tons of hours spent on understanding the complicated flow of methods, my code is now simpler and easier to read and maintain. I’ve also learned how to receive and give feedback about the less beautiful code. I try to understand the decisions made by other developers and ask them about the reasons instead of just assuming that they can’t write proper code. And all those situations when something went wrong – they only made me more connected to the team I work with. Nothing is better than a successful deploy after a tough coding sprint.
As the company grew, tutoring, mentoring and leading our younger team members became more and more important. They needed some guidance along the way because they wanted to use the best practices we had already established in the past projects. My role shifted a bit towards leading other team members the moment I stopped being responsible solely for my code but also for my team. I feel proud when I see senior guys who I met years ago as juniors. They’ve loads of valuable things, and I’m glad that I was part of their learning process (I hope they remember it just as fondly as I do :)) There are some natural born leaders, but there isn’t a lot of them. You can learn how to become a leader and how your actions might help other people become better at what they do.
I never had a day when I didn’t know what to do or didn’t feel accomplished. The number of to-dos is so big that it could be overwhelming sometimes, but it keeps me motivated. A good example might be a process which we create, describe and roll out to the team. You feel happy for about a minute after it’s in place, but then you have to make sure that this process is established and check how the initial approach behaves when it meets the reality. I’ve mentioned the “startup culture” because, as we grew, new things continued to appear. One day I was coding, the other day I had to recruit someone or make someone else redundant. The goal is not to stress too much about those things. The key thing there is to be organised, and the entire spectrum of your responsibilities and tasks will let you grow in multiple areas. In my opinion, the most important things happen when one area meets the other one. If you know only one area, it will be hard for you to get the big picture right.
After stepping out from coding and moving towards a more management-related role, I realised that my individual contribution is no longer as valuable to the company as the results of my team. This realisation helped me a lot. I started to see that delegating tasks isn’t bad – it’s a necessity. After I learned how to do some things and felt good about the way I do them, I started to pass responsibilities to other people and gave them the opportunity to grow as I had grown myself in the past. My team is exposed to various technologies and challenges. Even though I’m not at the frontline, I feel good about this because I know that I can count on my team and use their help and knowledge to conquer even more ambitious goals. I think that being a good manager is to stand behind your team and let them shine.
“If you don’t move forward, sooner or later you begin to move backwards.” I’ve learned that if you want to advance your career, you either have to find new domains to explore or master the one you already know. But you can’t do anything and expect it won’t affect you in any way. The IT world changes so rapidly that if we don’t adapt quickly enough, we will be out of business shortly. From my perspective, it doesn’t have to mean changing jobs. I would rather suggest that you master your current position and be a ninja/senior/star there, or start to be active in a role where you see there’s still a lot to be done.
Happy anniversaries people! :)