PM – Project manager (project manager).
You say the kettle will only boil for 5. The PM insists that the client is asking for it and it is extremely important to us, you bow under the pressure and decide to think of something. You put the bag in the kettle, pour the water in and wait for the water to turn brown. You clearly understand that you will have to remember to rinse the kettle, because this will leave tea rings and probably mold. You pour the dyed water for the client, and the PM says with a satisfied face: you see, you can do it. And you think that you would not want to be made like that… But circumstances require it. And just as you relaxed, the PM flies in and says: have you even tried it?
You realize that there seems to be no taste… You try to justify yourself, but then the PM interrupts you and says: what does it have to do with taste, it is not boiling and you quickly start thinking about what to do. You think about boiling for a long time and find a ready-made solution – an old boiling pot in the cupboard. You throw it in a mug, plug it in, it warms up, and the PM looks at you and says, ahem. We can’t leave that kind of dependence on cable… And you realize that it’s not a bad solution, you just need to fix it, naively believing that you’re going in the right direction. You find a battery, you plug it in, and everything works, but even the PM realizes there’s something wrong. And then comes the intrigue… The PM’s gone for an hour, two hours… You begin to think that they’re either discussing your dismissal, or PM somewhere lost, maybe he’s already decided to finish it himself. But then the PM flies in and without a bit of explanation says: the client is very pleased, we must also quickly make pasta. You are perplexed – they say okay, it worked, and you go and look at the kettle and think, what else can be done in it. But since it’s Friday night, you think enough of these adventures and agree with the PM on Monday.
Here it is Monday. You are full of energy and, having slept through the realization of what you did on Friday, you remember the pasta. Without a backward glance you put the pasta in the kettle. You add water and turn it on. A minute passes and you realize that the pasta does not color the water and how to understand that it is ready will not be so easy. But… opening the kettle fills you with extreme surprise. The pasta has indeed tinted the water. But the smell of tea brings you back to reality where you remember your TODO: wash the kettle. Given that there is no time, because the PM is about to come again, you stir this nonsense and think – come on, that was the task – to cook them quickly, not the color, the smell, write off on the inaccurate technical requirements. But then you realize that the noodles are not at all tea, and screwing them to the boilers, so that while they were carried to them they reached – not an option, because the customer will understand that this is a soup, not pasta. What not to spoil all the raspberries you boil with a kettle second water, but already in a bucket half full. It would seem: what is going on here, but no, the idea is still there. We cover the bucket with a colander, pour the kettle with brown pasta in the colander and cover with a lid, the steam pasta will reach the customer in boiled form. The PM flies in, you say with a happy face that everything is ready, hand him a bucket with a lid, a boiling pot, a battery. The PM’s joy on his face slowly turns into surprise or shock, but he does not seem displeased. He says, “okay,” and takes the bucket. You clearly realize that all this will end badly, and while there is free time to update the resume, but PM-mu say the nuances: the bucket do not open while the battery is connected – categorically impossible.
After a while, a new developer comes in and sees it all:
- Kettle, bucket, colander, boiling pot and battery.
- Logical questions are brewing in the developer’s mind:
- Why have a kettle when you have a kettle?
- Not kill someone with a battery.
- Why is the kettle black inside?
- What are the chances if you carry the bucket poorly – the boilermaker will sink, short out and the whole thing will explode.
- And the classic questions: how did it even work, since no documentation, no old developer and the second question is why was it done that way.
We could go on and on, but let’s draw some conclusions already:
- The PM screwed up because he’s afraid to say that normal solutions require a normal amount of time for the customer.
- The developer was not used to this pace and decided for the sake of the result, neglecting the consequences.
- TODO: – are done when something really comes out in this place or very rarely. You either have time to do it right away, or it won’t show up later. But there are exceptions.
- Similar processes can sometimes require very different approaches. And sometimes the normal solution lies just around the corner.
- Fear is our biggest enemy, and because of it there are understatements, excuses, fear to admit that you’re human and you can’t do anything faster than “your fast”, fear to tell the customer that we need accurate technical documentation and specific requirements, fear to ask a more experienced person, on a forum or at a seminar. Developers go to seminars, and half of them don’t really understand why. Yes they do, so ask if you don’t understand, this expert is there to make people understand, to see more.
- Lack of experience forms crutches that often force us to make decisions that lead us completely in the wrong direction. Like a ship: misjudged where the pole is, made a mistake of 2-3 degrees, seemingly a small thing, but after a week of moving in that direction, it could be hundreds or even thousands of kilometers to correct this mistake.
- Developers often think that the PM is smart and that all problems are his problems. But he, too, is human and can make mistakes. He too must be helped and told how to do things right and why something can go wrong.
- If you don’t have time for documentation, but you clearly understand that the code will not be easy – leave just 2-3 comments. So that after your vacation, you or another developer can correct a bug in your code. Comments in the code are fine, but commented out code is undesirable