managementAt Zerocracy, we work in distributed teams and keep all our communications in tickets. Besides that, we encourage every developer on every project to report bugs whenever he or she finds them. We even pay for each bug found. Once in a while, I see bugs reported along these lines: “Can someone explain to me how to design this module?” or even “I haven’t used this library before; please help me get started.” My usual answer is, “This is not a school; nobody is going to teach you here!” I realize this sounds rather harsh to most developers who are just starting to work with us, so here I’ll try to illustrate why such an attitude makes sense and is beneficial to both the programmers and the project.
Disclaimer: I’m talking about software projects here, which PMBOK defines as “temporary endeavors undertaken to create unique products, services, or results.” If your team is engaged in continuous development or maintenance of software, this concept may not be relevant.
No matter how unpleasant this could be, let’s face the reality: each software project is a business, and we, the developers, are its resources. Just like concrete, wood, and glass are the resources required to build a house, which is also a business activity. No matter how much we think about ourselves as a family having fun together and writing code because we enjoy it, each business looks at it completely differently.
The project needs us to produce classes, lines of code, methods, functions, files, and features. Then, the project can convert them into happy customers, which will give us something back—usually cash. Finally, the project will share that cash among us, investors, and the government.
A properly planned and managed project acquires the best resources its budget can afford and then relies on their quality. A programmer who doesn’t have adequate skills or knowledge is an unreliable resource. Obviously, no project would acquire such a resource from the start. However, this weakness may be revealed in the middle of the project.
Say you’re building a house and you contracted a plumber to install a drainage system. When it’s time to mount the equipment, he tells you that he’s never worked with it and doesn’t know how to install it. It was a risk, and it occurred. A good project manager always has a fallback plan or even a few of them. Obviously, the best option would be to contract another plumber. The worst option would be to train the original one on the spot.
Wait, why is that so obvious? The plumber is a great guy. Yes, he doesn’t know how to work with this equipment, but that doesn’t mean we should fire him immediately. Let’s pay for his training, send him to some courses, buy him some books, let him experiment with the equipment for some time, and then he will be able to install it in our house. Great plan, isn’t it? The plumber will be happy.
But the project won’t.
The goal of the project is to build a house, not to train a plumber. The project doesn’t even have funds to train the bloody plumber! If we train and teach all our workers, we won’t ever build a house. We’re not running a school here. We’re building a house!
While working on a software project, a good project manager has a staffing management plan that describes how skills will be recruited, tested, applied, and discharged when necessary. Such a plan may include training, but it would be as small an amount as possible—mostly because a plumber trained by us costs much more than one trained by someone else but does exactly the same, or worse, work. Thus, a smart project manager acquires project members who are already capable of performing their duties and falls back on training only in exceptional situations.
Now, a logical question: What should we, as programmers, do? We want to learn, and we don’t want to spend our own money on it. We don’t want to sit home for a few years learning all possible technologies before entering the job market as experts, ready to be hired. We want to learn on the job. We basically want to use project budgets for our own personal educational needs. Moreover, a smart programmer exits every project with some new knowledge, new skills, and new technologies in his or her portfolio.
However, if you make your projects spend their money on your education, that’s theft. And a good project manager should stop you, saying “This is not a school!”
What is the solution?
I believe that in the software business, there is only one workaround—blame the project for your own deficiencies in education, skills, or information. I’m being absolutely serious. Let’s discuss a few practical situations.
Say you have a module to work with, and it has to be written in Python. You have no experience in Python; you’re a Java developer. Who is at fault here? You could think of it as your problem and ask your project manager to teach you, but he should tell you he’s not running a school and get rid of you. That’s a bad scenario for both of you. Instead, blame the project manager. He hired you. He put you into this situation. He planned all project activities, so he probably knows what he is doing. This means that the project documentation should be detailed enough for a Java developer to create that Python module. However, it is not detailed enough. So report this issue and wait for its resolution. Explain in your bug report that you honestly started to work with the module and realized that its documentation is not complete enough for a Java developer to understand. Ask the project manager to fix this. If the project decides to invest its money into the documentation, you have the chance to read it and learn. Thus, the project’s money spent on your education will also contribute to the project. It’s a win-win.
Here is another example: Say you have to fix a Java module and you’re a Java developer. You understand Java, but you don’t understand how this algorithm works. You could blame yourself for not reading Knuth in school and ask the project to train you on it. A good and strong project manager should tell you that it’s not a school and get rid of you. Again, a bad scenario for both of you. Instead, blame the project. The code is not self-descriptive and is difficult to understand. The algorithm implementation is not obvious and is poorly documented. Ask for better documentation. If the project invests its money into the documentation, you will learn the algorithm from it. The source code will be improved, and you will have improved your skills. Win-win.
One more example: Say you are tasked to implement a WebSockets back-end in an existing web app. You know how WebSockets work but can’t understand how to connect this new back-end to the existing persistence layer. You are rather new to the project and don’t understand what would be the right design. You could ask for the project to provide training to explain how the code works and how it can be extended with features like this one. A project manager should tell you that you’re not in school and are supposed to understand the software if the project is paying you a software developer salary. And he will be right. But it’s a bad scenario for both of you. Instead, blame the project for incomplete design documentation. Good software should properly document its architecture and design. Ask for the project to provide such documentation. If it invests its time and money into better documentation, you will learn from it and find all the necessary answers. Another win-win.
There are a few other examples in my How to Cut Corners and Stay Cool post.
In conclusion, I would recommend you remember that software projects are, first and foremost, business activities where we, the developers, are resources. In order to obtain something for ourselves in terms of education and training, we should align our goals with project objectives. Instead of asking for help and information, we should blame the project for its lack of documentation. By fixing this flaw, the project will improve its artifacts and, at the same time, provide valuable knowledge to us, its participants.
