How I saved my programmer career
I was never very keen on coding. Despite studying IT at university and having a stable corporate job I still missed the point in it. I felt programmers have a lack of competence: just taking tasks from Jira and creating pull requests.
I felt like being a secondary helper worker, who can assist with just one thing. I missed the big picture or simply an answer to a question: “Why are we doing it?”. Moreover, I experienced idle time: when other teams were late finishing their tasks, I couldn’t help them, since it was not my role. Although we were not moving fast, everyone was happy because the game had clear rules.
I was very frustrated and blamed coding from this failure. I thought the only solution is to change a career, which was, back then, the biggest temptation of mine. However, I gave it another try at Slido.
Imagine an end of a long winter period. When spring comes, all ice melts and birds start to sing again. That’s what I experienced at Slido. Let me explain what we do differently here.
No idle time
“I am waiting for the back-end team to finish the API.” Have you ever heard such sentence?
Product teams (cross-functional, cross-component) remove the burden of dependency, they use the proactive way: If there is any constraint at work, remove it yourself (within the team), rather than wait for external help.
At Slido we work in such teams: The whole feature — from an idea to a customer — can be delivered within a single team (4–6 people) made up of front-end developer(s), back-end developer(s), a tester, a product manager and a designer. As a result, everyone contributes to the common goal without any “waiting time”. A team can deliver at a fast pace and get feedback from customers immediately.
Imagine coming to work in the morning with an idea in mind about improvement in production. Then, after a few hours of collaborative work, you receive positive feedback directly from clients. Those are moments, which wouldn’t be possible without a product team.
Feature ownership
A happy customer is an ultimate goal. My work does not end with a single commit or a pull request, but with a happy customer using a new feature. Coding is expensive, so every task must be challenged. Every feature is owned by a developer at a certain time, so PM can’t be blamed for useless features due to a wrong assumption. It is a shared responsibility. Wrong decisions must be detected ASAP. I think the best moment is during technical analysis.
To wrap it up, everyone must challenge the original intention. The success depends on the collaboration of all involved. That’s why I feel my voice matters: not being just a helper, but an owner.
Accountability
It all makes sense but how to create such an environment? I described an ideal environment, which is not a state, but rather a process. Honestly, it was very difficult for me to adapt at the beginning, but thanks to my great colleagues, we handled it in a few months.
“Give a man a fish and he will eat for a day. Teach a man how to fish and you feed him for a lifetime.” We aim to review each pull request with this proverb in mind. In addition, every developer should spend dedicated time learning each day.
However, learning alone might not make any difference. You can have great skills but if you are not working with a big picture in mind you might still fail to deliver value. Besides great hard skills, you should develop soft skills so that you can build a functioning team and your colleagues can always rely on you. Team success lies at the intersection of teamwork, great skills and following of product goals.
Why I love my job now?
Simply because I can come up with my own ideas. What’s more, I do not have to wait for anyone in order to execute any part of them. This freedom empowers my creativity and accountability. As a result, I am not only executing ideas of my boss, but also feel ownership of the product. And that’s what makes the biggest difference.
