4 Seemingly Good Patterns That Fail to Retain High-Performance Programmers
A high-performance programmer is the one who gets things done quickly and accurately. We are decisive, analytical, and communicable. We can engineer solutions as code that is logical, understandable, and efficient. Managers and leaders want to keep these rare people. Some companies even go as far as creating a novel standard of culture to encourage excellence and retain those people.
“Our core philosophy is people over process. More specifically, we have great people working together as a dream team. With this approach, we are a more flexible, fun, stimulating, creative, collaborative and successful organization.” — Netflix
I am a programmer myself. I have been working in Japan, where the work culture is drastically different from the west. During these years, I have witnessed some high-performance programmers, both ex-pats and locals grudgingly resigned from the companies and the projects they liked. Surely the tech industry has a relatively high turnover rate, but I always wonder why the best people are leaving. Thanks to the cultural differences, I started to observe some patterns. These are seemingly good patterns that are amplified under the Japanese work culture, but not helpful in retaining high-performance programmers.
Systemization
Japan is one of the champions in defining and following protocols and systems. Very detailed by-the-book and step-by-step systems exist at the company and team levels, such as attendance tracking, performance review, progress report, and planning meeting. These systems are created for better efficiency and to allow everyone to pick up on the same routine easily.
The most comprehensive system sacrifices flexibility and the ability to be spontaneous, which means regardless of the scale of the context and necessity, the same procedures are carried out anyway. Although most programmers like well-defined systems, because it is also what programming is about — create problem-solving systems, these company or team systems at one point could consume too much of their energy and time. High-performance programmers actualize their value by getting into the zone with the program and through code we solve problems. Spending too much of their time coping with a list of administration steps is exhausting and puts us into a status of “I am not doing anything useful”. And that frustration could one day grow into an intention to leave.
Neutrality
A leader or a manager is sometimes neutral. One characteristic of Japanese work culture is conflict-avoiding, so being neutral is regarded as merit and associated with being “nice”. A leader could be neutral in a good way, for example, to encourage individuals to make decisions.
However, here is the catch — high-performance programmers stretch as far as we can, but we also know their limit. We always make decisions, but we know when and what decisions to reserve for their leader to make. Examples could be a decision between two almost identical approaches, or a decision that has a big impact on the schedule and other members of the team. In those cases, we are not expecting an answer like “it is okay either way” or “you can make the decision”. We expect an answer, or we want to initiate a discussion against a standpoint. Being nice cannot please high-performance programmers. Especially in a hierarchical structure, since the responsibility of making the final decision and bearing the consequence is on the shoulder of the leader, it aligns with the structure that not every decision should be made by the follower.
Repetition
Doing the same or similar thing repeatedly leads to perfection. Although software development is ever-evolving, there are still many cases it repeats itself, in a good way. Teams repeat what they have previously prototyped in the production period but are more sophisticated. A veteran programmer repeats what he had implemented in a previous company with better familiarity on the topic.
A big part of programming requires modularization and the ability to write a piece of code that can be reused to solve similar problems. “Write once, solve many” is one of the many design goals of a function (a unit of logic execution or data transformation) in a program. Similar to how any other professionals extend their specialty into work outside their major job duty, such as designers being more creativity-driven and programmers being more logic-driven at meetings, it is common to see programmers preferring “do once, solve many” in areas outside the code itself. Migrating a codebase, rebooting a project, or making the same explanation to different stakeholders multiple times. These are all for good sake but might annoy a programmer eventually when they repeat for enough time. High-performance programmers are especially sensitive to repetition.
Stability
Stability can be established at the company level or in the program itself. Creating a stable program involves many factors, but to put it short — do not replace something that works for years. That is why old tech plays a big part in stability, and also why banks, governments and medical sectors often use tech that is five years old if not more.
Unless a high-performance programmer voluntarily signs up for such an industry, we are always looking for improvement. The connection between high-performance and eagerness for constant improvement although is very natural to a programmer, it might be subtle to other professionals such as project manager. The biggest difference between computer science and other branches of engineering is that code can be refactored. It means even with a full-functioning product that is out on the market, we can still reconstruct the inside and make it faster, safer, or simply easier to read by other programmers, more “performant”. You cannot easily restructure a building or reformulate how the chemical in a power plant reacts after they are built, these creations are supposed to be stable. The ability to refactor comes with the mentality of possible never-ending improvement. Needless to say, programming itself is a relatively new skill and still has so much room for improvement. So stability is an opposing force for high-performance programmers to feel fulfilled.
This is of course not an exhaustive list. After all, it is always about the people. It is down to what individual thinks about themselves, the team, the company and what environment do we want to work at.
The key takeaway is to try to avoid the mentioned patterns. On top of that, think about the following questions. Your current company culture might not permit the possibility of the culture you are looking for, like what some of my ex-pat colleagues experienced in Japan. If you are a high-performance programmer, do you want to stay and adjust yourself to the company’s culture? Or leave and find a better place where you can be the most real and technical “you”. If you are a manager or a leader, do you want to fight for us to keep us staying, and how far can you go to make that happens by negotiating with your top management. Or just let us go because this is not the place for us.
A final question — should company culture adjusts and fits their high-performance programmers or vice versa?
I did not go into details on Japanese work culture in this article, but if you are interested you can check my other stories about Working in Japan:
