Experts vs Expertise

Hello You can hear me that’s great. Well, I think we have to start with 11:20 While you’re still sitting I was just Washing my hands in the bathroom a few minutes ago and the machine When I move my hands to the machine its reacted and started the water And then I took my hands off and it stopped the water. So do you think it’s artificial intelligence or not? That’s my question to you. It’s a good question. Actually, it’s not related to my talk I’m just wondering what you guys think is it is it a thinking machine or is just Like a calculator which is programmed to do with certain operations That’s that’s a big question Actually my friend wrote a book about that is going to be published soon where he argues that the artificial Intelligence everything we call now artificial intelligence is just a collection of algorithms They’re not actually thinking those machines. They’re just putting giving us water and Taking the water back, but that’s not what I’m going to talk about So my I will drop a few ideas today for you. Just eight of them how to Resolve that’s that’s the summary of everything. I’m gonna say I will try to prove you that the more The more we depend on experts the more we depend on people who are irreplaceable on our teams on people who know too much and people who Maintain too much who possess a lot of knowledge the bigger the problem for the entire project The bigger the bigger the danger for the team and for the project And I want to ask you to call now. I don’t see you. That’s good okay, so my question to you is who of you actually Think that your team depends on you Can you raise your hand even though I don’t see your hands, but they’re like 20% of you So the rest of you the team doesn’t need you right more or less They’re just paying you That’s why you’re here. Yeah, you’re looking for another team So 20% of you think that think that the team depends on you and you are and who thinks that you are irreplaceable? There’s gonna be a real a big problem for the team if they replace you tomorrow. One, two, three, four five more Okay So I’m not gonna I’m gonna address my talk to the rest of you guys how to fight with those people how to get rid of them and A few words about myself just quickly. First of all, I’m a CEO and the founder of Zerocracy. It’s a it’s a platform Which claims to be artificial artificial intelligence like just like those? The tap with water in the toilet, but we are managing programmers with artificial intelligence So we invented the bot the robot the computer who is managing Programmers in software projects the robots give instructions to programmers. They collect results So they more or less help managers and replace managers in software projects who use interested on that and want to join you can comment to us as a software developer or as a product sponsor or Someone who wants to outsource the development work second. I am github Active code writer and open source countributor this how many followers I have on github. This is my timeline on github So I do write codes everything I’m gonna say today. It’s not just fantasizing I’m actually speaking from my actual experience on of writing code and Working with people who write code a few of my projects one is Rooter It’s for DevOps people for open source projects mostly it helps you Deploy, your stuff and merge your stuff and integrate your stuff from git hub to production from github to deployment Platform check it out. It’s interesting stuff. It’s also a chat board on github second. It’s takes org It’s a Java web framework sort of a competitor to spring and other frameworks Also interesting because it’s more or less pure open object-oriented And cactus door gets one of the recent projects were working on. It’s open source Also, it’s a Java framework for java library Also object oriented focused on object orientation for a replacement of apache and google guava I’m also a book writer may some of you know, my books elegant objects who ever heard or read books? my book elegant objects 1 2 3 4 5 120 people so My another book, which is also interesting, which I actually spend also some energy into it’s 2256 blog hacks it’s about blogging marketing staying online and being popular online and Attending conferences and making sure 120 people read your books and this is my last one It’s called codaeahead which is a fiction book about IT people which summarizes almost everything. I’m going to say today So if you haven’t heard about that, you may want to check it out and the last bit of promotion from me It’s my telegram channel where I post my news and interesting stuff So you may need to follow who actually in this room use telegram Oh Less people then read my books

