Managing developers

In this post I want to share some of my beliefs about managing (mostly junior) developers, after some years of doing it at BubblyDoo with varying levels of success.

In a startup, there's always too much to do. Usually the work for developers is developing new features, to drive more sales. It rarely is taking a step back, looking at what can be improved, and it is even rarer to find time and energy to get a fresh perspective and learn new technologies.

With learning I don't only mean following tutorials, but also watching videos about trends or how other people do things, doing a deep dive into documentation (e.g. I believe if you use React a lot, every once in a while you should just reread their documentation. There's always something new.), or checking the internals of a popular library.

I believe I've always been pretty good at balancing output with learning, and being able to turn new learnings into higher productivity quickly. But it was very hard for me to get the rest of my team to do that as well. One of the problems was that most developers had more than one manager, so whenever there was a good moment to learn something new, it would be considered inefficient by the other manager. Of course that only works in the short term. Rewrites or iterations, good for learning, are easily categorized as inefficient.

Next to that it was also hard to convince them that learning was essential for their career. I think it makes sense that in order to become an experienced developer, you need a lot of exposure to a lot of technologies, and always try to rethink how you can do things better. If not, you will keep doing things the way you have done them forever, and you won't take leaps of efficiency anymore, just incremental improvements.

And lastly, often when we tried to plan some learning moments it was inefficiently spent, with too much time dabbling in theory and not enough broadening of perspectives.

In the end I'm not very happy that I wasn't able to give everyone the mindset I have when it comes to growing as a developer. Maybe it was because that was just unrealistic (I also spend a lot of time at home on this topic), maybe because not everyone learns at my pace or not everyone was as obsessed with it as me. Probably it was all 3.

To hire great developers, we needed to hire for attitude, because we couldn't afford to hire more experienced people. We mostly hired people without a background in computer science or engineering. They came from more unusual backgrounds like bootcamps, being self-taught or a shorter higher education. This, we believed, would make it possible to hire motivated people with grit. That might have been correct, but we also believed for too long they would be able to achieve the same as someone with a theoretical background or an experienced developer.

In order to convince developers to come work for you, we could say a few things. Of course we said we're a cool, small, flexible company where you can have a big impact and you get a lot of agency. This was true. I also thought we could tell them they would learn a lot. But that really depends on what you want to learn. If becoming a great developer means writing the best and most structured code and following all the best practices regarding processes, reviews and sprints, then you will probably be very disappointed. But if you want to focus on business impact and you don't care that much about the code and more about results, it might be more suitable for you.

And there's always something more urgent to do, so mentorship is also very limited. If you're not able to learn and grow on your own, you won't grow. We tried to assess autonomy, but that didn't always imply learning.

So we stopped promising people they would learn to become good programmers. They can, but they need to be really dedicated to it. A startup is just not optimized at all for learning, because it is rarely focused on the long term.

Even YC's co-founder Paul Graham talks about it.

This creates a problem: the developers you hired don't improve as you expect. You keep guiding and reviewing the same as before. And hiring more junior developers only makes it more difficult to make time for yourself to push things forward. You can't simply become a manager of a team if the gap between the team members and you is too big. I believe hiring junior people and guiding them is possible, but you need to dedicate time from experienced people to it. The ratio junior/experienced needs to be low.

I believe it is possible to balance these three:

In fact, I think finding this balance is one of the key aspects of any developer's career, whether they're aware of it or not.

I think you don't have to choose between these three. It is not zero-sum. A good developer will be able to find a balance, and they will reinforce each other. At least that's what I've felt in my own career.