I've seen this video recently by Clément Mihailescu the guy who created AlgoExpert. No, this video is not about algorithms. It's about the 4+1 different kind of developers he identified during his career. In this post, I am going to reflect on this video, I'll do a self-analysis and share my opinion on why I think that the Clément is right and we should be aware of what kinds of developers we are and who we are working with.
The 4+1 kinds of different programmers
Alright, so here are the 4+1 different kinds:
- The coding machine
- The product-oriented programmer
- Domain expert/domain specialist
Process-oriented programmer
+1 Jack of all trades
Let me give you a very brief overview of each before I go into the self-analysis.
The coding machine
Simple, right? This kind of programmer wants to code, code and code a little bit more. Such programmers are rather unhappy by going to meetings (frequently) and doesn't really care about what service or product he is working on. He takes pride in his work.
The product-oriented programmer
Unlike the coding machine, the product-oriented programmer takes pride rather in the product of her work. She cares deeply about the product, in fact, she will be unhappy if she has to work on the wrong product. She is likely to enjoy meetings as she wants to have an influence on where the product goes.
The domain specialist
The domain specialist is somewhere in between the first two categories. He will be passionate about the product, but he also might end up as a coding machine if and only if he can work in his niche domain of speciality. Clément's example was someone caring so much about React that he only wants to work with React, preferably in the React team of Facebook or at some other companies/teams specialized in React.
The process-oriented programmer
The process-oriented programmer is characterized by the 3 Rs. She is all for rigid, robust and rigorous processes. To make her feel happy, everything should be planned out, everyone should understand what the others working on. It should be clear how code reviews are done, who approves what. Probably she is also working on a style guide. She cares more about the how than the why or what. She takes pride in building the right way, not the right thing.
+1 The Jack of all trades
We are not black and white, the jack of all trades is a little bit of everything.
Well-functioning teams need diversity
Clément thinks it's important to do an introspection and understand what kind of developers we are. I completely agree that it's important to understand ourselves. If we want to be happy we should do what challenges us and brings us joy at the same time. Challenge without interest leads only to pain. If you understand what brings you pride, you'll have a chance to lead your career in the direction you want. You can read more on that in The Seniority Trap, please subscribe!
Understanding ourselves is good, but understanding others is even better. especially if we manage a team. But even in an agile environment where the team is supposed to organize itself. Understanding the preferences of the individuals in a team helps to build a better functioning team where everyone can enjoy their work and contribute in a way that feels natural to them.
A well-functioning team needs diversity. Like a football team. No team can succeed only with forwards, you need a goalkeeper, some defenders and midfielders as well.
A development team is no different. You need people with different skillsets, roles and preferences. Understanding the "types" of developers is also the recipe to build a truly diverse team. You'll need all of these people. Some who can build the processes and make sure that operability doesn't suffer because of ad-hoc actions. Obviously, there must be people who are inherently interested in the product and can be a bridge between business/customers and the developers. And which team can function without some coding machines who can turn down their heads and code, code and code and make the dreams come true?
Who am I?
When Clément started to talk about the coding machine, I quickly said that's me! My role is far beyond being a programmer, but whatever project I join, I soon find a way to code something. It's not always about working on the C++ backends that I prefer, sometimes it's about automating some monkey tasks. Maybe it's about creating the integration pipeline. Whatever! I want to code, code and code! I'm definitely a coding machine who wants to get far from meetings.
Well, it's not exactly true. I want to get away from unstructured too broad meetings. Meetings with less than 5 people I specifically like. They lead to real knowledge sharing, they let people conduct real conversations whereas above 7 people it's never effective and for most of the participants a note about the minutes would be enough.
But that says nothing about whether I'm a product-oriented developer. Definitely not at the core. Only on the veto level. I wouldn't work on something harmful - but in fact, harmful is very vague. You might find something harmful that I find useful. And the other way around. I know I wouldn't work for Facebook. Even considering their role in easing communication and getting in touch with you, dear reader, I think they limit freedom of speech and they are bad for democracy. But I don't really care about whether the product I work on is inspiring people or if it's just useful. Well, it should bring enough money for the company to pay me...
So far, I'm a not very much product-oriented coding machine. But what about being a domain expert. Clément only spoke about React as a domain. What can a domain be? To me, it can be a framework, an aspect of a language (like performance optimization in C++) but a domain can also be a business domain.
I don't consider myself a domain specialist. Even though as a developer I've only worked in the travel industry so far and I understand the different flows, I've seen many problems, I don't see myself as a domain expert, and I don't feel tied to this domain. I've been working for Amadeus for almost 8 years and I'm working on rental car reservation systems for more than 3 years, the reason I haven't changed is not the domain, but fear. Just kidding, I still have a lot to learn, and I haven't plateaued.
I find it important that a part of my job is about C++ and I would reject any change or new job where I cannot exercise C++ because I decided to become a C++ expert. I'm personally invested and it makes no sense at this point of my career to jump between frameworks and languages. But C++ is not a domain or at least it's too vague with my (not very high) level of expertise.
All in all, I'm not a domain expert, but I think I might become one in the near future.
Lastly, am I a process-oriented developer? When I first heard it in the video, I laughed and said, hell no! I'm not so much fond of processes. But then I listened on and I realized that one of my first contribution to the team was about our git workflow, then I spoke about the importance of coding guidelines at multiple conferences and these days a part of my job is being a member of our internal C++ coding guidelines board.
So who am I?
A process-oriented coding machine who might become a domain expert with some feelings towards not working on the bad product.
Sort of a jack of all trades. It makes sense as I prefer having a portfolio job, I prefer being a mentor, a coder, an author at the same time. Why would I be a simple coding machine?
Who are you?
Today, I presented you an interesting video by Clément Mihailescu that divides developers into 4+1 categories: the tireless coding machine, the product-oriented developer, the domain expert and the rigorous process-oriented developer the and of course the mandatory jack of all trades.
I shared with you who I am, but who are you? Let me know in the comments or drop a mail!
Connect deeper
If you liked this article, please
- hit on the like button,
- subscribe to my newsletter
- and let's connect on Twitter!
Top comments (0)