So, but I think you should it’s a good platform And now I’m getting to the point. I’m jumping to the main point of my talk This is the quote. I really like from an interesting book it says that you can read it a good way for Ineffective people to get power in an organization is actually by creating an a monopoly of information. I Disagree with this statement only in one piece and you may guess which that piece is I disagree that Ineffective people do that. I think effective people do that so in order to be effective in order to succeed in an organization in a weak Organization in an not properly disciplined and organized organization You just create a monopoly of information. You control the territory You know how things work in that particular? area and then you are the king of that area and they will not be able to get rid of you and Then you will manage them instead of them managing you So this is actually a good principle even though it sounds like a joke in the book or half joke I think it’s it’s not a joke. It’s a problem It’s a problem in the industry and that problem is called job security. We all know what job security is. It’s making sure We are secure at our position. It’s not making sure the project is secure. It’s not making sure the team is successful Not making sure the company is successful. It’s just making sure that I am safe here This is my job is secure and they will not be able to replace me – you know – to fire me to move me somewhere else and that is good for us programmers But it’s not really good for our projects for our teams, and I found that term Called silos of knowledge. Have you heard about that? Silos of knowledge some of you yeah silence of knowledge is like like those Territories. I just mentioned those places which we know about which I know about which a few people know about we know what’s going On there. We maintain the information we’re not going to share that information with anyone else because this is our this is our territories our silo of knowledge and That would be many examples of those silos. I’ll give just a few of them first of all this of obviously a source code when I wrote the code. I know how it works I’m so proud of knowing how it works and I’m not gonna share it with you or it will be so difficult for you to understand it Anyway, so nobody will want to touch it and that’s my private territory Second these credentials so I know I have the keys. I have the passwords to the production server. I have the You know the information how to log in somewhere. I know how it works and I have those credentials I’m not gonna share it or maybe I’ll keep them somewhere or in the backup But only I know how to get them out of there only. I know how to apply them only I know how to manage them. That’s another silo of knowledge. This is this is the slide I’m making up. I didn’t find anywhere I’m just getting it out of my head. So where exactly people have stuff which they want to keep private and difficult to access Scripts, I’m talking mostly about deployment scripts release scripts Packaging scripts some scripts which are which work sometimes when when the author of the script is taking control of the script, but when somebody else touches the script We don’t know how to run it. We don’t know just to run scrip We don’t know what parameters are expected because the script is fine. But to run it you need to know the magic the magic Configuration to run them that’s another silo of knowledge configuration files Again for deployment for for making sure the software work. We may need some XML JSON Llamo, you name it text files to make the code work And we may keep them secret and finally data. How data is organized for example in database? What is the structure of the sequel database what these tables are? How they are connected and why what they contain what kind of information is that what that column means? One person knows and and we can get rid of that person because that’s best information. We Possess did I miss anything? Any other kind of you know, data or information or knowledge? which we May be maybe I missed the domain knowledge when I know how things works in the business and then I know how to apply that Knowledge to the software and only I understand that connection So what our customers need when they click that button and what they expect when they go to certain pages that also may be Called the knowledge The summaries are the dangers when we have those pieces while the project have more and more of those pieces it’s Dangerous for the project and the longer the project works. Usually the more Silos of knowledge. We have the more

territories are Controlled and protected by their owners. It’s dangerous not for us again I have to emphasize this dangerous for the project is dangerous for the team for the business for people who pay money to us So in order to resolve that in order to I’m getting to the solution now That was the problem And now I’m jumping for the solution in order to resolve that problem in order to make sure it’s not happening I believe that the best way is to somehow and I will show you how to encourage us programmers to share knowledge So instead of accumulating knowledge we want we need to share the knowledge. So we don’t want that because of the job security We don’t we want to sit on the knowledge and don’t share So we business or the team manager or the project manager or the team all together has to somehow invent some instruments how to motivate encourage Force, I don’t know us to share the knowledge and how do we share we share in writing? I think so through documentation through source code so explanations or diagrams We need to take out the information from our heads and put it into Into some digital artifacts into some files into some source code. I don’t know in something which is shareable with other people so instead of Knowing how it works even instead of teaching people around us how it works. We need to write it down That’s the key to success. I think so We need somehow and I will show you how we need to give some we need to do something. You know, the two To enforce information sharing and here’s the summary of my suggestion Some sort of, you know, a statement slide that I believe that good programmers They know how to explain how things works but the best programmers they know how to write it how to put The information that the ideas and the knowledge again I keep saying the same word again and again but we the best people know how to put that stuff into the digital artifacts into the documents into diagrams whatever So if you can turn good programmers into the best programmers the problem will be solved So how do we do that? And actually if we do that that’s again one more slide to To say what are we actually achieving with that? Why do we need to do that is because we increase the maintainability of the entire code as we all know I keep giving this number on every conference I speak is that we programmers change workplaces and teams and projects approximately every year So the recent study by Stack Overflow demonstrated that about 35% of us Changed the job during the last year. So let’s do the let’s do the experiment So, can you raise your hand if you actually changed your job in the last calendar year? There you go. So that’s maybe not thirty five percent, maybe two but still so we move from project to project Approximately, we will move even more frequently, but the project want to stay You know stable the project want to maintain what’s in the project what was created there. So maintainability is a very important characteristic the very important Quality of any project and if we manage somehow to share knowledge between people before they quit Then the maintainability of the entire stuff will be higher And actually I was giving this talk a few months ago and another conference not this one But I was touching the same problem and someone from them from the room corrected me improved me and said that it’s not even about Maintainability more but about predictability that’s maybe the better word. So the team will know what’s gonna happen tomorrow When we have silos of knowledge when we have people who know too much. We don’t know what’s gonna happen tomorrow We simply don’t know What are we gonna lose and how much we’re gonna lose when we lose that person and we may and will lose that person People go from project to project. It’s inevitable It’s not because we’re bad programmers of because we’re disloyal but because this is the market situation right now I also gave I’m not giving it now But I also gave a quote in one of my talks saying that I found it in some article by recruiter and that was a claim that If you according to some research that if you don’t change your job during 2 years That means that you’re getting 50% less money than you deserve Something like that. So you have to change every 2 years. Maybe it’s not true. I’m not sure That’s not my it’s not my you know, I haven’t seen the data. I’m not sure there’s data there, but that’s what they claim So now like 20 years ago. It was considered like a disloyal behavior If you change companies every few years now, this is the professional behavior you have to move from project to project in order to increase your Your your income in order to demonstrate that you’re moving that you’re improving and all that So what we what will happen with the project? Where is the predictability for me? Let’s say I’m a project manager and I’m an owner of that product

predictability will suffer if I don’t know what’s gonna happen when you leave and my final slide before we go into my reccomendations I will I’d like to compare what happened not what happened, but why? ancient civilizations the old guys who lived on this planet the hundreds of thousand years ago why they managed to evolve him evolved from From you know people who were living in caves To actually builders of beautiful buildings and actually build the civilization. I think that the root cause and the main Thing they managed to invent in order to achieve that we’re actually the ability to transfer knowledge I think it was like books or something which was written or trap some some media In order to transfer knowledge from one generation to another generation That’s why they managed to build beautiful houses not because they had brilliant architects and very talented people who knew how to build those those castles but because they Managed to transfer knowledge from one generation to another one to another one and then in maybe 15 or 20 or 200 Generations that generation get the knowledge from everybody else and can put something on top and then build Something beautiful a very similar stuff happens to us in our software projects But our generations are very short now is just one year. So I jump into the project. I know how it works I understand how it works I build something and then I quit so when I quit I don’t want to lose you don’t want as a project You don’t want to lose everything when I quit you want to stay with it. So I need to use some media to transfer my My thinking to you what media source code documentation? Diagrams data models something which will be easily understood by you And what I will suggest you now we have eight things we practice in my company in zerocracy They may sound quite extreme to you so they may sound like something which you may not apply in your team, but just listen to them listen and maybe something will Will work for you as well Am I clear up to now, do you understand the problem? Okay good So I will show you eight things They all will prevent Experts from from from showing up so we cannot like like like I was joking before, okay We have some people who we depend on. So let’s fire them. This is not a solution. Actually. It’s too late so when you already have people who you depend on you already know that this person knows too much and only that guy understands how The database is designed. That’s too late at that point of time. You need to do something else The key word here is prevent. We want to prevent that from happening. We don’t want people in our team to know too much We want all of us and to know You know enough to work with the project and we want the project to be the king not people but project Digital artifacts not people the source code is the king not the software architect The software architect is just a you know is just helping us to make the source code bigger and better and more maintainable So prevent step number one is smaller tasks. That’s what we recommend to do We encourage programmers Using different methods different different ways to work on smaller tasks. Don’t keep the code in your hands Don’t keep the problem in your hands for Too long if you’re working on something for a week if you’re working on something for a month you are Creating a potential problem because you will know too much about what what you’re working on So try to return your code try to return your problem back to the team back to the source Repository as soon as possible in our team We ask people to return the stuff back in half an hour in one hour no longer So you start coding you make a small increment and you return back the code The smaller the task the better and I also also sometimes claim that professional developers professional engineers They know how to solve a bigger problem in smaller increments So if you don’t know how to break your your bigger chunk of you know Code you need to write into smaller steps. Then your professional qualities are not high enough The more professional you are the more, you know How manage your own complexity how to manage the complexity of the work at your hands and how to break it down into pieces That’s the claim number one smaller tasks smaller branches smaller pull requests shorter reviews shorter commits faster deployments Smaller smaller small the longer. You keep the job in your hands the worse And I had really I’ll give you the real example

