Suffering at work is not necessary
I watched here the other day Kate Gregory's speech at the Pacific ++ 2018 conference.
Kate is a good programmer and a great speaker. The report itself raises a lot of interesting things about C ++ programming and programming in general (worth a look). But most of all I was caught by one thought (literally in passing) expressed by it. Keith managed very briefly and in the case to identify the motivation of programmers. It sounded like this: "The programmer during work seeks to maximize his happiness." It sounds trite, but it is.
We can say that we support the project, customer, company, humanity and world peace (and this may even be true). But let's be honest. We are people and, like all people, first of all we strive to maximize our happiness - globally in all life, strategically in a career, tactically in the current project and petty here and now, when writing this function, this line of code. Yes, we are doing this and it would be good to figure out what makes us happier and less so. This will allow us to better understand our colleagues, subordinates and ourselves.
')
I just want to put aside the issues of wages, working conditions, superiors, staff and others. If you work where you work - then all this suits you. Let's focus on what makes us happy and unhappy when working directly on the code.
All projects with tests are equally happy, each project without tests is unhappy in its own way. I can say with confidence that programmers in projects with good test coverage are on average happier than in projects without tests in general. I even saw how programmers who were not approached by the authorities in writing full-fledged tests wrote them in secret (sometimes even during non-working hours). Why did this happen? Written test makes the programmer happier. Its very existence is already a sign that at least something in your project is done according to the best practices of the industry (even if the rest is not). The successfully completed test shows a beautiful green tick, praises the programmer (and after all, maybe no one will praise him anymore). Successful completion of 100% of tests gives some stable ground under your feet, when you can already believe in something - this adds to our confidence in today and tomorrow, makes us happier. And even a failed test does its job - it tells us that we have written it for nothing, praises us for our foresight. If you want to make the programmer happier, allow him (or even forcibly bind him) to write tests (of course, everything is good in moderation).
“I won’t tell you for all of Odessa”, but the majority of programmers I’ve met in my life were more likely to write new features than bug fixing the legacu code. And why? But because touching a bug is touching a misfortune. Something went wrong for someone and it was so important that he was not too lazy to bring his grief to the developer. We'll have to go into his position, try to reproduce. After that, either it will be possible to reproduce - and there will be a blow to vanity because of the admitted bug, or it will not work and you will have to (o God, no!) Contact a living person who discovered the problem and try to get more information. All this can not be called pleasant.
At the same time, writing a new functional is a potential touch to happiness. We haven't broken anything yet, are not guilty of anything. We write new code to solve new problems. Perhaps this will succeed. Perhaps we will receive well-deserved praise (premium, promotion). This is closer to the upper levels of the pyramid of human needs for Maslow .
What is the conclusion? The work of the programmer must be balanced, there should not be a single bugfix in it. Every programmer needs from time to time to entrust the development of new features. Yes, there is no way to get rid of bugfixing, but at least we can try to achieve an “approximately zero” balance of happiness and unhappiness in this matter.
Working with good code is nice. Unfortunately, good code does not fall from the sky. It is even impossible to take and write it from the first time. We have to make a good code out of a bad one, because there’s nothing more to do. Here, programmers make a choice: every day, coming to work, continue to suffer and work with bad code, or still take it and try to make it good. In the second case, one often has to fight with the leadership, who does not understand what it was possible to spend these N hours of time, if new features were not added to the product and the old bugs were not fixed either. Yes, I have to fight. Fortunately, in this war we have arguments: a concise and beautiful code is less error prone, its support takes less time (and costs less money), it is better to change when new business requirements appear, etc. In addition, this war, as a rule, is not long: it ends with some kind of compromise like “no, I won't give a month for refactoring, but let's allocate 2 hours a week to it on Fridays”. Okay, that's good. We just got ourselves a piece of happiness. Yes, it will still need to be built with our own hands, but this has already become possible.
Many probably know the pain of having to work in a project stuck for some reason on a compiler (framework, library) many years ago. They explain to us that for such and such reasons it is impossible to switch to a new version right here and right now, but someday, probably, if it works ... What can you do? Well, first, you need to admit to yourself that the circumstances were not in our favor and the situation makes us more unhappy than we could be. Secondly, the same idea can be voiced by the authorities (or the customer). Hardly anyone would argue with that. And at this moment you can try to bargain for something: for example, time for those very tests, new functionality and refactoring. (It is possible to increase the salary, but at the beginning of the article I promised to leave it behind the brackets).
By the way, the time spent on such useful tasks may not only make you a little happier here and now, but also eliminate the very “scary” reasons for which it was impossible to switch to using newer tools. The real situation of my life:
You can probably continue to explore other aspects. But the general thought is one: some tasks and circumstances make the programmer happier, others more unhappy. If the second is greater than the first - the mood and productivity of the programmer will fall, sooner or later this will lead to problems in the project or to his departure from the team. Therefore, both the programmer and his manager should not only think about the “global good” of the project, company or user, but also how to remain relatively happy to the developer. Otherwise, what's the point?
Performance video
Kate is a good programmer and a great speaker. The report itself raises a lot of interesting things about C ++ programming and programming in general (worth a look). But most of all I was caught by one thought (literally in passing) expressed by it. Keith managed very briefly and in the case to identify the motivation of programmers. It sounded like this: "The programmer during work seeks to maximize his happiness." It sounds trite, but it is.
We can say that we support the project, customer, company, humanity and world peace (and this may even be true). But let's be honest. We are people and, like all people, first of all we strive to maximize our happiness - globally in all life, strategically in a career, tactically in the current project and petty here and now, when writing this function, this line of code. Yes, we are doing this and it would be good to figure out what makes us happier and less so. This will allow us to better understand our colleagues, subordinates and ourselves.
')
I just want to put aside the issues of wages, working conditions, superiors, staff and others. If you work where you work - then all this suits you. Let's focus on what makes us happy and unhappy when working directly on the code.
Tests
All projects with tests are equally happy, each project without tests is unhappy in its own way. I can say with confidence that programmers in projects with good test coverage are on average happier than in projects without tests in general. I even saw how programmers who were not approached by the authorities in writing full-fledged tests wrote them in secret (sometimes even during non-working hours). Why did this happen? Written test makes the programmer happier. Its very existence is already a sign that at least something in your project is done according to the best practices of the industry (even if the rest is not). The successfully completed test shows a beautiful green tick, praises the programmer (and after all, maybe no one will praise him anymore). Successful completion of 100% of tests gives some stable ground under your feet, when you can already believe in something - this adds to our confidence in today and tomorrow, makes us happier. And even a failed test does its job - it tells us that we have written it for nothing, praises us for our foresight. If you want to make the programmer happier, allow him (or even forcibly bind him) to write tests (of course, everything is good in moderation).
Bugfixing and development of new functionality
“I won’t tell you for all of Odessa”, but the majority of programmers I’ve met in my life were more likely to write new features than bug fixing the legacu code. And why? But because touching a bug is touching a misfortune. Something went wrong for someone and it was so important that he was not too lazy to bring his grief to the developer. We'll have to go into his position, try to reproduce. After that, either it will be possible to reproduce - and there will be a blow to vanity because of the admitted bug, or it will not work and you will have to (o God, no!) Contact a living person who discovered the problem and try to get more information. All this can not be called pleasant.
At the same time, writing a new functional is a potential touch to happiness. We haven't broken anything yet, are not guilty of anything. We write new code to solve new problems. Perhaps this will succeed. Perhaps we will receive well-deserved praise (premium, promotion). This is closer to the upper levels of the pyramid of human needs for Maslow .
What is the conclusion? The work of the programmer must be balanced, there should not be a single bugfix in it. Every programmer needs from time to time to entrust the development of new features. Yes, there is no way to get rid of bugfixing, but at least we can try to achieve an “approximately zero” balance of happiness and unhappiness in this matter.
Refactoring
Working with good code is nice. Unfortunately, good code does not fall from the sky. It is even impossible to take and write it from the first time. We have to make a good code out of a bad one, because there’s nothing more to do. Here, programmers make a choice: every day, coming to work, continue to suffer and work with bad code, or still take it and try to make it good. In the second case, one often has to fight with the leadership, who does not understand what it was possible to spend these N hours of time, if new features were not added to the product and the old bugs were not fixed either. Yes, I have to fight. Fortunately, in this war we have arguments: a concise and beautiful code is less error prone, its support takes less time (and costs less money), it is better to change when new business requirements appear, etc. In addition, this war, as a rule, is not long: it ends with some kind of compromise like “no, I won't give a month for refactoring, but let's allocate 2 hours a week to it on Fridays”. Okay, that's good. We just got ourselves a piece of happiness. Yes, it will still need to be built with our own hands, but this has already become possible.
Using modern libraries and tools
Many probably know the pain of having to work in a project stuck for some reason on a compiler (framework, library) many years ago. They explain to us that for such and such reasons it is impossible to switch to a new version right here and right now, but someday, probably, if it works ... What can you do? Well, first, you need to admit to yourself that the circumstances were not in our favor and the situation makes us more unhappy than we could be. Secondly, the same idea can be voiced by the authorities (or the customer). Hardly anyone would argue with that. And at this moment you can try to bargain for something: for example, time for those very tests, new functionality and refactoring. (It is possible to increase the salary, but at the beginning of the article I promised to leave it behind the brackets).
By the way, the time spent on such useful tasks may not only make you a little happier here and now, but also eliminate the very “scary” reasons for which it was impossible to switch to using newer tools. The real situation of my life:
- We are not sure that the transition to a new library will not bring us new problems ...After 2 weeks - a new library in production.
- But I wrote 200 tests for code using this library, let's try to go and run them.
- Hmm, come on.
You can probably continue to explore other aspects. But the general thought is one: some tasks and circumstances make the programmer happier, others more unhappy. If the second is greater than the first - the mood and productivity of the programmer will fall, sooner or later this will lead to problems in the project or to his departure from the team. Therefore, both the programmer and his manager should not only think about the “global good” of the project, company or user, but also how to remain relatively happy to the developer. Otherwise, what's the point?
Source: https://habr.com/ru/post/431120/
All Articles