PageSourceSearch

https://www.julianbrowne.com/article/the-95/

html julianbrowne.com collected 2026-09-24 09:25:04 UTC 30,376 bytes, 624 lines download raw bytes

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">&#8617;</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">&#8617;</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">&#8617;</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">&#8617;</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">&copy; 2023 Julian Browne. Powered by <a href="https://jekyllrb.com" rel="nofollow">Jekyll</a> &amp; <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.