I was working in a few years in the team and I just joined the team and that was one guy who was quite smart It was a like the architect the lead developer and I happened to be a project manager No, I was like leading the team for a short time and I told him that Something has to be done how something has to be? Implemented and then he said sure no problem And then I came back came back to this guy two days later and I was asking like, okay So what’s what’s going on with this situation? He said sure it’s done already. I’m doing something else already So and that was considered he thought that he did a good thing that he did the right thing Like why bother the project manager why bother the team with what’s going on? He knows what to do He knows you know how to continue He knows what what’s the next problem to solve? But from my point of view from the management point of view? That was a complete disaster. It’s a completely unmanageable situation. So he did the wrong thing He had to do a different thing he had to start what I told him to do and return it back to me as soon as possible and Then you know ask for what’s the next step? So I want to get the knowledge back from him sooner faster not you know Not not keep the problem in his hands for too long. I Still remember that that situation and he was arguing with me like no I was time doing the right thing. I’m an independent developer I know what what I need to work on. I see the next problem. I can take care of everything What do we have if I would be the bad manager? I would let it go I would said sure that’s a good situation because it’s easy for me. I don’t need to manage that guy He’s just keep working and keep working But in the end we’re gonna have the expert who’s gonna be the problem for me as a project manager So I have to resolve that problem before it goes too far. I had to say stop it it’s not gonna happen that way you need to report back to me every F2 every small you finish not because they don’t trust you But because I want to see the flow of knowledge back and forth from the code to you and from you to the code That’s number one. And here’s the like a subtitle is that I’m talking about hours not days or weeks So I’m talking about hours. We don’t need to keep the tasks in the hands of developers for weeks or days It has to be hours a few hours here if you are there and it’s also the great thing for for the smaller tasks that Every time you return something back to the source code we review what you’ve done We the team or code reviewers will review your stuff and we learn something from what you’ve done step number two is No code ownership. You know what code ownership is right many part authors many books advocate for code ownership Meaning that it’s good so the team has to know the other person or individual person has to own the code and like You know attach Himself or herself to that code like feel it like it’s mine. I Advocate for something completely different so don’t feel that this code is yours think like it’s something you’ve just hired to touch and improve for a few hours and then you’re supposed to forget that code so don’t Attach yourself for too much. Don’t marry your code feel like it’s a temporary stuff in your hands It’s something which you touch you improve and then you throw the well you not throw the way but you you leave it and somebody else won’t touch it that that will that will help you understand why it will help in the long run because every time if the if the developer Feels like that If all developers feel like that if they feel that every time they touch the code they touch something which is not theirs They don’t go it’s not it doesn’t belong to them that will help them to behave Transactionally, it’s every time it’s a short transaction. I open the source code. I look at it. I see how I can improve it I improve it and then I let it go so I don’t know what’s gonna happen tomorrow and I expect new people to come in and Blame me for mistakes and ask the questions about what I did and everything else So if you and your company encourage people to be, you know owners of the code you’re doing the wrong thing I believe so should be completely the other opposite approach. So don’t attach yourself at the goal Don’t say this code is mine or don’t touch my module or who is the author of this module that is the wrong statement to hear if you hear that in your office like who is Responsible for that module then your team is doing something wrong Should be nobody responsible for that particular model It should be the code share it with everybody and if everybody can modify anything and what we do sometimes and what I suggest to do is rotate teams and developers so in order to not this code ownership to happen you may take Somebody from one team and put into another team and then rotate and then ask people to come in and review the code from another Team, so don’t so try not to To isolate developers with their code or teams staying too tight. It’s better to rotate people and move them from team to team Intentionally, especially when you feel that somebody is very much attached again

I was in a real situation a few years ago and the team where we’re developing there was like 30 developers and one person One guy was the author of the payment module which was responsible them the module responsible for credit card transactions It was like online system and the one piece was for processing payments It was quite critical because there was a flow of transactions and and he was you know, historically the developer of that piece so he started it a few years ago and he knew how it worked and Then the company faced the problem and that guy said that I’m gonna leave the company because I got a better offer The company were ready It was ready to pay any amount of money for that guy to stay and then it was it was okay for the company but then everybody else in the team realized that and I remember like everybody started to talk and say like what the hell this guy is just another well just the Java developer like I am so why he’s getting a hundred percent raise just because cities he’s sitting on the module, which is more important I also want to be on that module So it creates unhealthy and unproductive tense In the team because nobody like I explained nobody wants to be in that situation if you’re not there If you’re that guy it’s perfect. But for the rest of the team, that was really unhealthy situation Nobody actually understood were able to on this to was able from this to I mean what I’m doing wrong I’m also a good honest programmer. I’m writing code so why they help my salary is two times slower than the salary of that guy So what was the mistake? It was the mistake of management why the management didn’t resolve that before it was too long The management was just you know quiet and sitting and waiting for that problem to happen when it happened It was a disaster. So don’t make it happen rotate people if you feel that somebody knows too much Take that person out and put somebody else into that module and see what happens Tech diversity I have to say the diversity thing, right? I’m talking about Having different people in the team with different skills. So when you that will also help to share knowledge So if you if people say all people are Java developers, they all are experts in that particular framework They all know how things works in that framework. It’s good for some time. It’s good for short-term but on the long term we all know that we’re going to lose that people eventually and that will be quite difficult for New people who may not know how things work specifically in that technology to get into the project So try to keep you know to try to keep diversity in the team by the technology I’m saying here not by my skills not by skin colors So pay attention to the skills people have if you have I had a real like practical experience I was I’m a Java mostly Java developer, and I remember a project in JavaScript Where I was invited by mistake as a code reviewer So they wanted me to look at the code and that was JavaScript code and I started to ask so many questions Stupid questions, of course, they started submit me Pool requests and I was supposed to approve them or disapprove and I was asking questions which are really stupid for JavaScript community I was asking like why are you doing this and they started to explain it as stuff and in 50% of explanations? they were just telling me that I should go read the documentation because that’s how You know things work in the the world but in another 50% of questions I was actually right I was asking stuff which was not so obvious and they were Asking themselves like really are we doing it? Right because the guy from the Java community? Thinks it should be done differently and they were asking they were challenging themselves by my questions That was a good thing. Why did it happen? Because the tech diversity they we I was invited from a completely different tech territory technical step to JavaScript project Eventually, it happened to be a good thing for the project because of my stupid questions. So try to do it the same So when you have too many people in the project with the same skills with exactly the same profile with exactly the same qualifications Then most likely your project is going the wrong way Eventually, you will have a problem try to invite sometimes people who don’t know anything about your tech stack point number four blame them Now the question is who is them So every time a problem happens every time we don’t know what’s going on every time I look at the code And I don’t have enough knowledge in the team Usually traditional way is to start asking who knows how it works in the team asking around going around the office In the slag chat in some, you know, newsletter somewhere asking like who’s the guy to help me out? Who can actually tell me? What’s going on? And that’s wrong instead of blaming instead of finding that guy and blame like that person and saying like ok

