In the book “Mythical Man-Month,” Fred Brooks demonstrates that the most efficient developers, the so-called “10x developers,” code ten times more efficiently than their average counterparts. Surprisingly enough, the heirs of the Stakhanovite movement are software engineers working for big tech companies.
Alexey Stakhanov, the 14x miner. Source: The Pravda
As a junior software engineer, I wanted to take a closer look at the mythical 10x developers. That is why I shadowed two senior developers at my company, Dataiku, for four days. I will explain later how I chose them. Do they actually deliver ten times more? If so, how do they achieve it? What can we learn from them? In this blog, I will share my findings and astonishments with my fellow software engineers.
All Roads Lead to Code: Talented Coders Come From Diverse Backgrounds
Brooks debatably stated that experience does not always increase the performance of a programmer. For Kyle Coberly, however, Brooks overlooked key performance factors, such as maintainability, communication, and adaptability. When I shadowed the two software engineers, I tried to find out which experiences benefited their careers most.
I observed Jiffy and Fred, who have been working as developers for seventeen and seven years, respectively. While Fred learned to program as a kid, Jiffy discovered coding during his studies. So, you do not need to learn C++ from the cradle to become a successful coder. Sharing this idea helps attract people from non-traditional backgrounds to software development. Both pursued technical studies, even though it is not a prerequisite to join Dataiku. Fred specialized in IT, telecom, and machine learning while Jiffy studied computer science.
More importantly, though, they both embrace the full spectrum of programming. By mastering not only front-end development, but also DevOps or machine learning, they can now quickly adapt to new projects. Experiencing different fields, companies, and projects contributed to their versatility.
Jiffy worked in the gaming, energy, and events industries. Meanwhile, he held various positions such as project manager, auditor, and DevOps. He is the embodiment of the shapeshifter developer described in the blog Neils On Software. Hence, he managed several projects in a non-technical position during his years in China. I believe this is how he learned to deal with change management and lead transformational projects.
At Dataiku, he successfully took over a high-stakes and thorny project: transitioning to a new tool chain. In The Silent Transformations, François Jullien argues that the Chinese approach to changes tends to “yield to situations rather than confront them head-on.” This is precisely what Jiffy did with the deployment of the new build chain. He spread the technical development over six months and continuously met with relevant stakeholders. Like Lao Tzu describes, he “remain[ed] unmoving until the right action ar[o]se by itself.”
Lao Tzu: Remain unmoving until the right action arises by itself
In contrast to Jiffy’s job switching, Fred preferred to capitalize on his years at Dataiku, where he has spent half of his career. Hence, he understands Dataiku’s code base extensively. He also learned a lot by working at a startup specialized in security. Not only could he spend more time on refactoring and making the code close to perfect, but he also became an expert at cybersecurity. Today, he trains and advises people on cybersecurity topics.
If you were wondering about how often you should switch jobs as a software engineer, this shadowing experiment brings no clear answer. However, if you are eager to know what senior engineers do everyday, the next section is all you need.
The 42 Habits of Highly Effective Engineers
Many blog posts list general advice on how to become a great software engineer, such as writing clean code or finding a mentor. More importantly, though, I believe that programmers strengthen their skills thanks to the tiny iterations they make everyday. During the shadowing, I tried to find out which programming habits were the most beneficial.
Jiffy and Fred advocate for quality code. It basically means preventing the code from becoming a labyrinth. When they implement new features, do peer reviews, or fix bugs, they always take a step back to think of the global structure of the code. For instance, during peer review, Fred used a lot of critical thinking, notably by applying the Occam’s razor principle. Like for scientific explanations, code quality increases when ‘entities [are] not multiplied without necessity.” Therefore, Fred quickly noticed any duplicated code and questioned the creation of new methods if he thought that they probably already existed.
By taking a step back, he could also foresee several edge cases and security issues. For instance, while reviewing a new Dataiku feature, he thought about the Kubernetes container management and spotted a breach for directory traversal attacks. I noticed that Jiffy took the time to refactor the code before working on his new feature. He split the existing front-end code into separated components. This commitment to the separation of concerns principle shows that Jiffy is a “healer” developer. As Neil on Software puts it, Jiffy “bravely refactor[ed] the parts of the code that [we]re considered plagued by others.” Both felt responsible to maintain and improve the code base quality. This may explain why they were involved in a lot of decision making processes.
Project Ownership and Knowledge Sharing
Fred and Jiffy “owned” their topics. Their management expected them to make technical choices and explain them. Jiffy brought many insights to help choose between reusing existing components or creating new ones for a new set of features. He brought valuable arguments to show that even if existing components already managed several technical constraints, reusing them was like fitting a circle into a square. Fred epitomized the Sage developer, as he could find technical solutions that were both suitable for short- and long-term needs. By coaching his colleagues, he even fostered collective ownership. This notion implies that everyone should be responsible for the quality of the software rather than focusing on their features only. For instance, when Jiffy discovered several new bugs while fixing a bug, he decided to fix them all at once. Then, he randomly assigned the review to a teammate. I think such a practice fuels knowledge sharing across the team.
Knowledge sharing resulted from the constant tech watch of the two programmers. They chatted together about their latest discoveries or their previous experiences with some cool technologies. For example, they discussed the benefits and drawbacks of GraphQL. Fred is definitely a ranger developer, who keeps up with the latest technologies while assessing their pros and cons. For instance, he considered various front-end frameworks and thought about integrating them into the software. Yet, he kept in mind that integrating all of the most recent front-end frameworks could hinder the onboarding of new developers. Jiffy and Fred kept in touch with the latest technologies to boost their team’s productivity. For example, Fred made the code of the statistical side of Dataiku as modular as possible. During our internal hackathon, the modularity of the code dramatically sped up the development of the new statistical features. Jiffy and Fred kept a critical mindset or a “hype filter” when assessing new technologies. They would only include them into the software if they significantly improved the code base and fitted a concrete need.
More generally, both engineers constantly questioned technical choices and implementations. For example, Jiffy spent time investigating a data structure and relied on diverse opinions before choosing the relevant implementation. As Adam Gordon Bell brilliantly narrates in his blog post “Don’t Feed the Thought Leaders,” software development is full of confident experts who think that they found the universal solution to all the problems. Yet, the most reliable experts give specific and contingent advice that best fit the problem at stake. Fred often questioned the specifications of his features. He preferred to start with a real-life problem rather than a solution. He also brought up several product insights during meetings. In terms of tooling, Jiffy and Fred rely on classical tools, nothing more fancy than IDE or Github. Yet, they use them in a creative and unexpected way.
Creativity at work often results from people twisting existing tools. I noted that Fred and Jiffy used their IDEs in the most interesting fashion, resulting in various “catachresis.” According to the article “Catachresis - problem and framework for work psychology,” operators perform a catachresis when they “make an unexpected use of certain tools [..] without being expressly compelled to.”
A famous catachresis: Use a spoon to open a jar. Source: wikiHow
For example, Jiffy and Fred usually used the “Annotate” function of IntelliJ, which shows the results of the “git blame” command on the right side, to better understand the code. Jiffy made the most of the version control features of IntelliJ. To find the difference between two similar code snippets, he would replace one of them with the other and view the difference in his IDE. Then, he benefited from the powerful “diff” features of Git to compare them. To be more efficient, senior software engineers tend to use common tools in a creative way.
What time management techniques did they use to boost their efficiency? Jiffy and Fred had different time management styles. Jiffy tended to get to grips with a task right away. I believe that this habit made him extra productive. He also had a lot of control over his agenda. While coding, Jiffy often checked his code and did not run into many errors. Fred could sometimes delay some tasks to have enough time to focus and reduce context switching. He was incredibly fast when writing code, at the cost of a couple of typos. Fred thought about his implementations in advance so he knew in detail how his code would be, even before switching his computer on. It reminded me of the photographer Robert Mapplethorpe. According to Patti Smith, Mapplethorpe already had the vision of his final pictures, even before switching his camera on.
Do Development Tools Have a Dramatic Impact on the Way the Engineers Manage Information?
During the shadowing experiments, I realized that the code was the most substantial medium for Fred and Jiffy, before documentation or processes. As a reviewer, Fred would first look at the code of the pull request before reading the written description. As a matter of fact, the code is often the most recent source of knowledge. Yet, it involves a lot of written communication. Fred and Jiffy both wrote notes during meetings and had quite good writing skills.
Fred and Jiffy often communicated in an informal way, both orally and through Slack messages. For instance, Jiffy asked Fred if he agreed on the way he fixed a bug. As most decisions are made orally during meetings, it is important to speak up.
Engineers often communicate in an open, honest and direct manner and that was no different here. Jiffy and Fred were open to criticisms. An ordinary code review already promotes this type of direct feedback. Jiffy even received some direct criticisms about his toolchain project and remained unwavering. As a software engineer, you sometimes need to keep your ego aside and think about your contribution to the collective project first.
Experimental Protocol and Limitations
To conduct this shadowing experiment, I used a couple of shadowing techniques. I observed the screens of the developers for four days. I logged every activity and interaction. To choose the developers, I asked my colleagues for advice, keeping in mind it would be easier to shadow people who often went to the office. So, of course, the choice is biased by what my colleagues considered to be a “good” software engineer.
Being a talented developer stems not only from your achievements, but also from peer recognition. In engineering departments, the working culture seems upside down. Engineers value technical expertise most and do not judge their colleagues based on their looks. The best fashion statement is wearing a t-shirt won thanks to a bug bounty program. So even your clothes may reveal your technical skills. The Hawthorne effect is another limiting factor, as being observed changes how you behave and work. Surprisingly enough, none of the developers opened a YouTube page in front of me.
Final Takeaways
When all is said and done, assessing the productivity of a developer is no easy task. Yet, this shadowing experiment taught me that I should:
- Diversify my experiences to grow my coding skills
- Promote knowledge sharing within my team
- Master my topics to make the relevant technical choices
- Be open to criticisms
However, every programmer has a unique way to contribute to a project. We can learn from experienced programmers, but we should not copy them. Rather than complying with a given model, we should create our own. What kind of developer are you, dear reader? Take the test on Neil Postman's website.