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.
