pages tagged when-is-x-a-good-decisionYareev's schmonz.comhttps://schmonz.com/tag/when-is-x-a-good-decision/Yareev's schmonz.comikiwiki2023-06-22T08:15:27ZWhen is being "technical lead" a good decision?https://schmonz.com/2015/03/13/when-is-being-technical-lead-a-good-decision/Amitai Schlair2016-11-12T01:39:43Z2016-02-12T06:24:48Z
<p>As software developers, “technical lead” sounds like a role we’re
supposed to want. How can we decide whether we should want it? What
exactly is a tech lead, and what does it take to be good at it?</p>
<h3>What isn’t a tech lead?</h3>
<p>We know by <a href="https://schmonz.com/2007/05/14/schmonzs-theorem/">Schmonz’s Theorem</a> that
there necessarily exist other roles similar to, yet different from,
“tech lead”. By inspection, some such similar roles appear to be:</p>
<ul>
<li>Architect</li>
<li>Developer</li>
<li>Senior developer</li>
<li>System administrator</li>
<li>Line manager</li>
</ul>
<p><strong>Line manager?!?</strong> Sort of. Both line managers and tech leads are
better positioned to make certain types of
<a href="https://schmonz.com/2014/04/01/my-superpower/">decisions</a>.</p>
<p><strong>Sysadmin?</strong> Sort of. Sysadmins and tech leads are better positioned
to understand the costs of technology decisions.</p>
<p><strong>Developer?</strong> For sure. A tech lead who hasn’t been a developer
faces an uphill climb to credibility, even if they somehow manage
to make good decisions.</p>
<p><strong>Senior developer?</strong> Depending on the context-specific meaning of
the title, it could be nearly identical with my conception of a
tech lead, or quite some distance away. In my experience, usually
the latter.</p>
<p><strong>Architect?</strong> Again, depends on the architect and the situation,
but in my experience, it’s difficult for architects to do what tech
leads can do.</p>
<h3>What do tech leads do?</h3>
<p>They help technical decisions get made.</p>
<h3>What do <em>good</em> tech leads do?</h3>
<p>They help good technical decisions get made by the team, consistently,
at every level of the decision tree.</p>
<h3>How do good tech leads do it?</h3>
<p>Their knowledge is wide, such that given any technical problem,
they know enough to guess well about potential solutions. Their
knowledge is a bit deeper in the codebases they live near, so they
don’t have to guess as often. And their desire to see teammates
make informed decisions is wide and deep, such that they can await
the delayed gratification of someone else making the “right” decision,
or even tolerate the discomfort of someone making the “wrong”
decision when it’s not too irreversibly wrong, if that’s what it
takes for them to make a better decision next time.</p>
<h3>What makes a great tech lead?</h3>
<p>A great tech lead has impeccable judgment with which to make every
last technical decision — and instead seeks, above all else, to
share that power with teammates. A great tech lead is one who doesn’t
think of themselves as “leading”, won’t be seen doing any such
thing, and might appear harmless to remove from their team. Don’t
go removing them! But if you do, and it turns out to be harmless,
that might be because they’ve just finished doing a terrific job.</p>
<h3>When is being “technical lead” a good decision?</h3>
<p>When you could be an architect, but are afraid to drift from your
team and your code; when you could be a senior developer, but are
afraid you won’t get to share everything you’ve learned; when you
could be a manager, but are afraid folks won’t get to manage
themselves; when you’ve got the chops to be “technical lead”, but
don’t want anyone thinking of you that way.</p>
<h3>Conclusion</h3>
<p>It’s a tough job. If you do it well, then (just like a sysadmin)
you might not hear appreciation for your work until years later.
Until that day comes, for what it’s worth, you’ve got mine.</p>
When is refactoring a good decision?tag:www.schmonz.com,2014-08-07:ed4417a7059b5d1ff91904645c482f4b/fb2470baca7aa3de7acf81b4dd5fcc79Amitai Schlair2014-09-12T01:34:38Z2014-08-08T02:30:48Z
<p>To develop working, valuable software, we expend time and <a href="https://schmonz.com/2014/04/01/my-superpower/">decisions</a>. In this context, a good decision is one which helps us deliver more value with our time. When might <a href="https://en.wikipedia.org/wiki/Code%5Frefactoring">refactoring</a> be a good decision?</p>
<h3>What's refactoring for?</h3>
<p>I see refactoring, above all else, as a tool for managing risk.</p>
<p>Software development is naturally rich in risk. If we accept that it's worth doing, then we're accepting some amount of risk. For all but tiny projects, the greatest risks are likely:</p>
<ol>
<li>Making undesirable changes that go unnoticed until fixing them is surprisingly expensive</li>
<li>Making desirable changes that seem worthwhile until implementing them proves surprisingly expensive</li>
</ol>
<p><span class="caps">TDD </span>can help us control (1) and — at no additional cost — affords us the option of refactoring, should we want to. And if we seek to control (2), I contend that we should want to.</p>
<h4>Straw man: never stop refactoring!</h4>
<p>Let's say we not only put stories whose only purpose is refactoring on the backlog, but we've got lots and lots of “refactoring stories”, and we prioritize them over everything else. We'll have maximized the number of possible future changes that are easy for us to make, but we'll never get around to making any of them.</p>
<h4>Straw man: never start refactoring!</h4>
<p>Let's say we not only don't ask permission to refactor, we simply never refactor. We'll have maximized how much time we're working on changes motivated solely by business value, but we'll have driven up two averages: the cost per change, and the risk of greatly underestimating the cost per change. Even if we accept that we've taunted Hofstadter's Law.</p>
<h3>Who decides to refactor?</h3>
<table class="img"><caption><em>Illustration by Rebekka Dohme.</em></caption><tr><td><img src="https://schmonz.com/2014/08/07/29.jpg" width="620" height="349" alt="Make it work (bee sinuously finding way to target flower), make it right, make it fast (bees making beelines for target flower)" title="Make it work, make it right, make it fast" class="invertible" /></td></tr></table>
<p>I see developers bee-ing best positioned to decide whether, when, and how to refactor.</p>
<p>I don't see that the “value” of refactoring and the “value” of software's user-visible behavior can be measured along commensurate axes. The latter is what we're here to do. The former is a way to improve our chances of doing it. The latter is best judged by the folks who rely on the <em>outcome</em> of what we make. The former is best judged by the folks who rely on the <em>process</em> of what we make.</p>
<h3>When is refactoring a good decision?</h3>
<p>If we agree that managing the risks of software development means mitigating its inherent variability while collecting just enough options along the way, then refactoring is likely a good decision when:</p>
<ul>
<li>Developers choose it</li>
<li>Its intended scope is to clear a path in front of the desired change</li>
<li>Its intended effect is to deliver the desired change faster (or at least not much slower, and then to deliver future changes faster)</li>
</ul>
<p>After some months of judicious and opportunistic refactoring (more or less depending on context), here are some trailing indicators that you're reaping the benefits:</p>
<ul>
<li>You rarely wish an estimate didn't have to be so large</li>
<li>You almost never feel the need to fudge an estimate</li>
<li>You almost always get what you expected when you expected it</li>
</ul>
<h3>Conclusion</h3>
<p>In software development, where risk management is a fact of life, refactoring is one of the most powerful tools at our disposal. Wielded wisely, it helps us more predictably deliver more value with our time.</p>
<h3>References</h3>
<p>My opinions generally derive from my experience (and, stubborn as I am, little else). The expression of this particular opinion is better for my having encountered the following expressions:</p>
<blockquote><p>”If you want to estimate little things, you have to refactor.” — <a href="http://www.jbrains.ca/">J. B. Rainsberger</a>. <a href="http://vimeo.com/79106557">7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development</a> (Øredev 2013).</p></blockquote>
<blockquote><p>”Why refactor? Economics.” — <a href="http://martinfowler.com/">Martin Fowler</a>. <a href="https://www.youtube.com/watch?v=vqEg37e4Mkw">Workflows of Refactoring</a> (OOP 2014).</p></blockquote>
<blockquote><p>”Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.” — <a href="http://www.soic.indiana.edu/people/profiles/hofstadter-douglas.shtml">Douglas Hofstadter</a>. <a href="https://en.wikipedia.org/wiki/G%C3%B6del%2C%5FEscher%2C%5FBach">Gödel, Escher, Bach</a> (1979).</p></blockquote>
<blockquote><p>”Do not taunt Happy Fun Ball.” Saturday Night Live (1991).</p></blockquote>