You created that now tell me how it works and what? Why the hell did you create it that way now explain it to me Okay, they explain I understand good. Now. I am the guy to blame instead of that we should blame Artifacts not programmers. So here them I mean digital artifacts So every time you open something which you don’t understand a database model as source code is script So don’t look at the script and look at who’s the author of the script and start calling that person. Don’t do that instead Say somewhere where you have your tickets reported and github in JIRA somewhere where you report problems create a new problem create a bug with the number and say I don’t understand that script That script is my enemy not the person who created that script but that script is a bad guy I want to deal with that bad guy. It doesn’t matter who created that script. It happened. It happened years ago or days ago I want that to be fixed and then the team will find the person to fix the script and the script will be fixed and the enemy will go away and now you will have something which Is clear which is better, which is easier to understand. That’s how you increase The maintainability that’s how you improve the project not people. That’s that’s not how you blame people. Don’t never blame people That’s my point never blame programmers for writing, you know for for creating something unmaintainable and never try to resolve it with them Never ask them tell me what’s going on explain always deal with digital artifacts file scripts diagrams Whatever if they’re not good enough for you claim Somehow ask the management to you know to to give you resources to fix them Well what we do in our team how we do We actually that could may sound quite controversial for you, but we pay programmers for each bug They report So we encourage people financially for reporting bugs We’re telling them if you open the source code if you open the file the class which is not clear for you Don’t blame yourself. First of all that you don’t understand how it works. It’s not your fault Don’t blame the author of that create a ticket number one two Three and say I don’t understand how file ABC works I need an explanation and we’re gonna pay you for that report Because that’s how you help us to find out where the technical debt is concentrated Now we know that the problem is right here in this file Somebody will fix it and we’ll get back to you with with the solution. So we encourage financially I don’t know how you can do that. Maybe you can give some you know, some reward points some, you know cookies Some apples, you know I don’t know but somehow I think that’s the right approach to encourage programmers to report problems about the code. They have enhance even about the code they Create so sometimes I open the code, which I created half a year ago I have no idea how it works and I create a bug about it and I pay myself Point number five we have eight so I have three more. Well number five is that Pay for results if we yeah, there are two actually two approaches we can we can most of us are being paid by the time we work and some of Us very few of us are being paid by the results. We deliver paying by results I mean if there are no results, we’re not being paid if the results we’re getting paid so we advocate the model for pay for results because we believe that if we are being paid for the time we spend in front of the computers then most likely we will be motivated to create The code the Artifacts which are not easy to understand by somebody else because we want to stay with our computers We want to stay with the code for as long as possible. We are internally subconsciously Motivated to be in the team for a long time. We want to be those irreplaceable resources, we want to be those people who are difficult to fire and Especially when the team pays us for for the time We stay then we definitely want to be want to create something unmaintainable if we turn that upside down and make our our interaction with the with the with the team what transactional like I give you something you give me the money I contribute I improve I Put my knowledge into your artifacts. I actually share my knowledge. They give me the money and we walk away We had a real situation by about seven years ago or six years ago. We had a project Java project quite big but there was an element in it which was supposed to use machine learning and that was like seven years ago So we didn’t know what was that at all like we were Java developers and we had no idea what machine learning is We just read it in the news and we needed to do something and we had a few frameworks on the Java world for machine

