How to Cut Corners and Stay Cool
Meetings Are a Threat to Code Quality (video).
Get Rid of Experts (video).
Transcript
[00:00] Hello. Shift-M podcast. My name is Yegor. Episode 28. It’s going to be just me today, no guests, and we will talk about management as usual, and I will try to summarize my thoughts about recently published article and a number of conference presentations I made over the last few years, and 1 video I published last month. They are all about how we can turn our laziness into the constructive direction. Not just turning the laziness into something productive, but actually being productive by being lazy, because in most cases we think that laziness is something negative and we are not supposed to be lazy. But I am saying in all these articles and presentations, that actually professional developer has to be constructively lazy, has to try to always find ways to do less instead of to do more. And now I’ll try to say it all again, but maybe will give a few more examples and we’ll try to go a little bit deeper into this subject.
[1:29] So, let’s start from the problem. As far as I understand it, according to my personal experience as a programmer, every time I start touching some code – my code, or the code which was written by somebody else, or the code which I wrote years ago and I forgot, and I need to make to make some [1:50 inaudible voice], it always is a problem for me of how can I actually understand the scope of the problem, and what to do with the scope when it’s so big. So, the biggest problem I always have to deal with as a programmer is the complexity in front of me. So, in order to change something or modify the code or fix the bug in the code, I have to understand how it works, I have to understand the algorithms, I have to understand the design and the architecture and all that. And let’s admit it; the majority of code is not well-designed code. In most cases there is no design and there is no architecture, it’s just some code. And the code is quite large in most cases. So it’s a big amount of lines of code, of statements, of files, of classes, of methods, and has to be fixed. So I have to find a way to fix all of that. Not all of that, but some part of that. And the problem is how to isolate that part.
[3:12] So, how can I know, where to stop? The more I dig deeper into the code, the more I try to understand how it works, the longer it takes for me, the more time it requires, the more efforts it requires, and the lower is the chance for me to fix it at all. So, the problem is how I can see the end of my work. How can I predict an estimate, the scope of the problem? So if something needs to be fixed – usually it’s a small part of the entire project, usually it’s a bug fix or a small feature needs to be introduced – that’s how we usually work. But when we touch the code, when we touch the code base, we understand that its size and its complexities way bigger than the amount of time we have for the particular ticket we’re working on right now. And that misalignment of scopes creates a lot of stress and creates a lot of frustration for me as a programmer. So I always want to abandon the whole thing, and I don’t want to touch the whole thing. I just don’t feel pleasure in touching the code which is big and not clear for me.
[4:50] So what happens, what I do, or what we all do is that we get frustrated, that’s first thing for sure, and then we just roll our sleeves and start doing what we have to do: we’re trying to do the right thing; we’re trying to refactor as much as we can around all this mess; we’re trying to understand how this mess works; we’re trying to ask questions about it; we’re trying to become knowledgeable enough about that code, so we’re trying to educate ourselves – we’re doing a lot of work, the preparation work, the learning work, analysis, before we can actually start contributing, before we can actually start making things. And if we stay in this project for longer, then we’re trying to know as much as possible about that code base in order to remove the frustration in the future. In order to make it easier for us in the future to work with this code, we’re trying to learn the code, we’re trying to become experts and knowledgeable enough about the problem domain, about the technical domain, about all the tricks and secrets of this code base and all that. And that helps us, of course. That helps us and that’s why in so many projects usually managers and team leads assume that a new programmer would definitely need some time before starting to be able to make any changes in the code base. Usually it’s a month or sometimes 2 months – it’s a long period of time, when you join a new team , you know, you usually can ask, you can say that you need like a few months to understand what’s going on, to learn the code base, before you can actually start making changes. And I’ve made a number of presentations about that saying that that’s a really negative practice, it’s a negative symptom of a project, if this is what the project requires new programmers to do. If it’s necessary to learn the code base for such a long time, if it’s necessary to spend so much time together on track, so called “get on track”, then it’s something wrong with the project. But it’s not something wrong with people; it’s not something wrong with the programmer who is coming in, or manager. It’s a defect of the code base. If the code base requires us to invest so much time to into learning it first before we can start making changes, it means that it is too messy, it means that the scope is not decomposed properly. It means that in order to fix a small detail inside some small class, we need to know how the class works, than we need to know how module works, then we need to know how the module connects to other modules in order to make a small correction inside a method.
[8:13] So, my point is that the knowledge, which we need to acquire in order to contribute to the [8:27 inaudible voice], to contribute to the product we’re developing, has to be inside the product and has to be easily available for programmers. A programmer has to be able to easily understand how to make changes, how to introduce new features and how to work with that. And by easy, I mean hours, I mean sometimes days, but definitely not months. So this stress and this frustration which happens when we deal with scope which is too big, which is too complex, which is unorganized, which is messy, is the fault of the code base. It’s a defect of the code base. It means something is wrong with the code base. And this is the attitude, this exactly attitude is not what the majority of programmers actually are ready to share, are ready to feel. So, most of us feel that it is us, who is guilty, if we don’t know how to make changes, if we don’t know how to fix the bug, if we don’t know how to work with the code. So we feel that it is something wrong with our skills or something wrong about our professional abilities to be a good programmer and work fast.
[10:13] And that’s why we think that when we join the project we’re becoming sort of the junior programmers, even though our skills, you know, let’s say, we’re good Java developers, we were good Java developers before, and then we join the project, we don’t understand how it works, and we stay like at the level of junior developers for quite a long time. And then in a half a year or a year become smart in the borders of this project. We become knowledgeable, we become fast with our changes, and we’re so accustomed to the territory, then we can say: “Okay, now I am a senior programmer in this project, in this company”. And that’s wrong. That attitude is wrong, we must not feel like that, we must feel in a completely opposite way. It’s not our fault, that something is not clear. It’s not our fault that we need more time to understand the scope, than just a few hours or just a few days. So that’s a very fundamental misconception of responsibilities, let’s call it this way. The responsibility of the code base is to be clear. The responsibility of the programmer is to contribute at the full speed, when the road is clear, so it’s like, you know, we can put a metaphor: if the programmer is a driver in a car, and the project is the road. So if the road is not smooth, and the road is full of garbage, then I cannot drive fast, but it’s not my fault. I as a driver am not supposed to be able to drive fast at the road which is not clear. I just can’t do that, and it’s not my fault. It’s just the fault of the road. It is a composite fault of everybody, who contributed to that project before, who made that project messy, who made it difficult to understand. It’s a fault of previous managers, first of all, it’s a fault of previous architects, it’s a fault of previous programmers or current programmers.
[12:41] Everybody who is working on the project, who is contributing to this messy situation, who is not clearing the project, who is not cleaning the argumentation, architecture, the design - everything. Those people are guilty, but when you join the project, when you start working with it, it’s not your fault; it shouldn’t be your fault. But that’s not what people think. And that’s why in one of my videos I said that our, you know, innate and our human altruism (altruism is our desire to help others) actually is going us a bad favor. So we like to feel, it’s normal, it’s natural, we like to feel ourselves as good citizens and we want to be helpful to the project, we want to improve things. It’s difficult to imagine a programmer – well they definitely exist, but these are just exceptions, I’m talking about programmers that just don’t care about the quality, they don’t care about the project; they just come in to just get their money, and they don’t want to improve things. It happens, but this is not the majority. The majority of the programmers, according to my experience, they do want to work in a good environment, they do want to be good citizens, you know, good project members, and they do want to contribute. They just don’t know how to do that right. They put their altruism into the wrong direction. Instead of helping the project in a true way, in a right way, they’re just trying to help the project.
[14:41] So, imagine the road is messy, and it’s full of garbage; you are sitting behind a wheel of the car, and you have to drive there, but you can’t because the road is not clear. Then you still start driving, you try to push your car to that garbage to probably somehow clean the road while driving, or you’re trying to drive left and right to find a right way through that garbage instead of just stop and walk out of the car and clean the mess somehow, clean the garbage, remove it from the road, helping you to drive through and helping everybody else to have the road clean. So what we are doing in most cases – we just feel that our responsibility is to drive and to code, to help, and no matter what. Instead – I would say that, you know, hold your altruism, try to be more egoistic, let’s put it this way, try to think more about your personal effectiveness, your personal results. And when you cannot achieve your personal results, when you cannot resolve the problems assigned to you by the manager, and the most effective way and the fastest way, in the easiest way, then you stop, you get out of your car and you start blaming the road, you start blaming the project, and saying “Here’s a messy piece of code, here’s something is not clear, this module has to be refactored, this architecture is missing here, I don’t understand the architecture, it is not obvious for me” and all that. So you, as I said in a number of my articles, you have to blame the project instead of blaming yourself. There has to be somebody to blame, so let’s not be afraid of the word “blame”, because we need to blame somebody in the situation where I need to fix a bug, which is supposed to be just a few lines of code, but I can’t do that, because I don’t understand where to put these few lines of code. And then I start blaming somebody, and you can either blame yourself for being stupid, or… well, I blame myself for being stupid in these situations, but then I realize that there’s something wrong, I shouldn’t blame myself. Because, like I said, it’s not my fault, it’s the fault of maybe my previous self, if it’s the project of just a few people and I was the author of that mess, and I was an author of that scope problems, which the code base has. But I still blame myself. And I’m always trying to stop that and say: “Wait a second. It’s not your fault; you’re not supposed to be smart enough to understand everything in this code base. You’re supposed to be a good citizen, who is always thinking about the project, and who is always thinking about the good situation, good state of that project”. How can I think about that? I can constructively and honestly put the blame back on the project and ask the project to fix itself. By project I mean the code base. So I’m always trying to revert that blame from myself to the code base and then see what I can do with that.
[18:44] So yeah, in my recent article on the blog - it was published less than a month ago - I gave a few recommendations, I said everything that I’ve just said to you, I mentioned the same as: the altruism is bad, don’t blame yourself, it’s just a slogan line I’m always using: “Don’t blame yourself”. And unfortunately, what I see, what I experience in many projects I see around myself, the programmers I see around – they still continue to blame themselves. So they’re always saying “”I’m not smart enough to understand it, I need to ask somebody who is working on this project for longer, I need to learn, I need to study, it takes time, it’s not so easy, and the project is so complex, there are so smart people there, I have to still learn a lot from them” – all those words. Needless to say it’s not correct. We should not do that. And else I said in this article, I’m just looking at it right now – I said that the project, unlike your mom – I put these words there and just crossed them out – the project doesn’t expect you to be intelligent or tax-savvy, the project needs you and expects you to close tickets. By close tickets I mean implementing some functionality or fixing some functionality. Maybe not in all projects you have those tickets and ticket racketing systems, but we are programmers, and we are, let’s face it, we are resources for our projects. So we need to contribute with the work, with the code we write, or the design we do, or the diagrams we design, or the algorithms we invent – something. So we bring something back. And this is what the project needs from us – to bring something back. The project doesn’t need us to be smart, to be intelligent, and to be someone, they want our results, they don’t judge us by who we are, and they judge us by our results. But that’s against our expectations of dealing with people. We think that we work for people, for a boss, for the architect, for the group of people, instead of working for the project by itself. So we feel, we think, we expect that we’re judged by who we are instead of what we produce. And I’m not saying it’s wrong to think that way, because in most companies it is the way it is, in most companies you are judged by who you are, not by the results you produce, if you’re not a good friend with the entire team – then most likely you will be.. maybe not fired, but you’ll not be promoted, you’ll not be as respected as somebody who is producing less code than you are, producing lower quality than you are, but who’s a good friend with the boss, who’s a good friend of a boss of the boss and all that. So, that’s called politics, right? People in most companies are earning respect, earning the position of the company by working for people instead of working for project. Unfortunately, that’s the way it is. It is unfortunate and I’m saying that it is bad.
[22:44] I’m trying to deliver this podcast to people who are… mostly for managers, so even if you are a programmer now - maybe you’re a programmer now I think the majority of listeners are programmers now, but you will become a manager sometime in the future, I think so, it’s just a normal, natural career path for the majority of programmers. I think so. To become some sort of maybe not a manager, but an architect or a tech lead – somebody, who will sort of coordinate other people or manage other people. So I’m trying to fix that situation, I’m trying to convince you that the right way to work is to work for code bases, let’s say this, to work for projects, which of course have customers, stakeholders, managers, bosses and other employees, but our goal as technical experts, as technical contributors, let’s not use the word “experts”, but technical contributors – our job is to be useful, is to be needful… I think the right world is to be useful for the project, not for some individuals who are judging us by who we are. But that’s not overused to see in companies. Usually it’s the other way around, usually when we say to our manager that “Look, I don’t understand how it works, I don’t understand how are these databases designed, I’ve been looking at it for 2 hours already and there is no documentation or explanation of the database scheme and I don’t know what these two tables are for”, then the manager would think that “There is something wrong with this programmer, most likely his/her intelligence level is not that high, so maybe we will start thinking about our hiring decisions we made”. And we’re trying to prevent that, we don’t let that happen, so that’s why we better say “No-no, I understand, I understand how the database works, I just need more time to figure out what these two tables are for”. And we will figure out. I will find out what they’re for, I will just need more time to investigate and learn and everything. I will acquire that knowledge, eventually. All I need is just to ask to buy the time from the manager. All I need is just to convince the manager that I’m smart enough, but a little bit more time is required. That works, well I’ve done it many times myself, but that only means that the manager is not professional, the code base is messy, and I am not helping them to fix themselves. So I am not helping to make the road cleaner for me and for all other programmers who are going to drive by that road in the future. I am just finding the best path through the piles of garbage staying on the road. And I will find that path, of course, I will learn how to drive on this messy and full of holes road, I will find that best way. But it’s going to be my knowledge and I will know how to do that. All future programmers coming after me, they will have to find it as well; they will have to learn the same mistakes I learned, the same lessons I learned.
[27:05] So, back to my point, is that a good project, a properly organized project, it doesn’t expect its programmers to be smart. It doesn’t expect them to be good soldiers, to be heroes and to play heroes, and be ready to learn whatever that they see in front of them. A good project doesn’t want that heroism to happen. Instead a good project expects programmers, expects everybody who works in the project to bring back information and to raise concerns, when they see problems, when they see inconsistency, when they see something wrong with the artifacts, with the deliverables with the code base. So in a good project a good project manager doesn’t expect programmers to hide problems, doesn’t expect them to say “Yeah, give us more time, we will figure it out”. A good project expects them to be constantly as negative as possible about the problems they see around. A good project expects them to fail fast, let’s put it this way here as well. Don’t conceal problems, don’t make them invisible, don’t make your project manager happy by saying that “No worries, will figure it out”. Instead – try to make the project manager as unhappy as possible all the time by telling them (there could be many project managers, could be many architects, could be many people on the projects), don’t be afraid, the project has to expect people not to be scared of raising concerns and letting everybody know what’s wrong and what’s going wrong. That would a good project do.
[29:16] Unfortunately, it’s not happening, so, of course, be prepared for resistance, be prepared for blame, be prepared for expectations coming from the project telling you that “We hired you, so you’re supposed to be smart, so how can’t you understand how the database works? Are you a database expert? You said at your resume that you’re a good Java-developer, senior Java-developer and you know databases. Now here is the database and you are saying you don’t understand how it’s designed. So it’s obviously some inconsistency of the information, so maybe you lied to us or what’s going on?” That could be the reaction, but that’s the reaction of an unprofessional manager. I’m not sure that you’ll be able to find a professional manager, so I can’t just recommend you to do what I’m saying now and just every time you see a problem you just raise a ticket and say “I can’t work like that, I can’t continue to work, until the database is documented, so let’s find the way to document it for me and then I can continue”. If you keep saying it in your project, most likely you will have problems with project manager, who will start thinking about finding a new developer, who’ll be more quiet, who will stay calm, who will not raise hell in any possible point, because that will make the project manager’s life easier on a short term. But on a long term, people who are not taking a blame for the mistakes they’ve made and people who are constantly interested in really being good citizens, not in looking like good citizens, but by actually being good citizens. So a good citizen is not the one who says “yeah, let’s not tell anyone that the road is messy, let’s not tell anyone that there are piles of garbage on that road. No, let’s pretend everything is fine”. This is not a good citizen. A good citizen is the one who goes on that road and starts calling everybody else and saying “Hey, people, look at the situation we have here! The cars cannot drive, we need to fix the road, we have a lot of problems in here, so let’s do something about that”. That would be a good citizen I guess.
[31:53] So in this article I published last month as I said I gave a number of examples of how actually a programmer can be a good citizen, can help the project improve itself, and I said that the best way is to create tickets. That’s the main recommendation I keep giving to everybody. Work through tickets. Maybe that recommendation will actually help you to avoid that personal resentment you may get from people around you. Because if you start saying in the office out loud “our code base is messy, I don’t like how it’s designed, I don’t like our database” they may feel and think that you’re just whining about everything and you’re just a negative person. They may even start telling you that “this negativity is not tolerated in the project, we don’t like it, please just stay quiet”, even though you’re being constructive, you’re being professional, you’re not saying that “I don’t like someone personally”, you’re not saying “I don’t like this project in general”, you’re not saying “I don’t like the mission of the project”, you’re saying: “I don’t like that these 2 tables in the database are not documented”, but if you say it out loud, most likely you’ll have negative reaction. So that’s why I am suggesting using tickets, I’m suggesting to go through a more formal way. So find a ticketing system, I’m sure all projects have that and submit your concerns as tickets, make sure they’re properly documented, make sure you say everything you can say in that ticket, you do it in writing, so you explain your point, you don’t generalize, don’t say that “Hey, our code is messy”, or “Everything is broken here” – be very specific, say: “Table #5 does have some data, but it is not documented, what these data is about and how they’re related to other tables, for example”. And then you will get a number of this ticket and then you will go to your manager and you can say that you cannot continue to work effectively with a problem you’re solving now until the ticket #123 is not resolved. That would be a very constructive criticism you bring back to the project and a very constructive negativity about the code base. And that will help your manager to do something with that because in that case the manager will be able to also constructively outsource that problem to somebody else, or maybe to you, maybe it will come back to you and the manager will say: “Okay, I understand, so please stop working on what you were working before and now fix the ticket you’ve just created. So, we know the problem, we know that the table #5 is not documented, how about you allocate a few hours of your work time and document it? As long as you’re already here, you’re already with this problem; you’ve already started to work on this direction. So how about you look deeper into that table, you understand how it works, you invest your time, you have this time, and we give this time to you because, you know, you’re in the office. So make sure that the documentation is clean and come back to us when your ticket is resolved”. And you do that, but in that case your frustration will be way lower because you know that now you are working on the specific ticket, you’re cleaning the road, you’re removing the garbage from the road, and you are making the road cleaner, so your scope of work is pretty isolated. You perfectly understand the borders of the scope, you know what’s the criterion for finishing that scope, you know that when the documentation is there, when the table is documented, then the work is done. That was an example of how you decomposed a bigger problem into 2 smaller ones. Well actually we don’t know if there will be 2, maybe there will be more, but you manage to isolate one problem out of a bigger task.
[36:41] So that’s my recommendation: in all cases just make tickets. You don’t know something – make tickets, you don’t understand something – you make a ticket, you don’t want to understand something, you find it too difficult for you, you find it out of your professional area of interest - let’s say you’re a Java-developer and there’s a bug in Java-script piece, then again make a ticket, and say that this has to be fixed by somebody else or just in some other task. Each ticket is a kind of a help to your manager to create a new task. When you’re making a ticket, you’re helping your manager to know what tasks the team needs to do. Another point of all days is a very high visibility of scope for the manager. Because when you’re concealing problems, when you’re not making them visible, when you just work and work for quite a long time and it takes weeks and days and weeks to understand everything and to document, maybe, the tables, or to understand how they work, and then finally you fix the problem - you’re doing a really bad favour for your manager, you are hiding the information about what you are doing from them. So you’re making yourself as a resource - like i said, we all are resources - so you’re making the information about the resource hidden, and that’s why the resource becomes unmanageable. In order to manage you, your tech leader, your manager or the person who is coordinating your work has to know what exactly you’re working on and the finer is granularity of information - the easier you are as a resource to manage. So if the granularity is too high, and all they know about you is that you’re working on something which you’ll report when you’re done, that’s all we know, and you’re staying with this task for a week already, that’s an absolutely unmanageable situation. Unless you are some crazy scientist who is supposed to invent some superfast algorithm which we just cannot decompose into elements, you just think and then you relax, and then you drink, and then you sleep, and then you think again, so we don’t wanna touch you, so just come back to us when it’s done. so this is not software development works. The majority of tasks are pretty routine and and decomposable elements. the work consists of classes, methods, tasks, task scripts, modules, deployment scripts, all those elements are pretty decomposable. So when the task is in front of you - it’s your job as a developer, it’s your job as a programmer to break it down into pieces and make those pieces visible to your manager, to your team. maybe you don’t have a manager, maybe it’s a sort of flat team, it doesn’t matter. But you need to make your progress, you need to make your problems and concerns and impediments - everything - visible. And not just in saying, not just in announcing them on this morning standup meetings, but making them visible through tickets, in writing, because that’s how you make it manageable. If you’re just saying that “I have problems”, that’s negativity, that’s not what the team will love to see and that’s what brings stress to the entire team because everybody around will feel that something’s wrong, that something is unfixable, something is, you know, fundamentally wrong in our project. and that maybe it’s start to quit. You don’t want that, you don’t want to create that kind of feeling. You want to create the feeling… well you don’t want to create any feeling actually, you try to stay away from feelings and you focus on objective facts about what’s going on. so don’t put emotions and don’t say that “I’m frustrated, I’m fed up with this database structure, I can’t work like that, do something about it”. That’s destructive, that’s negative. but correct way to report is like I said, like, make tickets and say: “Table 8 is not documented, table 5 is not properly documented, and table 7 has some defects in its design and can’t be improved”. And even better if you can say in each ticket to report you can give recommendations for improvement, you can say “The table 8 doesn’t have enough indexes, for example, and that’s a bug, that’s a mistake, I think so, and that’s why I would recommend to create these 2 indexes which will improve the performance and so on and so on”. That’s a very positive way to look at problems and we do have problems, everybody knows that, and the manager knows that, but your job as a developer is to make them visible.
[42:18] And a few more words about why it’s not happening, again I said in the article, I’ll just go through them again. So, the first why we’re not doing that, is that like I already mentioned we feel guilty for being not smart enough. Just don’t do that, just stop that feeling. Maybe one recommendation here for you if you’re a developer and you’re listening to this, if you’re a manager you can encourage your programmers to do that - we all want to be valued. We want to be, you know, important. We want to see that everybody in a team see us somebody who is important, who is valued, who is professional developer, even though we’re junior, whatever. And if we cannot solve the problems which are in front of us, if we keep creating those tickets, if we keep, you know, returning back our job, our tasks, and we keep making complaints about things around us - we will never or rarely finish it. Because you know, in order to finish something we need some things around us to be resolved and I need the road to be clear in front of me, and I can’t do that because there are so many holes in it, and there is so many garbage in front of me so keep complaining about it, and I’m making tickets, but my main tasks are in hold, so i]I cannot really drive. I’m waiting for the road to be flat. And it’s not flat. so waiting and waiting and waiting. And my self-esteem and my self-confidence will go down, for sure. I will think that maybe everybody around me doesn’t think that I’m a good developer. and they’re not gonna promote me and I’m gonna stay in this team for longer and they don’t value me and so on.
[44:30] So I would recommend everybody to do something aside of the direct project tasks and the tickets assign too. So do something else for this project and maybe for yourself. For this project besides reporting problems you can also start reporting suggestions for improvements, you can start saying “What would you improve in the project, what would you do better?”. You can even suggest yourself as an improver. You can say “I would be interested to refactor that module, I would be interested to remove that code duplication here, I would suggest to create the ultimate testing for that module”. That will help you to feel better and that will help everybody else to see that you’re not only complaining about everything, you’re also suggesting and making changes, and making improvements. that’s first recommendation. And second - I would say: do something on the side, do some open source activity, do some blog writing, something which will help you feel valuable for the community. So always remember that the project you’re working in is not the entire community, is not the entire industry. There are way more people around you who you will meet in the future, who you may work with in the future. So, connect with them, do something for them, not only for your boss, right? Write some open source, contribute to some open source, do something on the side. that will help you to feel better about yourself. And you’ll not be that ashamed when you gonna say to your boss that you don’t understand the design of the database. You will say it as a professional who has the right to be not knowledgeable enough about that particular database.
[46:35] You know there is a joke we had in our telegram chat like a few weeks ago, and someone said that when a junior programmer says that something is not clear in the code, then it’s a bad programmer, but when the senior… So it’s in the interview, so on the interview, when you’re a junior, you cannot say “I don’t know that” because that means you’re a bad programmer, you are not you know smart enough. But if you’re a senior programmer and you say “I don’t know that, I can google for it” - then it’s okay, it’s acceptable. so for senior programmer it’s acceptable to say “I can find it in google”, for a junior one it’s not. the same here. So if you will feel that you’re a junior, if you will not have enough self esteem and self confidence, then it will be very difficult for you to say that “I don’t understand how this database is designed, I need somebody to clear it up for me, I need somebody to write the documentation”. If you are a junior and you feel like a junior, if your self understanding is like you are a junior programmer - then you will be very much, you know, afraid to say that. You’ll not be comfortable by saying that. But if you feel like a senior, if you not that, for example, you are one of the key contributors to the database open source library or something like that, and you know databases, you know that because the open source community respects you for your contribution to some big library then you will have no problems saying to your boss and to your team, and to your architect that “You know guys, I know a few things about databases, but this particular database is a mess. So how about we change it here, here and there?” So you will not feel bad, and that’s the key point. it’s not so important about how the project will feel about it, because likI I said - most projects will most likely not welcome your negative thoughts, actually. But if your keep doing the suggestions, if you keep doing these tickets, if you keep reporting problems in a constructive/negative way/positive, then the project with start improving as well. They will start to understand that what you are doing is actually helping them. But for you, in order to do that, you need to be enough internally, inside yourself, you have to be sure, that you are a good programmer and no matter what, let’s put it this way. A few more points I’m reading right now, yeah, I’ve already said about that, that don’t be afraid, your attitude actually is positive, I’m saying that in the article too, so when you’re doing these complaints, when you’re reporting them, you are actually positive, even though it looks negative. And I’m suggesting I have another article actually, where I said how to report a problem so I said it’s called “The right way to report a bug”. In this article it’s said that when you report a bug, try to be as critical as possible, let’s not say negative, let’s say critical. so don’t say in your bug report like “Yeah, maybe, could be better, I would suggest, if you don’t mind if you don’t change it, it’s okay as well”. No, be very critical, say that “The whole thing is broken, the database is okay, but the table here is not documented, and is completely lack of documentation, it makes my life difficult, it makes my work difficult, it makes it impossible to implement these and these features”.
[50:34] Exaggerate the problem. Exaggerate the consequences, make it look very serious, and that’s how you will again help the project. But, like I said in the article, I said “Make it in a very constructive way. Don’t make it personal, first of all. Don’t blame people, that’s for sure. You never ever blame people, you always blame the artifacts. Who created the artifacts - it doesn’t matter, even if you know that this piece of documentation is created by your friend, maybe not your friend, but somebody who is sitting next to you at next desk, but you don’t say in your bug report, or in any complaints you have, you never say “You know this table which was designed by Jeffrey? It’s completely wrong. And Jeffrey’s doing it wrong all the time.” That’s not what you say. You say, no matter who did it, you say this table is completely wrong, it’s designed in bad way, even if you designed it. Sometimes it happens to me as well, I see the code which I created months ago, or maybe a few days ago, and I make a ticket and I say “Hey, this code, even though it’s in a code base, it is wrong for this and this reasons, and it has to be fixed, it has to be refactored, or completely removed, or improved, whatever.” You don’t pay attention who made the code. You just blame the code. And that’s what makes you professional developer. The ability to be absolutely objective about the artifacts and absolutely neutral about people. You don’t care who are the authors of the artifacts. You always blame the artifacts absolutely not looking at personalities, you don’t care who these people are, who created the code. You only care about the artifacts. that’s the kind of programmers I love to work with, to be honest. So when I see they are capable of being absolutely sceptical, critical, negative about artifacts and absolutely neutral about personalities - that’s the most effective, the most professional engineers I enjoy working with. So that’s probably what I wanted to say, that’s a good summary of this discussion. And hope you learn something even though I said it many times on the blog. I will put always links to these podcasts, read them, watch a few videos I made a few years ago, a few presentations, and see you on the next episode. Thanks for your listening. Bye-bye.
