intltechventures.blogspot.com: 2019-07-20 Saturday - So, what is a 10x software engineer?

2019-07-20

2019-07-20 Saturday - So, what is a 10x software engineer?

There is an assumption embraced by many in the field of software engineering - that may take the form of one of two diametrically opposed positions:

10x software engineers exist.
10x software engineers are a myth.

I'm interested in the arguments put forth by both camps. However, in every field of endeavor, there are exceptional, world-class, elite performers. To deny that fact - would be foolish.

But first, let me explain something. The reason for writing this is actually two-fold:

1) I'm interested in understanding WHY people hold either of these opinions.

2) if you think this is an important question - if you believe that you should be seeking out 10x software engineers in your hiring process - permit me to to submit for your consideration - that you may be focusing on the wrong thing... (read this thread)

What you should be infinitely more concerned about - is rooting out the [-10x] software engineer from your organization.
Let me explain.

Drawn from over 30 years of observations while working in the industry - here are a few ideas of what might constitutes a [-10x] software engineer:

Some lack the minimum requisite skills, aptitude, and technical knowledge.
Some lack the interest/desire/motivation to make the necessary investment of time and effort to continue to maintain (and expand) their skills, knowledge, and professional development.
Some are unaware of the minimal basics of good software development practices.
Some are careless and inattentive.
Some create more technical debt - than value-add
Some focus on the easy ("window dressing") tasks first - delaying the hard work of eliminating technical risks/unknowns - putting the organization at significant risk of late discovery - and of incurring massive rework.
Some are too enamored with driving their solution design recommendations based on resume-driven technology decisions (aka "Shiny New Thing" addiction, or a variation of "Let's Gamble Whether The Business Survives with this Unproven Technology").
Some will willingly commit code to the source repository - that has not been tested. At all.
Some will argue that version control is an unnecessary burden.
Some will argue that writing documentation is an unnecessary burden.
Some will argue that they don't have time to write automated test cases.
Some lack an understanding of basic algorithms and data structures - and therefore are unqualified to make most nontrivial design decisions.
Some seem to take joy in creating an atmosphere of negativity and fomenting dissension.

Such individuals are capable of [-10x] damage to an organization - they should have their network access revoked, and should be escorted from the building.

A client once engaged me in an architecture mentoring role - to help assess a very large engineering team (> 100) - to help diagnose why they were creating more technical debt - and more defects - in every Agile Sprint - than Stories delivered (by a not insignificant multiple). My conclusion - after a significant amount of code inspections and code review discussions - was that quite a few of those software engineers were definitely in the [-10x] category.

As I explore my own thoughts on this topic - I will come back periodically and elaborate more in this posting, but I do have a few initial thoughts that may help illustrate where my views may diverge from what has previously been written by others.

If there are such things 10x software engineers - I think the distinction is really about the magnitude of the impact that a software engineer has beyond the scope of just their own work.

For your consideration - possible key indicators that someone might be a mythical 10x software engineer:

A 10x software engineer demonstrates an active awareness and appreciation for the efficiency and productivity of their team - and their organization.
A 10x software engineer isn't necessarily the engineer that codes 10x more, or 10x faster - but may be a more subtle and nuanced value proposition - in that the 10x person makes smarter choices - that result in code that is:

more extensible;
easier to maintain;
easier to understand;
is well tested;
demonstrates elegance;
shows keen insight in the naming of things; and,
exhibits higher scalability and performance tolerances.

A 10x software engineer focuses on eliminating technical risks/unknowns first - so that late discovery is mitigated - and reduces the potential need for massive rework.
A key indicator of a 10x software engineer is demonstrated by their relentless efforts to educate, elevate, and improve the abilities of other engineers in the organization.
A key indicator of a 10x software engineer is their intense focus on automating the mundane - so that processes are automated, less error-prone, of higher quality, repeatable, and frees not just them - but their team/organization - to focus on more value-added work.
A key indicator of a 10x software engineer is their ability to intuitively "see" (or, know) how a design will perform under various stress conditions - before writing a line of code.
A key indicator of a 10x software engineer is their judicious application of this rule: "The fastest code is the code that you don't need to write".
A key indicator of a 10x software engineer is in the ability to align their intuition, brilliance, creativity - with their efforts to create software - such that their design expands the capabilities of the organization in new dimensions - both in terms of business services offered, revenue generation, cost reduction, and enabling new business opportunities.
A 10x software engineer is humble and works to lift and elevate the capabilities (and attitudes) of their colleagues - and brings a tremendous positive energy to the work that they do - that permeates their environment.