Learning and we needed some knowledge to you know, we needed to know how to apply that stuff to our code So it was like a big piece of Java and then smaller my element had to be for machine learning so we found a guy who was the creator of The machine learning framework in Java. I don’t even remember the name Maybe I remember but it doesn’t matter And I emailed that guy remember this that that situation I emailed and said look we need your knowledge We don’t basically need your code. We don’t need to know, you know, we don’t need to you to teach us We just want you to take your stuff which you created and put it into our code somehow and show us in the code How it has to be wired together with the rest of the stuff and he said sure it’s $500 an hour And that was a good rate So but for for an hour, and we hired the guy for I think like for two days or so So we paid good amount of money per hour, but we need it just for a small amount of time So we completely bought the knowledge. We didn’t buy the guy We didn’t buy the person we didn’t hire the person. What do you need the person we didn’t need that person to be in the project We just bought the knowledge and that’s what we’re trying to do in all other with all other programmers. We’re not buying time We’re buying knowledge the information the code the knowledge that digital digital something which we can take Put into the code and then leave and then let the person go of course We don’t let everybody go every day. But that guy. Yeah, we let them go in two days, but for other programmers We are trying to stay together but every time we consider every transaction every piece of code you contribute as a Transaction where you give something the project gives you something back I’m not sure you can do that in your project. But that’s most probably my understanding. That’s the future software development I think in the future that’s my vision for 10 years ago 10 years. They have we will have Programmers who are actually charging $500 an hour and we will have programmers who are charging $2 an hour now We have more flat distribution. Now. We have everybody sitting in there Mostly everybody sitting in their offices or remotely doesn’t matter and charging something per week per month per hour in the future I think there will be more diverse Distribution of numbers and we will have people who know what they’re doing who can contribute with Good good knowledge and they will charge a lot and we’ll have everybody else that’s I think the future and I think in the future I gave that number already in some talks that that $25,000 a month would be a good income for a good programmer for a professional programmer But some programmers will get $200 $200 a month. So now we have more, you know more even distribution in the future It will be more Spread I think so point number six is How we can help people? encourage people to to give us knowledge and not to keep the knowledge in their heads is read on man read only master who view in in in in Raise your hand if in your project nobody can commit and push to the master branch Without a proper lead in the review. It’s about five maybe ten more twenty. Ok, many of you That’s great actually because I was asking that question a few years ago in a few conferences and there were just a few hands raised now we have more people so that’s I think a great instrument for protecting for for enforcing the knowledge transfer if you can not contribute directly to the master branch if you cannot push what you know right there in the source code if you have to pass some Code reviews or maybe a number of code reviews in our case. There are two code reviews So if you if you need to do that if you need to go through Quality control or I call it quality gate or quality of wall so there’s something standing in front of you which does not allow you to just vote just a Freely contribute without telling everybody else that will help as well So try to build that quality gate between programmers and the source code and make sure they need to go through something Before their knowledge gets into the code into the source code If you can manage that that will be that will encourage them to be more to share to share knowledge better to share knowledge more effectively because if everybody can just push You know without any anybody else looking at what they do then, of course they will stop isolating themselves into their own problems, and they will they will you know They will go directly production without telling everybody else So try to make the life of programmers more difficult that will make the life of project easier The more difficult for us is to you know to get into the master branch is to put our code there the better For the maintainability of the project. That’s the very idea of these quality gates We are almost close to the end we have two more the most provocative Number seven, no meetings, especially technical ones I think and here you may not agree with me

