A real programmer. A 10x engineer. A rockstar developer. It has many names, it comes in flavors, but in the end it’s the same old stereotype. In this video I’ll try to deconstruct it. Imagine you’re in charge of a developers’ team or a company. Let’s say you start a new project, or you are in the middle of one, but for some reason things got serious the project made a gybe and suddenly you need to hire new people who will save it from an imminent disaster. Who do you look for? A real programmer, that’s who. You need a guy who will almost instantly be productive, who will have no problem working overhours if the compensation is right, and who you can trust with your idea and be sure that he will do whatever is needed to make your dream come true. Then, if the project is successful you’ll not only have the initial version of the product but also a story: here is a brainchild of a brilliant software developer. It couldn’t happen without him. And what if the project fails? Well, usually we don’t hear much about such projects. A month ago a thread about such a real programmer – – or in this case it was called a 10x engineer – made rounds on Twitter. According to the author, a 10x engineer is someone who keeps all the codebase in his head, prefers to work alone, don’t like meetings, don’t like mentoring, thinks that teamwork is a waste of time, and so on. The author was a manager and he didn’t mean to be sarcastic. He appreciated these traits in a programmer. In his opinion, such a person was a cornerstone of a project. A company cherish their 10x engineers and build developer teams around them. The thread was mocked mercilessly which gave me a bit of hope for the programming community. But the programming Twitter is usually ahead of the rest of the world, and I know from experience that the myth of a real programmer is alive and kicking. Companies would like to be seen as welcoming and inclusive. They say they value teamwork. They’re all for personal growth. They want the office to be a fun place to hang out. They want to draw in junior developers who will gain experience and become valuable assets for the company. But the company’s goal is first of all to make money and when it comes to hiring someone all that progressiveness suddenly has to take a step back. Sure we want a diverse crowd of newcomers, but, oh, you know, we’re in a very dire position right now, and how about this one time we’ll look for this very experienced guy who will make sure that the project won’t fail. But reliance on brilliant hero developers may hurt the company, especially in the long term. In the short term – yes, it’s less risky, and after having your hero and putting him on a pedestal you will probably see a surge in productivity. But if you’re not careful, if you let things go this way, one day you might wake up with a number of issues making a negative impact on your project, the quality of the code, and the atmosphere in the team. Let’s talk about them. Sooner or laterevery project moves out of the phase where one person can handle it, no matter how real your real programmer is, and the company needs more people on the team. So, okay, new people are being hired. But instead of working on creating a functional team with people of different talents who cooperate and complement each other, some companies choose to build the team around their superstar. In such a scenario new members become sidekicks. Their role is to unburden the senior programmer from the more mundane tasks, fixing trivial bugs, writing unit tests, taking care of some particular non-crucial parts of the project, and so on. Now, it’s important to note that the senior developers are not the bad guys here. They don’t have to follow the stereotype. If they are willing to mentor new members – and in time would delegate more and more important tasks to them – the team may still evolve in the good direction even despite the best company’s efforts to sabotage it. Unfortunately, it may happen that your senior developer follows the “real programmer” stereotype: he focuses on writing code, is unwilling to mentor, does not like when during a code review someone tells him that his solution is wrong, he’s allergic to the documentation… He – it’s almost always a ‘he’ – assumes that other team members are there to help him, not to learn from him, and definitely not to teach him. And in a way this system can be stable and effective. Every team member has their position, and their tasks, and they all may perform their tasks very well. Junior members either learn on their own or are just happy with the situation. So if everything goes well, what’s there to criticize? Well, let’s start with that we have a person in the team with a very crucial role and a lot of responsibilities nobody else has. Other team members look up to him and try to be like him – or maybe even better than him. It creates a situation which does not promote cooperation but rather competition. The team is no longer a set of more or less equal colleagues. It becomes a pyramid with the senior programmer at the top and the rest climbing up and judging each other’s value. Helping each other becomes less important than an individual contribution, and that individual contribution is often measured in lines of code. People who follow the “real programmer” stereotype better are judged to be more valuable. Those who do not, stay behind, get delegated to less important tasks, and finally look for another job. But that’s not everything. Far from it. A bus factor is a half-serious notion of how many developers have to be hit by a bus before a significant part of the project will be left without anybody having a good idea what’s happening in it. In projects where the team is built around a single senior developer the bus factor is one. In reality people rarely get hit by a bus. They just leave the company, because someone else made them a better offer, because of our personal conflict, or because they are no longer happy with what they’re doing. Projects built around single senior developers and companies embracing the hero culture are sensitive to all these three factors. Being the most important person in the team is not fun at all. Yes, our rockstar is in charge of the whole project. He gets to decide who does what, he often works individually on the most important parts, other people look up to him, he gets praised when everything goes well… But he also gets blamed when something goes wrong. Or even if nobody blames him, he tends to blame himself. Or maybe not. Maybe he chooses another unhealthy coping mechanism and instead of blaming himself, he starts to blame other people. Or maybe it’s all good, but the rule of promotion to one’s level of incompetence is applied and the company promotes him to the position of the team leader and starts to treat him more like a manager than a programmer, so instead of programming now he has to do a lot of things he doesn’t like and he’s not good at. Either way his relationship with the rest of the team, and the project, and the company, tends to get difficult sometimes. And when it does, it may just happen that he will choose to quit. After all a senior developer will find a good job in no time. Even if the team is a healthy one this is a difficult situation. If the company embraces the hero culture and the rockstar developer around whom the whole team if built is leaving, this is a disaster. It means that suddenly large parts of the codebase are no longer maintained by anyone – and they are almost always the most complex parts of the code. There is no good documentation – real programmers don’t like to write documentation after all. “The code should be self-evident”. “If it was hard to write it should be hard to read” and blah blah blah. So, no other team member knows it very well. They weren’t mentored – real programmers don’t like mentoring. Maybe they were sometimes doing code reviews of it, but we all know how reviewing code of real programmers by junior team members looks like: “Ohh, this is weirdly complex, and I don’t understand it, but Rick surely knows what he’s doing, and I don’t want him to waste more of his time on this review, so how about I’ll just click accept…” Also, it often means that the code really is weirdly and unnecessarily complex. rogrammers working on one piece of code for a longer time tend to stop noticing that their code is unreadable – it’s still readable to them after all. But the rest of the team does not know what that code does and how it’s different from what it should be doing. They are not sure which parts are there for a reason and which are redundant. What can be refactored. Where is a bug if there is one. It will take months before theyll build confidence and understanding needed to handle it with ease. And in the meantime, the whole project may go the way of the last season of Game of Thrones. In my humble opinion, companies tend to look for new employees when it’s kind of too late. As a company, we plan a new project, we find funds, we make the plan, we go with to our developers, and… oh, fuck… we need more developers. Ok, ok, usually it’s not that dire but you can see the trend. the developers’ team is often tasked to the roof. There are no free resources, so to say. If somebody leaves, or if we get a new project, we need more people. But when a new person joins a team, they usually become productive only after some time: weeks or even months. Up start, having a new person means that now other team members need to schedule some time to teach them, so for some time now not only we still don’t have more people, but the people we have – have less time than before. The way to solve this is to hire someone already experienced in the technologies we use. Such a person will be much easier to introduce and will probably even know some clever tricks we don’t know. It’s a win-win, right? In consequence, job offers are biased towards senior developers. All over LinkedIn there are offers full of three- letter-long acronyms, and lists of required skills so big as if this one searched candidate was needed to save the whole company from collapsing. Most of these requirements are about coding: programming languages, technologies, years of experience in coding in this or that, evidence of projects the candidate was involved in, and so on. There’s enough of them that candidates tend to think that despite all the sweet talk about inclusivity and personal growth this is what companies value the most: expert coders, at the expense of everything else. So they try to be one. And, as a result, they perpetuate the myth. Okay, so now we have the whole system in place. You have to be very skilled in coding, have years of experience, and immense knowledge of technologies in use, because only then you’ll find a job where you’ll spend your days coding very important stuff and get a lot of money. If you don’t have these qualities already, you should spend your time developing them. If you can’t… well, maybe it’s not for you? It’s called gate-keeping. It’s when a part of the community sets up artificial rules guarding what does it mean to be a “real” member of the community and what qualities one has to have to become one. In case of programming, these rules focus on great coding skills and superficial traits which may signal that you have them: like knowledge of certain niche technologies, getting certain certificates, or having a penis. It’s ironic that even though in the community since long, the name “real programmer” started of a parody. In 1982 Ed Post wrote an essay “Real Programmers don’t use Pascal” based on another parody book popular in these times, “Real Men don’t eat quiche”. The book described an exaggerated image of what it means to be a man. The essay did the same about programmers. To be a real was to use punch cards and write in FORTRAN or assembly languages. The real programmers shunned new fancy languages like Pascal, and their fancy features like data structures. The technology changes so fast that even the specific rules of what does it mean to be a real programmer had to change a few times. Nowadays, even real programmers don’t use FORTRAN and don’t write directly in the terminal. IT became so big and diverse that there is not one language or technology which could be recognized as the technology of real programmers. But gate-keeping didn’t go away. It just moved to slightly more abstract positions. Now it’s more about how advanced your knowledge should be in the technology of your choice – given that it’s worthy of being known by nreal programmer, because, of course ,it can’t be too easy – and how much time you spend learning it and working with it. So, what if you don’t have time to do it? What if you’re not particularly interested in in any advanced library or framework? What if you have a small child and that’s what occupies most of your time? What if you are a single mother and you haven’t slept in three months anyway, even though you don’t maintain an open source project? What if you have other commitments you can’t or don’t want to drop? What if you’re simply not a workaholic? Or maybe you’re just late to the party, because for a long time you couldn’t afford a good laptop, internet connection, and time to learn, or maybe you decided to switch your career path only in your thirties, or forties, or fifties? Well… then you’re screwed. At least according to real programmers. Yeah, it seems easy to ignore these voices and this is exactly what I advise you to do but they can be intimidating from time to time. Let’s go back to the situation I described a while ago: a team where people climb an imaginary career ladder. They don’t even have to compete with each other. They may as well help each other with their tasks. But with the real programmer myth on stage they still judge themselves according only to its rules. Writing a complex piece of code is a step up. Failing at it, even if it’s a failure only in your mind… Oh boy, you’re not a real programmer. You’re a fake. Clearly, you shouldn’t be here. This is exactly what people told you. This is what you see in the eyes of those who didn’t tell you anything. And that guy who said “don’t worry about it”? What he meant was that you’ll get one more chance, you’ll fail again, and that’s it. The impostor syndrome is a well-known psychological condition. It can take many forms and it is better if I make a whole other video about it. Here I just want to underline that: *one*, it’s very common in the programming community on all levels of experience – from beginners, to senior developers, to people who achieved a lot and whose work is globally appreciated; and *two*, the fact we suffer from it is in part because of the sneaky thought that maybe we’ve not good enough, maybe we should have studied more, worked more, maybe we’re just stupid and we should leave programming to other, smarter, more committed people. Well, what if we can erase all the IT and start from scratch? What? That’s not possible? Dammit. I don’t have all the answers, but I think I know where we can start. We can realize that being a programmer is not only about coding. Coding is maybe half of the game. There’s a diagram I made for intro episode, and I’m going to get back to it from time to time. Coding is here. Around it are tools used to build a working application, documentation, design, QA, code reviews, and then there is teamwork, soft skills, methodologies, and time management. And even when it comes to coding: complex code is not the same as good code. The code is good when it’s written in a way that any member of the team can read it, understand it, and start working on it in a reasonable amount of time. The real programmer myth claims that what is needed is only the small subset of all the skills, namely coding and expert knowledge of advanced tools and libraries. But this subset here is far from being all that is needed. And if we say “okay, so a real programmer is someone who knows everything”… well, no. I don’t think there is one person on the planet who is brilliant at all these things. The set of all skills is just too big. Each one of us is good at only some of them. And that’s good. That’s natural. That’s why we form teams whose members help each other and complement each oher. Yes, of course, some of the team members are more experienced than others, but on the other hand, a junior developer is someone with a fresh look on the system and an ability to push it in the new directions. They can also more easily take over from experienced colleagues while other senior developers are often already responsible for some parts of the codebase and it is difficult for them to take new responsibilities. It also means that if you are this brilliant guy who’s mostly interested in coding with some pretty advanced tools and avoid meetings, there is also place for you in the team. Maybe just work a little more on your soft skills and a little less on even better coding skills. Help others. Write documentation. Go to meetups and conferences and talk about your work. Mentor someone. Answer questions on Stack Overflow. That sort of stuff. Please note that the “real programmer” myth hurts us all, creating unreasonable expectations, and a lot of unnecessary stress also for you. It’s not an us-versus-them situation. It’s all of us versus the hero culture. Let it go. So, if it was up to me I would
like my company to look more for junior developers, but to do it early enough. And during the interview process, we should focus more on their potential – their ability to learn, communicate, willingness to share and test new ideas, and things like how they respond when someone spots an error in their work. Sure. technical skills are important. A junior developer has to already have certain knowledge and experience. I’m also not saying that we should stop looking for seniors. I’m not talking about going to the other extreme here, just to bring back right proportions which, as I think, should be a bit more on the side of junior developers and skills other than coding. On the other hand, my advice to junior developers is: ignore gate-keeping the best you can. There are no real programmers in the sense that some other programmers are not real. If you work as a programmer, or if you participate in an open-source project, or if you simply code something in your free time, you are a programmer. And you are real enough. You can also make mistakes and that doesn’t take that title from you. If you see that your company promotes the hero culture or that your team is getting organized around one person, schedule a one-to-one with your manager and talk about it. I think it’s important to make it a one-to-one meeting. Just dropping a hint over a coffee is not enough, and bringing the topic while the whole team is listening may result in denial and a push back. Instead, prepare for a longer talk, make sure that the manager treats it seriously ,and bring up good arguments. If it doesn’t work, if nothing changes, I guess that means you should look for a better job. And that’s it. What are your thoughts? Have I missed something? Do you think my judgement isn’t fair? Or maybe applying my suggestions will turn any company in a weed-smoking hippie commune? Leave a comment below the video or let me know on Twitter. The next topic will be FLOSS: Free/Libre and Open Source Software. And then I guess I’d like to talk about Agile as the first in a short series of episodes on the ways we work as a team. But maybe you’d like to hear about something else? Let me know about that too. Thanks for watching.