I have more thoughts on this - but will do some deeper reading and reflection before returning to my key indicators list discussion above.

Fundamentally - I do believe - that there are individuals that exhibit better awareness, bring such a greater depth and breadth of experience, have a higher level of intuition, are more meticulous in their attention-to-detail, exhibit an extraordinary Duty-of-Care, deliver a higher quality in their work products, produce code with much better performance, who build software with better efficiency, and who make better design choices - and their contributions are so material and substantial - that they can have a positive 10x impact on an organization.

Thus, I agree that there are 10x software engineers - for I have seen firsthand the carnage and devastation that even a modicum of [-10x] software engineers can inflict on an organization - and I have been fortunate to have worked with several software engineers who were certainly worthy of the 10x designation - by virtue of the indicators noted above.

Perhaps 10x is a misnomer. Certainly no one performs at peak performance, all the time.

Perhaps a 10x is really more of a [1:10], or a [1:20], or a [1:100].

Background Reading:

Scholarly Research:

1984:

Effects of individual characteristics, organizational factors and task characteristics on computer programmer productivity and job satisfaction, Information & Management Volume 7, Issue 4, August 1984, Pages 209-214

"Several individual characteristics of computer programmers (self- esteem, level of experience, and mathematical aptitude); four organizational factors (perceived supervisory initiated structure, perceived supervisor consideration, perceived level of performance feedback, and perceived degree of participation in organizational decisions); and five task characteristics (skill variety, task variety, task significance, autonomy, and feedback) are related to computer programmer productivity and job satisfaction. Measurement was accomplished via questionnaires; least squares multiple regression was used to test the hypotheses."

2002:

An investigation into the effects of code coupling on team dynamics and productivity, Proceedings 26th Annual International Computer Software and Applications (August 2002)

"During the past three decades a number of theories have been proposed to explain the idiosyncrasies of software development as a team activity. The paper compares and combines these theories into a coherent model of software development that links software coupling and dependency management with team productivity. As a practical test of this model, the paper then investigates, the effects of coupling in two large commercial systems. It achieves this by using the VCML Views visualisation technique, developed by the authors, to expose the system wide coupling found in the code and how this coupling develops during the lifetime of a project. It then compares the resultant VCML views with simple attributes of the two projects to derive a set of important conclusions. In particular, it finds that unmanaged coupling within the code is a good indicator of potential productivity bottlenecks; that the number of programmers on a project is not necessarily a good indicator of programmer productivity; and that the architecture of a software system can radically alter the number of programmers that can effectively work together on a system."

2006:

Pair programming productivity: Novice–novice vs. expert–expert, International Journal of Human-Computer Studies Volume 64, Issue 9, September 2006, Pages 915-925

"Agile Software Development methodologies have grown in popularity both among academic researchers and industrial practitioners. Among the various methodologies or practices proposed, pair programming, which is concerned with two programmers collaborating on design, coding and testing, has become a controversial focus of interest. Even though some success stories have been reported with the use of pair-programming in real software development environment, many people remain rather skeptical of the claims on pair-programming productivity. Previous studies in pair programming have only addressed the basic understanding of the productivity of pairs and they have not addressed the variation in productivity between pairs of varying skills and experience, such as between novice–novice and expert–expert. Statistical productivity measurements reported by different researchers also seem to lead to contradictory conclusions. Until now, the literature has not addressed how those results and experiments were related to each other. In this paper, we propose a controlled experiment called repeat-programming which can facilitate the understanding of relationships between human experience and programming productivity. Repeat-programming can be performed when controversial issues in non-traditional programming methodologies and development productivity need to be investigated into. To illustrate how the proposed empirical experiment can put arguable, divisive problems into perspective, we have examined the productivity in pair programming as a case study. With repeat-programming, we are able to (i) better understand why results of previous pair programming control experiments reached different conclusions as to the productivity of pair programming and (ii) most importantly, present a case in which novice–novice pairs against novice solos are much more productive than expert–expert pairs against expert solos."

2007+:

Towards Applying Complexity Metrics to Measure Programmer Productivity in High Performance Computing, Catalina Danis, John Thomas, John Richards, Jonathan Brezin, Cal Swart, Christine Halverson, Rachel Bellamy, Peter MalkinIBM, TJ Watson Research Center

2012:

MEASURING PRODUCTIVITY OF SOFTWARE DEVELOPMENT TEAMS, Serbian Journal of Management 7 (1) (2012) 65 - 75