But try to hear me out. I think that meetings informal conversations sitting together in the room discussing technical stuff is how you Degrade your team is how you become less professional is how you kill your project the more you talk the more informal conversations you have first of all, the easier it is for you as an engineer because Speaking is easier than writing. Like I said before good and good programmers. They know how to talk the best programmers They know how to write. So if you cannot put your questions your ideas your concerns your Your thinking into writing into documents, then you are not you know You’re not as good as you could be if you can’t put your stuff in writing if you can’t ask that Questions in not in the room But in writing in diagrams and then show it to somebody else and get their opinion back from that somebody else also in writing that means maintainability predictability readability Traceability of everything that happened a year ago. We can have it in there in our documents very few teams can do that Unfortunately, we are just used to say hey grab your laptop. Let’s go to the room and let’s talk for two hours Just you know, let’s just get the pizza. That’s not how professional programmers work I believe this is how it looks like we work but that’s immature. That’s not professional we need to find a way how transfer how translate how to deliver our Ideas in writing in documents because like I said it first of all is good for traceability. We will know the future What ideas we had? Everybody else will know we will be replaceable I was at that meeting and then in half a year We changed 50% of the team and nobody remembers what happened at it at that meeting half a year ago Nobody we need to start another meeting. We need to talk again. We need to redesign everything or many things That’s not what people who invest in down projects want we as a team we as investors We as key lead engineers want the team to be want the project to be maintainable meaning that in a year anybody should be able to jump in and Understand why that database is designed that way in order to have that knowledge The best way is not to read the notes of the meeting or maybe you know Listen to the to the audio protocol of the meeting, but actually get more readable documents You know something which you may use. I don’t know which is gonna be it’s up to you in our case we use github just github github tickets readme files markdown documents and the source code and that It seems for many years already for a few years. It seems that that’s enough I don’t know what’s gonna be enough for you and the final one No chats That’s even more provocative. So we are in our team. We do not allow programmers to have any chance whatsoever. No slack No telegram No HipChat, nothing. All you can do is you have your ticket and then the ticket you have comments. You post that comments There you resolve one specific problem inside the ticket you solve it We see the solution you attach your code you attach your pull request it all gets in it gets to the production done So we never allow people to discuss what’s going on If you have something to discuss create a ticket if you have a solution submit your solution to the ticket So no informal conversations it may sound Counterproductive it may sound like where are the ideas will come from so where all the creativity will come from? again in our projects it demonstrates that discipline programmers actually appreciate that approach and they like it they like that they have you know, very discipline and very understandable clear Predictable way of discuss ideas instead of staying in those chats for for days and hours and and talking and talking and talking so Now that all I meanit’s try it. I’m not sure who of you actually in can you raise your hand even your team you have the same situation just tickets just source code no chats See, so give us a few years and I think that will get into your head this idea I think this is again the future of development. I think that you know being Non-professional I emphasize it. I think it’s not professional to use Informal communications for technical discussions. I think we can be more professional we can learn how to write our ideas down So my final point I think that we need to transfer knowledge Accumulating experts. Those are the bad guys people who accumulate knowledge They accumulate knowledge. They know too much. They know how things work and they are the bad guys We need to turn to expertise providers like those guys without $500 an hour I’m an expertise provider. I know what you need

I know I have the knowledge I give it to you and then I walk away. I don’t want to stay with the knowledge I want to drop that knowledge into the source code and forget it That’s how I work personally with mine. I have many open source project. You can check my github I know like maybe 20 Actively working projects like projects who which actually work and they people actually contribute to them and I don’t remember what’s inside of them I mean, I can’t keep this information in my head because that’s too much for me but I can jump into any of that project and every time I jump in I create a ticket for myself I Explain what the problem is I make the changes and I’m trying to forget what what I’ve done just now and I’m always have this Mindset in my in my head that I will need to forget what I was working on because I don’t want to keep it in My head I want to be expertise provider Not a knowledgeable guy in the project and my one of the final slides Is that the summary so the best engineers are the easiest to replace? That’s what I think so the easier you are to replace in your team the easier for the management to get rid of get rid of you and put somebody else in your in your the better engineer you are So that’s how we should think like make sure that you are the guy who the team will not need tomorrow do it Do it that way code that way Contribute that way make sure that you don’t remember anything you put everything in there everything in the code I’m not sure you have to show that to your management though Because yeah, it’s not going to be good for job security, but that I think should be the future Finally everything. I just said not everything but most of the thoughts are in my book called the head So this is what you have to do after listening to my talk First of all, buy my book second second. You can try Zerocracy If you have your project You can try how you our team can actually develop your stuff with all that principles in mind No meetings no chats paying for bugs Contributing with the knowledge not having any experts. You can try it out and you can follow me on twitter facebook Instagram Pinterest That was it thank you very much Many have questions and we think I think we still have time Right a few minutes. I believe any questions. Yeah, you can just say I’ll repeat the question Number four is yeah results. How do I sound? Oh, how do we calculate? How much to pay? That’s a good question in our case in its it’s up to you. Of course in our case I can only say how we do that in our case We are putting the very small and very fixed budget on every small micro task So we are working in micro tasks and we give programmers very small tasks, which are estimated approximately with the same estimation but we managed to achieve that after years of work and years of Experiments in your team in the team which works in traditional model that may not be easily achievable So I would suggest we started a few years ago, and we’re just starting we started with estimates So you are the programmer I give you the task but the task has to be small like really less than a day of work and then you give me the number of How much you how many hours and how many dollars you will? Charge or take for that test and we can do it like many many many times So when programmers initially they may not like it because they may sound like a bit too You know too – maybe too aggressive but in the end professional programmers like that They know that this test is three hours. This test is two hours. This one is one hour This one is four hour. And in most people in most cases people don’t make big mistakes So it this that’s how I would started but now we are making like really small micro estimates for all tests But we are you know, maybe advanced at this at this point anymore. Yeah Yeah, that’s probably related to this ticket So when we blame artifacts, we create many tickets or when we work on fixed tickets, then we then we have many tickets That’s the question. So we have many tickets in the repository. The question is, how can we find the information there? So instead of maybe it’s related to this one, right? So we have no meetings. No chat. So we have many tickets, right? That’s where people communicate and the question is how do we find information there in a few years? So, how can we actually That’s a good question actually and I think that I can only say how we do that is Github has a pretty powerful search tools. So you can search by keyword. You can search by the name of the class You can search by the name of the problem, but we still have problems with that. That’s true So sometimes it’s difficult to find what was the problem we worked a year ago, and how was it solved? I can’t find the ticket in some projects We have 3,000 tickets 2000 tickets and that’s a big number for a quite a small project and we do sometimes have problems Searching and finding but that’s still way better

