How to achieve 0.1x developers
Leaving aside the controversy of the 10x developers, i.e. developers that are 10 times more productive than a “regular” developer, we may find some common ground in 0.1x developers, i.e. developers that are 10 times less productive than a “regular” developer. There are many ways to get 0.1x developers. Here are 12 examples, which you may choose to combine for greater effect:
- Choose the most cumbersome tools possible for the job. For example, CI/CD is possible from code repositories by uploading a text file. Instead, use a GUI with a series of clicks and random times to wait between them. Penalize the developers for not waiting attentively by forcing them to start again the process if they take too long for any click after possible. That is more engaging, your executives will be happy to see you embracing the “attention economy”. Use 2 factor authentication, e.g. messages to mobile phones in several steps of the process, to try to stop developers automating the previous process.
- Disregard any possibility of unit tests, force manual tests, e.g. requiring to test in a server with several ssh hops and disabling access from anything that is not an interactive shell. Certainly developers will try to bypass this by having mockup tests or data. For machine learning this is easy to prevent, even if the code runs, the accuracy may only be checked with the actual data. For other areas of work, there may be other unexpected situations, including the data in the database changing in subtle ways, making the code break in new ways.
- Make every feedback loop as slow as possible. If a small change in one line of code requires one hour of overhead for testing, every line may require several hours of work. Eventually, developers will start to code blindly without any feedback, which will result in more bugs and slower development. This is best when combined with the previous points. For example, only the team lead may be able to access the server for the testing of the new versions.
- Use “metaprogramming”. For example: use global variables for everything, nest them in templates, and use environment variables in runtime to compose the names of the templates that will be instantiated in different parts of the codebase. Some developers will try to use a debugger if they have the values for the environment variables, which is already good for 0.1x developers. However, if the values for the environment variables are not shared, this may get your team to 0x developers.
- Set up meetings, many of them. Technically, one meeting will disrupt productivity for developers for a long time before and after the meeting (see maker time vs manager time). However, if you want to be sure of getting that 0.1x productivity, you may choose to have meetings for 90% of the work schedule, and to force attention in the meetings. Do not tolerate developers coding during meetings, it is disrespectful to the talker. If all or some of the developers are working remotely, force the use of webcams, try to make it as if nobody is working remotely, for equality.
- Avoid documentation for developers. Reading the code can easily take 10x more time, especially when reading the code to try to infer aspects of the architecture or the infrastructure. Every aspect of the environment or context in which the code will run should be kept in secret. Some developers will try to cheat using Docker containers or similar techniques to have control over the execution context; forbid them, and make the context as specific and restrictive as possible.
- Require documentation for managers (point 5), as much as possible of it, require versions in as many formats as possible, e.g. PowerPoint, Word, Slack, some custom webform, a wiki,… The more that developers think of themselves as “makers not talkers” the more this is necessary. A good leader helps his followers to overcome their weaknesses, like the lack of communication skills. The consumption of this documentation is covered in point 11.
- If meetings (manager time) and the documentation for them is not enough overhead, interruptions should help to spread that management burden on productivity to the rest of the time. With the remote work as a consequence of the pandemic, casually interrupting someone at their desk is not as easy as before. However, there are still emails, instant messages, and the best: audio and video calls. In general, avoid asynchronous communication or grouping messages in batches, it is “too slow”.
- Do not plan ahead. Write the same code 10 times, then refactor. Even better: change the requirements whimsically 10 times at least, for 0.1x productivity. One hour of planning and thinking can save your team of 10 engineers 10 hours of work each. Avoid that planning at all costs. Make as many disposable prototypes as possible. Call it “agile”.
- Promote bad software practices. Create an OOP hell, in a dynamically typed language, without type annotations. Make pipelines of operations that return and receive nothing, everything being side effects. If someone shows a tendency towards obscure code that nobody else can read and convoluted architectures that nobody can understand, promote him to tech lead because “he must be a genius, way over his peers”.
- Move developers between projects and teams as much as possible. It takes some time to know the project, the goals, the codebase, etc. to be productive. Keep all developers in this state of reduced productivity as much as possible to try to reach the 0.1x desired productivity. When developers change projects, provide loads of manager documentation (point 7) to check out, which will be time consuming and provide zero value to developers. For most senior developers, enough manager documentation may brainwash them into managers, for a permanent 0x productivity multiplier, especially when pushing the most ambitious of them to unrealistic goals.
- Make sure that if something ever gets built, it is approximately 90% useless. In the end, the most important point is not what is built or how it is built, but why it was built in the first place. Even better: change goals fast enough so that by the time anything is finished it is completely useless, and therefore nothing is never deployed for production, achieving the “ideal” 0x results. Moving the goalposts is easier at a finer granularity when automated tests are not possible (point 2).
Any of these points would allow for the not-so-mythical 0.1x developers, but combining all of them would allow for 0.1¹²x developers, perhaps even 0x developers.
As you may have observed, many of the approaches are centered in avoiding automation, with the current trend towards automation, this is not always easy. In fact, some of them may not be applicable for much longer, you have to stay on your toes, for example:
- A proxy may slow down any use of the Internet, or completely prevent it, but this has only limited effect with remote work.
- Windows may not be the best operating system for developers, but with the new options in WSL, it may be fairly usable.
- Extreme temperatures, noise, or other conditions in the work environment may only be enforced with an office centric culture, which is now jeopardized by the digital transformation, which has been accelerated by the pandemic.
New methods may appear, replacing the methods lost. Managerial progress never stops. There are also additional methods not discussed in the previous examples, like increasing team sizes and dependencies, or how the foundation of a company may be a source of friction more than an asset to leverage. These topics would require an even longer discussion. Reach out to me if interested.
To conclude, if we can agree that 0.1x or 0.1¹²x developers are possible, we may agree that 10x developers are possible. Even 10¹²x developers may be possible, after adopting better practices and processes, if you 12 have problems like the ones described. If you feel that may be the case, please do not hesitate to reach out to me, I may be able to help further.
I hope this helps,
— trylks
