1<!doctype html> 2<!-- 3 Minimal Mistakes Jekyll Theme 4.24.0 by Michael Rose 4 Copyright 2013-2020 Michael Rose - mademistakes.com | @mmistakes 5 Free for personal and commercial use under the MIT license 6 https://github.com/mmistakes/minimal-mistakes/blob/master/LICENSE 7--> 8<html lang="en" class="no-js"> 9 <head> 10 <meta charset="utf-8"> 11 12<!-- Google Tag Manager -->
13<script>
vendor: 351 bytes, lines 13-19
13 14 (function(w,d,s,l,i) { 15 w[l]=w[l]||[];w[l].push({'gtm.start': 16 new Date().getTime(),event:'gtm.js'}); 17 var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:''; 18 j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f); 19 })(window,document,'script','dataLayer','
19GTM-T5DHGBR
vendor: 4 bytes, line 19
19');
20</script>
20 21<!-- End Google Tag Manager --> 22 23<!-- begin _includes/seo.html --> 24 25 26<title>The 95% | :julianbrowne</title> 27<meta name="description" content="Itâs easy to get carried away with the notion of productivity. Itâs important but itâs also important not to single out highly productive people and compare them to others. Itâs the varied differences in teams which are both unavoidable and can be harnessed to do better work. Not talking about 10x developers is good for team diversity and avoiding tech-bro monocultures."> 28 29 30 31<meta property="og:type" content="article"> 32<meta property="og:locale" content="en_US"> 33<meta property="og:site_name" content=":julianbrowne"> 34<meta property="og:title" content="The 95%"> 35<meta property="og:url" content="https://www.julianbrowne.com/article/the-95/"> 36 37 38 <meta property="og:description" content="Itâs easy to get carried away with the notion of productivity. Itâs important but itâs also important not to single out highly productive people and compare them to others. Itâs the varied differences in teams which are both unavoidable and can be harnessed to do better work. Not talking about 10x developers is good for team diversity and avoiding tech-bro monocultures."> 39 40 41 42 43 44 45 46 <meta property="article:published_time" content="2023-03-27T00:00:00+01:00"> 47 48 49 50 51 52 53<link rel="canonical" href="https://www.julianbrowne.com/article/the-95/"> 54 55 56 57
58<script type="application/ld+json"> 59 { 60 "@context": "https://schema.org", 61 "@type": "Person", 62 "name": "Julian Browne", 63 "url": "https://www.julianbrowne.com" 64 } 65</script>
65 66 67 68 <meta name="google-site-verification" content="R0HAYKG3Af7M_Sje__lV02Y0-LV7y4dElj3-QSkBVI8" /> 69 70 71 72 73 74 75<!-- end _includes/seo.html --> 76 77 78 <link href="https://feeds.feedburner.com/julianbrownerecent" type="application/atom+xml" rel="alternate" title=":julianbrowne Feed"> 79 80 81<!-- https://t.co/dKP3o1e --> 82<meta name="viewport" content="width=device-width, initial-scale=1.0"> 83 84<!-- For all browsers --> 85<link rel="stylesheet" href="/assets/css/main.css"> 86 87<link rel="preload" href="https://cdn.jsdelivr.net/npm/@fortawesome/fontawesome-free@5/css/all.min.css" as="style" onload="this.onload=null;this.rel='stylesheet'"> 88 89<!-- Google Analytics -->
vendor: 65 bytes, lines 89-91
89 90 91<script async src="https://www.googletagmanager.com/gtag/js?id=
91G-LHE91R78S2
vendor: 12 bytes, line 91
91"></script>
92<script nonce="72gaJDKTR5AssSggvvUTQ"> 93 94 document.documentElement.className = document.documentElement.className.replace(/\bno-js\b/g, '') + ' js '; 95 96
vendor: 133 bytes, lines 96-99
96window.dataLayer = window.dataLayer || []; 97 function gtag(){dataLayer.push(arguments);} 98 gtag('js', new Date()); 99 gtag('config', '
99G-LHE91R78S2
vendor: 4 bytes, line 99
99');
100</script>
100 101 102<noscript> 103 <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@fortawesome/fontawesome-free@5/css/all.min.css"> 104</noscript> 105 106 107 108
108<script src="https://code.jquery.com/jquery-3.6.2.min.js"></script>
108 109 110 111 112 <!-- start custom head snippets --> 113 114<!-- insert favicons. use https://realfavicongenerator.net/ --> 115 116<!-- end custom head snippets --> 117 118 </head> 119 120 <body class="layout--article"> 121 122 <!-- Google Tag Manager (noscript) -->
vendor: 83 bytes, lines 122-124
122 123 <noscript> 124 <iframe src="https://www.googletagmanager.com/ns.html?id=
124GTM-T5DHGBR
vendor: 94 bytes, lines 124-126
124" height="0" width="0" style="display:none;visibility:hidden"></iframe> 125 </noscript> 126
126<!-- End Google Tag Manager (noscript) --> 127 128 <nav class="skip-links"> 129 <ul> 130 <li><a href="#site-nav" class="screen-reader-shortcut">Skip to primary navigation</a></li> 131 <li><a href="#main" class="screen-reader-shortcut">Skip to content</a></li> 132 <li><a href="#footer" class="screen-reader-shortcut">Skip to footer</a></li> 133 </ul> 134</nav> 135 136 137 138<div class="masthead"> 139 <div class="masthead__inner-wrap"> 140 <div class="masthead__menu"> 141 <nav id="site-nav" class="greedy-nav"> 142 143 <a class="site-title" href="/"> 144 :julianbrowne 145 146 </a> 147 <ul class="visible-links"><li class="masthead__menu-item"> 148 <a href="/about/">about</a> 149 </li><li class="masthead__menu-item"> 150 <a href="/archive/">archive</a> 151 </li><li class="masthead__menu-item"> 152 <a href="/contact/">contact</a> 153 </li></ul> 154 155 <button class="search__toggle" type="button"> 156 <span class="visually-hidden">Toggle search</span> 157 <i class="fas fa-search"></i> 158 </button> 159 160 <button class="greedy-nav__toggle hidden" type="button"> 161 <span class="visually-hidden">Toggle menu</span> 162 <div class="navicon"></div> 163 </button> 164 <ul class="hidden-links hidden"></ul> 165 </nav> 166 </div> 167 </div> 168</div> 169 170 171 <div class="initial-content"> 172 173 174 175 176 177 178<div id="main" role="main"> 179 180 <div class="sidebar sticky"> 181 182 183 184<div itemscope itemtype="https://schema.org/Person"> 185 186 187 188 <div class="author__content"> 189 190 <h3 class="author__name" itemprop="name"></h3> 191 192 193 </div> 194 195 <div class="author__urls-wrapper"> 196 <button class="btn btn--inverse">Follow</button> 197 <ul class="author__urls social-icons"> 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 <!-- 251 <li> 252 <a href="http://link-to-whatever-social-network.com/user/" itemprop="sameAs" rel="nofollow noopener noreferrer"> 253 <i class="fas fa-fw" aria-hidden="true"></i> Custom Social Profile Link 254 </a> 255 </li> 256--> 257 </ul> 258 </div> 259</div> 260 261 262 </div> 263 264 265 266 <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork"> 267 268 <meta itemprop="headline" content="The 95%"> 269 270 271 <meta itemprop="description" content="Itâs easy to get carried away with the notion of productivity. Itâs important but itâs also important not to single out highly productive people and compare them to others. Itâs the varied differences in teams which are both unavoidable and can be harnessed to do better work. Not talking about 10x developers is good for team diversity and avoiding tech-bro monocultures."> 272 273 274 <meta itemprop="datePublished" content="2023-03-27T00:00:00+01:00"> 275 276 277 278 <div class="page__inner-wrap"> 279 280 <header> 281 282 <h1 id="page-title" class="page__title p-name" itemprop="headline"> 283 The 95% 284 285 </h1> 286 287 288 <h2 id="page-subtitle" class="page__subtitle p-name"> 289 Hell, Iâll either surf or ski 290 291 </h2> 292 293 294 295 <p class="page__meta"> 296 297 298 <span class="page__meta-date"> 299 <i class="far fa-calendar-alt" aria-hidden="true"></i> 300 301 <time datetime="2023-03-27T00:00:00+01:00">March 27, 2023</time> 302 </span> 303 304 305 <span class="page__meta-sep"></span> 306 307 308 309 310 311 <span class="page__meta-readtime"> 312 <i class="far fa-clock" aria-hidden="true"></i> 313 314 13 minute read 315 316 </span> 317 318 </p> 319 320 321 322 323 324 325 326 327 <p class="page__taxonomy"> 328 <strong> 329 <i class="fas fa-fw fa-tags" aria-hidden="true"></i> 330 Tags: 331 </strong> 332 <span itemprop="keywords"> 333 334 <a href="/tag/business/" class="page__taxonomy-item p-category" rel="tag"> 335 business 336 </a> 337 338 <span class="sep">, </span> 339 340 341 <a href="/tag/culture/" class="page__taxonomy-item p-category" rel="tag"> 342 culture 343 </a> 344
345 <span class="sep">, </span> 346 347 348 <a href="/tag/development/" class="page__taxonomy-item p-category" rel="tag"> 349 development 350 </a> 351 352 353 </span> 354 </p> 355 356 357 358 359 360 </header> 361 362 363 <section class="page__content e-content" itemprop="text"> 364 365 <figure class="align-right"> 366<img src="./assets/images/surfers.webp" alt="Surfers 1969 by Byron Randall" /> 367 <figcaption> 368 weâre all equal before a wave 369 370 </figcaption> 371 </figure> 372 373<p>In November 2007, <a href="https://en.wikipedia.org/wiki/Bruce_Eckel">Bruce Eckel</a> gave a commencement address at <a href="https://www.neumont.edu/">Neumont College of Computer Science</a> in Salt Lake City. He published it shortly after and titled it â<a href="https://www.artima.com/weblogs/viewpost.jsp?thread=221622">The Mythical 5%</a>.â Itâs a good speech about what it takes to be a member of the top 5% of software engineers in the world who are 20x more productive than the other 95%.</p> 374 375<p>That is a pretty astonishing statistic. If itâs true then companies in the UK who happily pay a mid-level average developer 60k UKP (80k USD) a year for average productivity should logically be paying their top engineers over a million flipping quid a year. I guess itâs lucky for financial controllers that software engineers arenât employed on piecework contracts.</p> 376 377<p>I read The Mythical 5% and enjoyed it. I donât disagree with anything he says. Some engineers are indeed enormously more productive than others. But it also made me feel uneasy, because it provides some good suggestions within a narrative that can be culturally quite dangerous.</p> 378 379<p>So today I wanted to pick the article apart a bit and explore a counterpoint view that says the same thing but in a more practical format.</p> 380 381<h2 id="true-and-dangerous">True and Dangerous</h2> 382 383<p>If you gathered 100 random people together and made them run a race, the gap between the fastest and slowest would be huge. Because we are all different. If you took 100 random <em>runners</em> and made them run a race the gap would still be huge. Because we are all different even when we share an objective. Weâre different because we donât all share the same goals, motivations, genetics, upbringing, social networks, opportunities, societal regard. So the fact that software engineers have vast differences in productivity is no surprise.</p> 384 385<p>Eckel suggested the 5% comes about because of the <a href="https://en.wikipedia.org/wiki/Pareto_principle">80/20 rule</a>. That is to say, 80% of the team <em>just come to work every day</em> (he uses the phrase âdonât do anything but what they covered in collegeâ which makes sense given the commencement context, though Iâve worked with some great engineers who didnât have college degrees) whereas 20% of the team actively seek to improve their craft (read books, watch conference talks, learn skills beyond those required for their day job).</p> 386 387<p>Iâll call the 80% the <strong>Surfers</strong> (ride the waves, go with the flow) and the <strong>Strugglers</strong> (a term taken from Eckelâs talk) the 20% of people who âstruggleâ every day to master their field.</p> 388 389<p>Within that 20% of Strugglers, thereâs another 80/20 split. 80% of them are highly competent but are still at various stages on the learning curve, whereas 20% of the 20% (the 5%) have amassed enough experience and know-how to exhibit this <strong>Superstar</strong> super-productivity.</p> 390 391<p>If you gathered 100 random developers together, statistically youâd have 80 Surfers, 15 Strugglers and 5 Superstars. I have no data to say how accurate that is, but if I think about teams I have managed, and interviews I have conducted, that feels about right. And all I mean by that is Iâd expect to interview roughly 5 people before finding a Struggler or a Superstar. Iâm not making a value judgement about Surfers, other than to note that when we talk about teams in the abstract we often fall into the habit of assuming what we are aiming for is a team full of Strugglers and Superstars. Iâll talk about why thatâs unhelpful later.</p> 392 393<p>The next question is just how much more productive Superstars are compared to Surfers?</p> 394 395<p>Itâs a bit of a minefield.</p> 396 397<p>The 20x figure comes from a 1968 paper called âExploratory Experimental Studies Comparing O
397nline and Offline Programming Performanceâ <sup id="fnref:1" role="doc-noteref"><a href="#fn:1" class="footnote" rel="footnote">1</a></sup> which is strange because the paper actually records differences of up to 28x, a figure used by <a href="https://en.wikipedia.org/wiki/Robert_L._Glass">Robert Glass</a> in his 2003 book <a href="https://www.google.co.uk/books/edition/Facts_and_Fallacies_of_Software_Engineer/saRQAAAAMAAJ?hl=en">Facts and Fallacies of Software Engineering</a> and discussed in his paper âThe Importance of the Individualâ<sup id="fnref:2" role="doc-noteref"><a href="#fn:2" class="footnote" rel="footnote">2</a></sup>.</p> 398 399<p>However, on closer scrutiny, neither the 28x nor the 20x figures hold up because the comparisons werenât <a href="https://www.codingblocks.net/practice/four-reasons-why-10x-developer-controversial/">exactly rigorous</a>. More commonly quoted though is the infamous 10x figure, which was popularised by <a href="https://en.wikipedia.org/wiki/Steve_McConnell">Steve McConnell</a> in his book <a href="https://en.wikipedia.org/wiki/Code_Complete">Code Complete</a> and <a href="https://www.construx.com/blog/the-origins-of-10x-how-valid-is-the-underlying-research/">defended</a> <a href="https://www.construx.com/blog/productivity-variations-among-software-developers-and-teams-the-origin-of-10x/">numerous</a> times since. And studies like Tom DeMarco and Tim Listerâs <a href="https://gwern.net/doc/cs/algorithm/2001-demarco-peopleware-whymeasureperformance.pdf">Coding War Games</a> show some developers are 11x more productive than others.</p> 400 401<p>My take on all this is simple. As Captain Blackadder might have said there is <em>a tiny flaw</em> in all this research. Itâs <a href="https://www.imdb.com/title/tt0526712/characters/nm0000100#:~:text=There was one tiny flaw,Captain Blackadder : It was bollocks">bollocks</a>.</p> 402 403<p>With the rise of automation and AI, Iâm not sure weâll ever be able to measure relative productivity reliably or use the results if we could. Because even if I were able to pull off a totally unbiased, fair, double-blind, experimental result it wouldnât be repeatable. Another experiment with different people would give a different result. And what are we measuring anyway? Lines of code? Completed story points? Features? Amount of rework? Passing tests? Maintainable code?</p> 404 405<p>In 2009 a study<sup id="fnref:3" role="doc-noteref"><a href="#fn:3" class="footnote" rel="footnote">3</a></sup> looked at the effect of personality type on the effectiveness of pair programming. The conclusion was that mixing personality types improved productivity. A year later another study<sup id="fnref:4" role="doc-noteref"><a href="#fn:4" class="footnote" rel="footnote">4</a></sup> said personality only had âmodest predictive valueâ for productivity and aspects such as expertise and task complexity were more significant.</p> 406 407<p>Itâs like creating an experiment to show how much faster Usain Bolt is than me over 100m. Well, he is faster. But does knowing heâs 1.5x or 2x or 3x faster help? Not really. Itâs useful to know about his training and techniques if (and only if) I want to run faster than I do today. But what if I run for fun? What if I care more about equestrianism?</p> 408 409<p>Ah but this isnât about running. Itâs about software development. And companies want software development done faster. Try telling your engineering manager youâre a bit behind with the current feature you are working on because you care more about dressage.</p> 410 411<p>Relative productivity measures donât help us much in software development for some very good reasons.</p> 412 413<h2 id="we-dont-work-solo">We donât work solo</h2> 414 415<p>Software development is a team sport. As I am very fond of saying, the whole team succeeds together and fails together. Itâs great if some individuals race through tasks faster than others. And, just as with Usain Bolt, if they can share a few tips with other team members then thatâs awesome. When Eckel talked about struggle he meant learning. Everyone is learning all the time. So the key to making a <em>team</em> go faster, rather than thinking about individuals, is to foster open natural learning as part of the development process.</p> 416 417<h2 id="we-dont-learn-under-pressure">We donât learn under pressure</h2> 418 419<p>Metrics can be useful but not if they only tell us about individual productivity. Thatâs like telling me Usain Bolt ran 100m in 9.58 seconds when I am taking 20 seconds. And? I canât do anything with that data. In software, if we start to measure the wrong thing it leads to a bunch of <a href="https://en.wikipedia.org/wiki/Brogrammer">brogrammers</a> flexing about how many lines of code they wrote today. Itâs not helping the team learn.</p> 420 421<h2 id="we-cant-ignore-95-of-our-team">We canât ignore 95% of our team</h2> 422 423<p>If we put the 5% on a pedestal we risk alienating the other 95%. Especially the 80% of Surfers. I said Iâd come back to this and here we are. When we say Surfer we mean someone who comes in every day and does their best. They w
423ork the hours, do the meetings, follow the process, make friends and go home at a reasonable time. Theyâre not under-performers. Thatâs a very different thing.</p> 424 425<p>These are people who are happy in their job but theyâre just, for whatever reason, not motivated to do more than that. Critical point though - they may not be motivated towards becoming a Struggler, but that doesnât mean they donât want to learn, be better, or get promoted. And this presents an enormous opportunity. Because if you can lift 80% of the team by only a small amount it far outweighs the impact of focusing on the 5%.</p> 426 427<h2 id="its-culture-not-people">Itâs Culture, not People</h2> 428 429<p>The same Coding War Games study by DeMarco and Lister found something amazing, but not surprising, about <a href="https://fs.blog/open-plan-offices-suck-privacy-makes-us-productive/">how we work</a>, rather than who is more productive:</p> 430 431<blockquote> 432 <p>People from the same companies performed at roughly the same level â but that there 433was an enormous performance gap between organizations.</p> 434 435 <p>What distinguished programmers at the top-performing companies wasnât greater 436experience or better pay. It was how much privacy, personal workspace and freedom 437from interruption they enjoyed.</p> 438</blockquote> 439 440<p>When I said companies want software development done faster, this is what they mean. They have no preset measure of how fast, as long as itâs faster than the competition.</p> 441 442<h2 id="the-team-is-the-team">The Team is the Team</h2> 443 444<p>And the final nail in all this is that the team is the team. Iâve inherited teams and Iâve built teams from scratch. When you inherit a team you have to work with it as it is (other than deal with actual under-performance). I mean you could fire 80% of the team on day one, but good luck with gaining the trust of the survivors. If one of your Superstars has a bad week do you fire them too? Iâm most definitely not saying accept everything about a team. Iâm saying lift everyone by working on the <a href="/article/tech-culture/">culture</a> rather than focusing on the 80% or the 5%.</p> 445 446<p>And itâs no better when you start with a blank slate either. When you build a team you can probably over-index on Superstars and Strugglers for a while but in the end, life finds a way. This has perhaps been one of the hardest realisations of my career. And an empowering one too. For years I thought if I only hired and worked with the super-elite then things would be awesome. And, in pockets, thatâs true for small teams that are fairly short-lived. And in other organisations, I would witness teams with a fairly normal distribution of productivity doing amazing things once I stopped being quite so snooty.</p> 447 448<h2 id="elitism-kills-productivity">Elitism Kills Productivity</h2> 449 450<p>And talking of snooty, thereâs an antipattern I see a lot that drags potentially great teams into the watery depths of stagnation. Take a happy diverse team thatâs been through a rough patch (say something like a dramatic period of growth in a start-up, or an especially tricky project). Many of those people might experience a productivity drop. Managementâs response to this might be to hire more managers to <em>improve the process</em> or <em>implement more productivity measures</em>. Because obviously the one thing a team thatâs low in morale needs is more process and metrics.</p> 451 452<p>People arrive without context and start to disparage sections of the team. Secret Slack groups pop up, with memberships often along perceived productivity lines, exacerbating divisions. This is a tacit focus on the 5% and the only sure outcome is reduced overall productivity.</p> 453 454<h2 id="embracing-multiplicity">Embracing Multiplicity</h2> 455 456<p>Hereâs how it can work. Firstly, make no attempt to quantify differences in productivity. Itâs a pointless exercise. Some people will go fast, others will go slower. And who those people are, and what percentage of the team they make up, will change by day, by task, by mood. And thatâs normal.</p> 457 458<p>Overall you want to always be improving. Strugglers love to improve, but so do Surfers. One is just more motivated to seek improvement beyond the confines of the day job. Superstars can be useful sources of improvement know-how, but they are not the only sources. Itâs important that anyone making good headway shares the how and why with everyone. This is what weekly team demos are useful for. Itâs important for the team to feel that good things are happening regardless of who does the show-and-tell.</p> 459 460<p>Strugglers and Superstars are not an elite. Their self-motivated learning is usually their own reward. The focus can safely be on making sure the 80% always feel connected to the work that is happening. For what to think about beyond this kind of sharing we can go back to Bruce Eckelâs article.</p> 461 462<h2 id="rising-tides">Rising Tides</h2> 463 464<p>Thereâs <a href="https://en.wikipedia.org/wiki/A_rising_tide_lifts_all_boats">a phrase</a> used by economists and politicians - âa rising tide lifts all boatsâ - usually to justify a new crazy free-market policy that benef
464its only the rich. But itâs a useful concept for team productivity. If you can create an environment that promotes open sharing and a collective mindset that problem-solving isnât linear but requires diverse minds to look at things in different ways then you lift all the boats.</p> 465 466<p>Eckel said one aim is âgetting leverage on everything you doâ that is using tools, data and collaboration technology to take problems and crowbar them apart. When problems are hard remember that âleverage .. doesnât always come from the obvious thing, or from what weâve been toldâ itâs often found by looking at everything from another angle. There are no bad questions. As you discuss and debate and cross-reference with hard data you will âdiscover the hinge points of a problemâ and then by keeping a âclear mind and detached perspectiveâ the solution will eventually show itself. These sessions should involve everyone. Use the fact that Surfers arenât drawn to over-complex solutions that they know will lead to late nights. Let them question everything.</p> 467 468<p>Superstars can lean towards sophisticated approaches because they understand them. Thatâs great but everyone has to maintain what goes into production later. Remember that âunreadable code has a real cost, and we call it âtechnical debtââ</p> 469 470<p>Also, beware architects touting models or frameworks upon which to base solutions. Foundations can be useful but we in tech are âlegendary for flailing about with fads that promise to get things done betterâ and productivity is the result of three interacting entities: the real world of business and people using the software, the code that attempts to pin soft concepts down in the binary world of software and the model used to connect the two. Eckel quotes a workshop attendee:</p> 471 472<blockquote> 473 <p>All models are wrong. Some are useful</p> 474</blockquote> 475 476<p>He finishes the talk by looking at the softer side of tech. One mantra I have lived by for years is âno matter what they tell you, itâs always a people problemâ - even when I am engaged to fix delivery processes or migrations or re-architecture exercises I always know it will be the people. People problems require listening and patience and time, not relative productivity metrics.</p> 477 478<p>And when the team has cracked the problem and found an appropriate solution (one that is no more complex than the problem itself) and the knowledge has been shared widely you then have to build it. And whatever you estimate that time to be âthereâs a 0% probability that you will actually get it done in that period of timeâ because daily changes in task challenges, mood, productivity, and dependencies will all conspire to make progress faster or slower.</p> 479 480<p>Some days you will feel more lost than others but if you do these things you can massively improve productivity over time. But donât give up.</p> 481 482<blockquote> 483 <p>Youâll need to make a lot of mistakes in order to figure things out. 484So be humble, and keep asking questions.</p> 485</blockquote> 486 487<p><strong>Notes</strong></p> 488 489<ul> 490 <li> 491 <p>The painting is <a href="https://commons.wikimedia.org/wiki/File:Surfers_1969.JPG">Surfers 1969</a> by <a href="https://en.wikipedia.org/wiki/Byron_Randall">Byron Randall</a></p> 492 </li> 493 <li> 494 <p>The subtitle is a quote from Frank âThe Cushâ Cushman in the film <a href="https://en.wikipedia.org/wiki/Jerry_Maguire">Jerry Maguire</a></p> 495 </li> 496 <li> 497 <p>The picture caption âweâre all equal before a waveâ is a quote from legendary surfer <a href="https://en.wikipedia.org/wiki/Laird_Hamilton">Laird Hamilton</a></p> 498 </li> 499</ul> 500 501<p><strong>Footnotes</strong></p> 502 503<div class="footnotes" role="doc-endnotes"> 504 <ol> 505 <li id="fn:1" role="doc-endnote"> 506 <p><a href="assets/downloads/productivity-performance.pdf" download="">Exploratory Experimental Studies Comparing Online and Offline Programming Performance</a> <img src="/assets/images/pdf.svg" alt="pdf" title="pdf" class="download-icon" /> <br />Sackman, Erikson and Grant (Communications of the ACM. Volume 11. Issue 1. January 1968) p. 3â11Â <a href="#fnref:1" class="reversefootnote" role="doc-backlink">↩</a></p> 507 </li> 508 <li id="fn:2" role="doc-endnote"> 509 <p><a href="assets/downloads/importance-of-the-individual.pdf" download="">Importance of the Individual</a> <img src="/assets/images/pdf.svg" alt="pdf" title="pdf" class="download-icon" /> <br />Robert L. Glass (ACM Sigsoft, Software Engineering Notes. July 1980) p. 48Â <a href="#fnref:2" class="reversefootnote" role="doc-backlink">↩</a></p> 510 </li> 511 <li id="fn:3" role="doc-endnote"> 512 <p>âAn experimental investigation of personality types impact on pair effectiveness in pair programmingâ Sfetsos, Stamelos, Angelis, Deligiannis (Empirical Software Engineering, April 2009) p. 187â226Â
512<a href="#fnref:3" class="reversefootnote" role="doc-backlink">↩</a></p> 513 </li> 514 <li id="fn:4" role="doc-endnote"> 515 <p>âEffects of Personality on Pair Programmingâ Hannay, Arisholm, Engvik, Sjøberg (IEEE Transactions on Software Engineering, March 2010) p. 61 - 80 <a href="#fnref:4" class="reversefootnote" role="doc-backlink">↩</a></p> 516 </li> 517 </ol> 518</div> 519 520 <span id="end_of_article"></span> 521 522 </section> 523 524 <footer class="page__meta"> 525 526 527 528 <p class="page__date"> 529 <strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> 530 Created: 531 </strong> 532 <time class="dt-published" datetime="2023-03-27T00:00:00+01:00"> 533 March 27, 2023 534 </time> 535 </p> 536 537 538 </footer> 539 540 541 542 543 <nav class="pagination"> 544 545 546 547 548 549 550 <a href="/article/blockchain/" class="pagination--pager" title="Blockchain and The Third Web 551"> 552 Previous 553 </a> 554 555 556 <a href="#" class="pagination--pager disabled"> 557 Next 558 </a> 559 560 </nav> 561 562 </div> 563 564 565 </article> 566 567 568 569</div> 570 </div> 571 572 573 <div class="search-content"> 574 <div class="search-content__inner-wrap"><form class="search-content__form" onkeydown="return event.key != 'Enter';"> 575 <label class="sr-only" for="search"> 576 Enter your search term... 577 </label> 578 <input type="search" id="search" class="search-input" tabindex="-1" placeholder="Enter your search term..." /> 579 </form> 580 <div id="results" class="results"></div></div> 581 582 </div> 583 584 585 <div id="footer" class="page__footer"> 586 <footer> 587 <!-- start custom footer snippets --> 588 589<!-- end custom footer snippets --> 590 <div class="page__footer-follow"> 591 <ul class="social-icons"> 592 593 594 595 596 597 <li><a href="https://feeds.feedburner.com/julianbrownerecent"><i class="fas fa-fw fa-rss-square" aria-hidden="true"></i> Feed</a></li> 598 599 </ul> 600</div> 601 602<div class="page__footer-copyright">© 2023 Julian Browne. Powered by <a href="https://jekyllrb.com" rel="nofollow">Jekyll</a> & <a href="https://mademistakes.com/work/minimal-mistakes-jekyll-theme/" rel="nofollow">Minimal Mistakes</a>.</div> 603 604 </footer> 605 </div> 606 607 608
608<script src="/assets/js/main.min.js"></script>
608 609 610 611 612
613<script src="/assets/js/lunr/lunr.min.js"></script>
vendor: 1 bytes, line 613
613
614<script src="/assets/js/lunr/lunr-store.js"></script>
vendor: 1 bytes, line 614
614
615<script src="/assets/js/lunr/lunr-en.js"></script>
615 616 617 618 619 620 621 622 623 </body> 624</html>
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.