Than just saying anybody remembers what was discussed a year ago by what’s the name of that guy? Who left? And what’s the name of that guy? Who left? I don’t remember what they were discussing. Nobody Nobody knows that so that’s better than looking at the tickets and searching the tickets and finally maybe finding the solution But I have to admit finding it’s it’s a problem. It’s it may be difficult. Yeah That’s good question, so how do I know if I’m looking at the ticket How do I know that the information in the ticket is still relevant or was relevant or something like that? I can only answer How do you know when you look at the when you cannot? you know run docker on some machine and you don’t know why it gives you this mistake you go to the Google you you search by date by that Message and then you jump into their github and then you see the github ticket Then you see up food downloads people, you know sending these fun emojis and then you look at this and you read through the whole story and then you find and then you make your own decision whether all this Situation all this information is relevant or not. I don’t know it’s not it’s not as it’s difficult to say exactly what’s wrong And what’s right? But at least you have the full traceability of what happened there who voted for it who voted against it in our project? we always have an architect and an architect has the leading the leading voice and the leading role and the architect can say in the Ticket, you know, what’s right and what’s wrong, but sometimes again I have to admit sometimes it’s difficult to say Where are we actually able to find a solution was it actually solved and what was there but still it’s better Than asking people around because here you have the full history Which is one two years old and you can see and it’s available. Most of our projects are open-source You can check them out You can see our portfolio and you can jump into github repositories and you will see all the discussions like in the open source world That’s the beauty of it. Yeah Yeah, okay, yeah the first question is we if we are paying by results if we’re actually like putting the Responsibility of completion to the shoulders of developer. So then how we resolve the problem of The results or the outcome being dependent on somebody else when the developer cannot solve the problem because there are some dependencies around Well in our case, we just ask developers to put the problem on hold and get back to this problem. Later So when you’re getting the problem We are getting the ticket to solve the job to solve and you know if you have the fixed budget But you cannot resolve it because there are some dependencies around Just don’t start working on that just say put my problem on hold because you guys gave me something which depends on so many other things so please solve them and then I will continue and then make it the problem of the management and then the management will see the Situation. Okay, we have this task and we have three more tasks around which are not completed and that’s why this guy cannot continue Okay. Now it’s going to be my problem as a manager what to do with this Maybe I’ll give more money to these people Maybe I’ll say I’ll tell them to focus on resolving that maybe I’ll do something But that’s that’s not it shouldn’t be the problem of the developer That’s true that’s a good question that it may look like ping-pong game between developers and managers and that may never end Of course when you depend on something and they depend on something else and then could be deadlocked It happens, but in our cases in our case in our projects it happens rarely and in that case the management jump in jumps in or the architect jumps in and Somehow resolved that saying that okay, we’re not going to stop working with it or put the highest priority to that So it’s all resolved a ball case by case Well, you know well every task that’s again my my understanding of how software development should work is that every task every Something every piece of work. We do has to return something back to the repository Even if it’s yeah Well, we expect first of all source code if you have to write if you can write something it just has to be source code If you cannot write anything, it has to be a piece of documentation Explaining why you cannot write their source code if it’s a script. It has to be a script It has to be something which may constitute a pull request

So we accept pull requests We always accept something back in a digital form which we can put put in the source code and then let you go So we never expect you know talks or discussions or opinions we always want you to contribute something from the source code because like I said in the beginning we think that it’s only healthy to treat developers as Knowledge providers not knowledge accumulators So every time you give us something we won’t actually you to give us something not to say that you know how it works But you don’t want we don’t want to we expect you to you know, not in a this harsh way But we expect you to leave tomorrow We expect you to expect to lose you or anybody else tomorrow And that’s why every time you want to completely get out everything You know out of your head and put in the source code from everybody for me as well So that’s that’s why we expect something digital in most cases it is source code That’s a good question, but I think we need to continue the discussion Outside of the room we definitely should I think we’re running out of time. Yeah, for some reason these guys. Don’t stop me So thank you very much. I’ll see you outside. We can continue the conversation