"This paper gives an exhaustive literature review of the techniques and models available to measure the productivity of software development teams. Definition of productivity, measuring individual programmer’s productivity, and measuring software development team productivity are discussed. Based on the literature review it was found that software productivity measurement can be done using SLOC (Source Lines of Code), function points, use case points, object points, and feature points. Secondary research findings indicate that the team size, response time, task complexity, team climate and team cohesion have an impact on software development team productivity. List of factors affecting the software development team productivity are studied and reviewed."

Measuring Productivity of Software Development Teams Serbian Journal of Management, Vol. 7, Issue. 1, pp. 65-75, 2012

2014:

Software developers' perceptions of productivity, FSE 2014 Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering Pages 19-29

"The better the software development community becomes at creating software, the more software the world seems to demand. Although there is a large body of research about measuring and investigating productivity from an organizational point of view, there is a paucity of research about how software developers, those at the front-line of software construction, think about, assess and try to improve their productivity. To investigate software developers' perceptions of software development productivity, we conducted two studies: a survey with 379 professional software developers to help elicit themes and an observational study with 11 professional software developers to investigate emergent themes in more detail. In both studies, we found that developers perceive their days as productive when they complete many or big tasks without significant interruptions or context switches. Yet, the observational data we collected shows our participants performed significant task and activity switching while still feeling productive. We analyze such apparent contradictions in our findings and use the analysis to propose ways to better support software developers in a retrospection and improvement of their productivity through the development of new tools and the sharing of best practices."

2016:

What Predicts Software Developers’ Productivity?

"Organizations have a variety of options to help their software developers become their most productive selves, frommodifying office layouts, to investing in better tools, to cleaning up the source code. But which options will have the biggest impact?Drawing from the literature in software engineering and industrial/organizational psychology to identify factors that correlate withproductivity, we designed a survey that asked 622 developers across 3 companies about these productivity factors and about self-ratedproductivity. Our results suggest that the factors that most strongly correlate with self-rated productivity were non-technical factors,such as job enthusiasm, peer support for new ideas, and receiving useful feedback about job performance. Compared to otherknowledge workers, our results also suggest that software developers’ self-rated productivity is more strongly related to task varietyand ability to work remotely."

2017:

Empirical evaluation of the effects of experience on code quality and programmer productivity: an exploratory study, Empirical Software Engineering October 2017, Volume 22, Issue 5, pp 2457–2542

"Years of experience are a poor predictor of programmer performance. Academic background and specialized knowledge of task-related aspects appear to be rather good predictors."

Pashkevich, Natallia and Haftor, Darek M., (2017). "SOFTWARE PROGRAMMER PRODUCTIVITY: A COMPLEMENTARY-BASED RESEARCH MODE". In Proceedings of the 25th European Conference on Information Systems (ECIS), Guimarães, Portugal, June 5-10, 2017 (pp. 2755-2766). ISBN 978-0-9915567-0-0 Research-in-Progress Papers.

"The identification of the factors that condition a software programmer’s productivity remains a key challenge for both scholars and practitioners. While a number of studies have focused on the impact of one or a few particular factors, the way these factors jointly condition programmer productivity is still unknown. This paper presents a conceptual model aimed at a comprehensive understanding of the factors that complement each other to govern the productivity of a software programmer. The model is based on complementarity theory and its systems approach and addresses an individual worker’s productivity, which accounts for cognitive, technological, and organizational characteristics. The analyzed factors are organized into a system of complementarities, offering two propositions that specify the conditions of a programmer’s productivity. The model’s key contribution lies in its unique configuration of two systems of complementarities, which have the potential to add to the literature on the productivity of software programmers. The proposed model can be employed as a guidance for the design of empirical investigations of the conditions of individual software programmers’ productivity as well as information worker productivity in general."

Chapter-4, Cooperative Software Development Andrew J. Ko with contributions from Benjamin Xie

"After teaching software engineering for many years, I've been frustrated by the lack of a simple, concise, and practical introduction to the human aspects of software engineering for students interested in becoming software engineers."
"In response, I've distilled my lectures from the past decade into these brief writings. They don't represent everything we know about software engineering (in particular, I don't discuss the deep technical contributions from the field), but the chapters do synthesize the broad evidence we have about how teams have to work together to succeed."

Human-Centered Methods to Boost Productivity, Rethinking Productivity in Software Engineering pp 147-157, Brad A. MyersAndrew J. KoThomas D. LaTozaYoungSeok Yoon, (2019)

Misc. Articles, Blog posts:

This thread is illustrative of someone who has incredibly wrong ideas about 10x - and whose reasoning borders on cargo cult science...what he describes is prima donna behavior, at best...