tag:blogger.com,1999:blog-14971144731074450332024-03-13T15:00:05.057-07:00Kurt Guntheroth's Old Hands BlogKurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.comBlogger38125tag:blogger.com,1999:blog-1497114473107445033.post-14650738612492597022020-05-28T12:02:00.000-07:002020-05-28T12:02:59.161-07:00Re-Intermediation -- Controlling the Internet as a Channel of DistributionI saw an <a href="http://www.slate.com/articles/technology/technology/2013/04/google_has_a_single_towering_obsession_it_wants_to_build_the_star_trek_computer.html">article</a> on Slate about how Google wants to build the famous talking computer from Star Trek. Google doesn't
want to return links that might contain the answer to your question,
but rather to provide a direct answer. It's a romantic vision. I bet it motivates their engineering team. But it can never be.<br />
<br />
There is a big, unbridgeable difference between Google and the Star Trek
computer. Google wants to sell you something. If Google gets to the point where it can
reasonably answer questions like, “What computer is best for me?”, or “Who
has good prices on HDTV sets?”, or "What restaurants are nearby?", I won't be able to trust the
answers, because they are shamelessly influenced by advertizer dollars.<br />
<br />
What concerns me is whether I will have any choice in the matter. <br />
<br />
The web was once touted as a powerful force for consumers,
disintermediating old industries like TV networks, record studios,
newspapers, and retail stores. But it is far more apt to think of the
web as merely a new channel of distribution, disrupting older channels
because of the internet's lower cost structure, and inserting new and
voracious intermediaries between producers and consumers. Rather than
share cost reduction with consumers, these new intermediaries want to
capture all the savings as profit for themselves. <br />
<br />
But an intermediary can only capture these savings if they dominate
this new channel. Unfortunately, the internet makes that easy by
reducing a company's brand name to a few keystrokes. Get that brand
embedded in peoples' heads, and you own the internet as a channel. While Xerox fought for years to keep its name from becoming a verb, Google can laugh all the way to the bank. It may technically lose the ability to prevent a competitor naming itself Google, but it owns the google.com domain name, so who cares?<br />
<br />
If Google can successfully provide direct answers instead of links, they will become <i>the</i>
search engine. This gives them a huge advantage over other search
engines, and enormous power over vendors of any product you may want to
search for. Google will own the only path to find products. Amazon is set up as a marketplace, and is in one sense a competitor to Google, but people use Google first, before they even form the thought of buying a product. <br />
<br />
Google is already dismantling the
fence between their ad-based search results and organic results. If Google can answer conversationally, they will no doubt completely eliminate any distinction.<br />
<br />
If Google becomes "the" marketplace, then they will also wield enormous power
over vendors. They don't have to provide a
direct way to sort products by price. They can sell placement in their
search results, and extract a taste of every sale <br />
<br />Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com2tag:blogger.com,1999:blog-1497114473107445033.post-80364026875519048962017-06-07T12:41:00.003-07:002017-06-07T12:41:36.004-07:00Circular Buffer Container ClassC++ comes with a set of templatized container classes so developers don't have to re-implement a doubly linked list or balanced binary tree class for every project. This is a tremendous time-saver you may not appreciate unless you've had to live without. It can also be a trap that limits performance.<br />
<br />
The roster of container classes in the standard library is thin;
there are three kinds of sequence container (vector/array/string, deque,
list/forward_list), and two kinds of associative container
(map/multimap/set/multiset,
unordered_map/unordered_multimap/unordered_set/unordered_multiset). With
such limited choice, a developer who needs a container with specific
behavior may be forced to accept a lot of unwanted implementation
baggage.<br />
<br />
By giving up the ability to access the sequence as a C-style array, it is possible to obtain a container that is about as fast as <code>std::vector</code>, but supports constant-time insertion and removal from both ends. One variation of this container is the circular buffer. Work to standardize the circular buffer is underway, and in the meantime boost has a version. The circular buffer makes a great queue data structure.<br />
<br />
I ran <code>boost::circular_buffer</code> through the performance tests for sequence containers from my book <a href="https://www.amazon.com/dp/1491922060"><i>Optimized C++</i></a><i>. </i>Here is a link to a <a href="https://www.codeproject.com/Articles/1185449/Performance-of-a-Circular-Buffer-vs-Vector-Deque-a">long article</a> reporting the results.<br />
<br />
Only one new kind of container (the unordered associative container) has been added to C++ since 1995 when the Standard Template Library was introduced. There is a lot of interest from communities with performance issues in adding additional container classes to future versions of C++.Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-85231804277355427842016-09-23T11:09:00.002-07:002017-06-07T08:07:57.434-07:00C++ Optimization BibliographyI wrote a wonderful book on performance tuning in C++. Plug, plug, plug. <a href="https://www.amazon.com/Optimized-Proven-Techniques-Heightened-Performance/dp/1491922060" target="_blank">Buy it now!</a><br />
<br />
The web is full of free optimization advice. The best of these references support their findings with timing benchmarks. Intermediate in quality are references that speak to the behavior of specific processors, but don't contain timing data to allow the reader to reason about the size of the performance speedup. Least interesting are simple lists of recommendations presented without evidence. These are a few frequently-cited references I found useful.<br />
<br />
Most people think of code tweaks when they write about optimization. The performance improvement from statement-level optimization is unlikely to make much difference unless it is magnified by being frequently executed, in a loop or frequently called function, so these tweaks are of uncertain value.<br />
<h2>
Free Resources on the Web </h2>
Here is a free taste of the optimization drug, to whet your appetite and make you want to read <a href="https://www.amazon.com/Optimized-Proven-Techniques-Heightened-Performance/dp/1491922060" target="_blank">my book</a>, or to get you over those two days of the shakes while Amazon delivers your paper copy.<br />
<br />
<h3>
Short Notes</h3>
<dl>
<dt><i>Tips for Optimizing C/C++ Code</i> (<a href="https://people.cs.clemson.edu/%7Edhouse/courses/405/papers/optimize.pdf">PDF</a>) </dt>
<dd>This short note contains two dozen short thought-mantras about optimizing code. Explanations are necessarily brief. It can serve as an, "I didn't know that!" kind of checklist.</dd> <br />
<dt><i>Optimizing C and C++ Code</i> (<a href="http://www.eventhelix.com/RealtimeMantra/Basics/OptimizingCAndCPPCode.htm#.V0s3B76_paV">HTML</a>)</dt>
<dd>Two dozen short thought-mantras on code optimization from game developers.</dd> <br />
<dt><i>Optimization in C and C++: good practices, pitfalls</i>, by Sébastien Binet (<a href="http://www.in2p3.fr/actions/formation/Info12/20120207-binet-opt-cxx.pdf">PDF</a>)</dt>
<dd>Optimization advice on PowerPoint slides. Covers a lot of ground, focuses on linked structures, great graphics.</dd> <br />
<dt>Programming Optimization (<a href="http://www.azillionmonkeys.com/qed/optimize.html">HTML</a>), by Paul Hsieh</dt>
<dd>An interesting mix of general advice, plus brief specific low-level advice for <a href="http://www.azillionmonkeys.com/qed/optimize.html#tricks">optimizing statements</a> and expressions.</dd> <br />
<dt>Performance Optimization (<a href="http://gee.cs.oswego.edu/dl/oosdw3/ch25.html">HTML</a>)</dt>
<dd>This is chapter 25 of the book <i>Object Oriented System Design</i>. It is notable for providing language-independent descriptions of design-time optimization techniques. It uses a dense and somewhat obsolete jargon defined elsewhere in the book, that can be a little hard to read. </dd> <br />
<dt><i>Three Optimization Tips for C++</i>, Andrei Alexandrescu (<a href="https://www.facebook.com/notes/facebook-engineering/three-optimization-tips-for-c/10151361643253920/">HTML</a>)</dt>
<dd>Anything Alexandrescu says is worth reading. This is more of a case study than a general advice piece, and contains many more than three tips. It features reduction in strength, reduction in array writing, and memoization.<br />
<br />
<a href="https://code4thought.wordpress.com/2013/02/03/one-optimization-trick-for-c/">This link</a> has commentary and more measurements on the counting digits example Alexandrescu uses in his article.</dd> <br />
<dt><i>Efficient C/C++ Coding Techniques</i>, by Darren G. Moss (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/ESC_Boston_01_304_paper.pdf">PDF</a>)</dt>
<dd>This is a performance analysis of how several compilers available in 2001 generate code for common flow-of-control constructs, loops that index tables, and methods of structure composition. The findings are unsurprising; that <span style="font-family: "courier new" , "courier" , monospace;">switch</span> is often better than <span style="font-family: "courier new" , "courier" , monospace;">if-elseif-else</span>, that pointers are efficient in loops, and that a class with virtual multiple inheritance is expensive (if that wasn't obvious).</dd> <br />
<dt><i>Writing Efficient C and C Code Optimization</i>, Koushik Ghosh (<a href="http://www.codeproject.com/Articles/6154/Writing-Efficient-C-and-C-Code-Optimization">HTML</a>)</dt>
<dd>A grab-bag of statement- and expression-level optimization techniques, provided without supporting evidence for its effectiveness. Compilers may do some of these optimizations.</dd> <br />
<dt><i>Techniques for Scientific C++</i>, by Todd Veldhuizen (<a href="http://www.cs.indiana.edu/pub/techreports/TR542.pdf">PDF</a>)</dt>
<dd>A somewhat older, but interesting article with a grab-bag of optimization advice. Covers optimizing compile time, eliminating virtual functions, how aliasing interferes with optimization, expression templates,</dd> <br />
<dt>C++ Optimization Strategies and Techniques (<a href="http://www.tantalon.com/pete/cppopt/main.htm" target="_blank">HTML</a>) by Pete Isensee</dt>
<dd>Isensee really knows his stuff. This web page represents the state of the art in optimization circa 1999 (as he notes himself). It is slightly dated now, but still very relevant. The advice is well supported with timing measurements and examples.</dd> <br />
<dt>Faster C++ (<a href="http://www-h.eng.cam.ac.uk/help/tpl/languages/C++/fasterC++.html">HTML</a>)</dt>
<dd>Another grab-bag of statement-level optimizations, plus discussion of profiling, compiler flags, and cache issues. Good bibliography at the end.</dd> <br />
<dt><i>FastC++: Coding Cpp Efficiently</i> blog (<a href="http://fastcpp.blogspot.com/">HTML</a>)</dt>
<dd>I haven't explored this blog extensively, but he seems to know a lot about getting the C++ compiler to use SSE extensions.</dd> <br />
<dt><i>The Top 10 Myths of Video Game Optimization</i>, Eric Preisz (<a href="http://www.gamasutra.com/view/feature/130296/the_top_10_myths_of_video_game_.php" target="_blank">HTML</a>)</dt>
<dd>Interesting viewpoint on several well-loved optimizations. Of particular interest to me, that LUT-based algorithms may be a lose if they have reduced cache performance, since a cache miss is slower than the slowest instruction. The moral would be that small LUTs are good, but big ones can be problematical.</dd> <br />
<dt>Mentor low Latency C or C++ code (<a href="https://www.linkedin.com/pulse/mentor-low-latency-c-code-joe-ellsworth" target="_blank">HTML</a>)</dt>
<dd>This is an article on verifying that programs meet their latency goals, not on optimizing C++ per se, But it has a bunch of good rules about memory allocation, and a couple of other optimization topics, covered without supporting evidence.</dd> </dl>
<dl><dd></dd>
<dt>Performance of a Circular Buffer vs. Vector, Deque, and List (<a href="https://www.codeproject.com/Articles/1185449/Performance-of-a-Circular-Buffer-vs-Vector-Deque-a">HTML</a>)</dt>
<dd>This article reviews the performance measurements from chapter 10 of my book <i><a href="https://www.amazon.com/Optimized-Proven-Techniques-Heightened-Performance/dp/1491922060" target="_blank">Optimized C++</a></i>, plus a new type of container, the circular buffer, that is a candidate for inclusion in C++20.</dd></dl>
<h3>
Longer Works</h3>
<dl>
<dt><i>Technical Report on C++ Performance</i> ISO/IEC TR 18015:2004 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf">PDF</a>)</dt>
<dd>This is a definitive 202 page report on performance-related issues in C++03 by the ISO C++ Committee, fully supported with extensive timing evidence. At the time this TR was written, C++ was under an unjustified attack for being inefficient compared to C. TR 18015 is amazing, offering a mature look at C++ which includes much of the optimization advice in <a href="https://www.amazon.com/Optimized-Proven-Techniques-Heightened-Performance/dp/1491922060" target="_blank"><i>Optimized C++</i></a>, albeit in a compressed form. I was aware of TR 18015 before I began writing my book, then forgot about it until the book was in production.It's a gem.<br />
<br />
TR 18015 covers all of the following:<br />
<ul>
<li>Types of programs (embedded programs on small devices, servers running flat out) with performance issues</li>
<li>Costs of various C++ features: namespaces, type conversion and casting, classes and member function calls, exception handling, and templates, all supported with run time measurements.</li>
<li>Two methods of exception handling (code, table). This discussion also contains a list of alternative error handling mechanisms.</li>
<li>Ways to make the standard I/O functions faster by fiddling with locales.</li>
<li>A hardware interface using atomic and volatile. </li>
</ul>
<br />
TR 18015 spawned some articles in the embedded systems press. Some of these articles offer a much less mature “C++ is less efficient than C” viewpoint.<br />
<br />
<dl>
<dt><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/ESC_Boston_01_304_paper.pdf">Efficient C/C++ Coding Techniques</a>, Moss, 2000</dt>
<dd>"Explains" that C++ is less efficient than C if you use virtual multiple inheritance when simple containment will do. Some comparisons of control flow choices also motivated by poor understanding about what’s good about C++. Great diagrams on virtual functions and virtual inheritance, though.</dd>
<dt><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/ESC_San_Jose_98_401_paper.pdf">Using C++ Efficiently In Embedded Applications</a>, Quiroz, 1998</dt>
<dd>"Explains" that C++ exception handling is expensive because you don’t really need to destroy objects as you exit each stack frame, which is fine if resource leaks are OK with you. Paper talks about some C++ features and categorizes them into cheap, maybe-cheap, and expensive categories.</dd>
<dt><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/ESC_SF_02_405_&_445_paper.pdf">Reducing Run-Time Overhead in C++ Programs</a>, Saks, 2002</dt>
<dd>A paper on optimizing C++. It has great 90/10 law quotes, and covers implicit copying and custom new and delete. It cites Bulka and Mayhew in its bibliography.</dd>
<dt><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/ESC_SF_02_465_paper.pdf">Representing and Manipulating Hardware in Standard C and C++</a>, Saks</dt>
<dd>A paper on how hardware registers may be represented in C++.</dd> </dl>
<br /></dd>
<dt><i>Optimizing Software in C++</i>: Agner Fog (<a href="http://www.agner.org/optimize/optimizing_cpp.pdf">PDF</a>)</dt>
<dd>This is a long (150 page) treatment of statement and expression-level optimization in C++. The material is informed by deep knowledge of the x86 architecture, and makes reference to architectural details. It is only partially translatable to other platforms. Agner Fog actively maintains this document, so its content changes from time to time. If you find it useful, it may be worth caching a copy for your own use, lest the material change out from under you.</dd> <br />
<dt><i>Optimizing C++: A book about improving C++ performance</i> (<a href="https://en.wikibooks.org/wiki/Optimizing_C%2B%2B" target="_blank">Wikipedia</a> | <a href="https://upload.wikimedia.org/wikipedia/commons/7/7d/OptimizingCpp.pdf" target="_blank">PDF</a>) </dt>
<dd>There is some useful information in this small collection of Wikipedia entries, though not enough to call it a book. Good things about this wikibook include:<br />
<ul>
<li>It evolved substantially during the time I was writing <i>Optimized C++</i>, growing to cover more material better.</li>
<li>It has a <a href="https://en.wikibooks.org/wiki/Optimizing_C%2B%2B/Further_reading" target="_blank">bibliography</a>, including free on-line references, and some books that were new to me.</li>
</ul>
There are several problems with it, though:<br />
<ul>
<li>No topic is covered exhaustively. There are, for instance, a few algorithmic techniques, but not a complete or even extensive catalog.</li>
<li>Most optimization advice is supported only by hand-waving arguments about how a compiler might behave.</li>
</ul>
</dd></dl>
<h2>
Books</h2>
<dl>
<dt><i>Efficient C++</i>, Dov Bulka and David Mayhew (<a href="https://www.amazon.com/dp/0201379503" target="_blank">Amazon link</a>) 1999, Addison Wesley, ISBN: 0-201-37950-3 </dt>
<dd>Meticulously researched, but now slightly dated. I have tremendous respect for this work.</dd> <br />
<dt><i>The Software Optimization Cookbook</i>, Gerber, Bik, Smith, Tian (<a href="https://software.intel.com/sites/default/files/m/0/9/e/toc-swcb2.pdf" target="_blank">PDF table of contents</a>)</dt>
<dd>I have not read this book, but it appears to be a useful source of information on processor-dependent optimization for the IA-32 (Intel 32-bit) architecture.</dd> <br />
<dt><i>Optimizing C++,</i> Steve Heller (<a href="http://www.steveheller.org/opt/" target="_blank">HTML</a>), 1999, Prentice-Hall, ISBN: 0-13-977430-0</dt>
<dd>Warning: not about performance tuning in C++ at all, but rather about optimizing an ISAM database. You can view it for free on the web.</dd> <br />
<dt><i>Optimized C++,</i> Kurt Guntheroth (<a href="https://www.amazon.com/Optimized-Proven-Techniques-Heightened-Performance/dp/1491922060" target="_blank">Amazon link</a>), 2016, O'Reilly Media, ISBN: <span class="a-size-base a-color-base"> 978-1491922064</span></dt>
<dd>My book, the best of everything, of course.</dd></dl>
<h2>
Other Notes</h2>
<a href="http://www.highprogrammer.com/alan/windev/visualstudio.html" target="_blank"><i>Microsoft Visual C++ Tips and Tricks</i></a> has all sorts of debugger tricks. Not about optimization, but interesting.Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-49475232136881261312015-12-04T17:41:00.002-08:002015-12-04T17:41:43.261-08:00Mastery Takes TimeI have talked about <a href="http://oldhandsblog.blogspot.com/2014/03/things-only-taught-by-time.html">achieving mastery</a> <a href="http://oldhandsblog.blogspot.com/2011/08/learning-about-robustness.html">previously</a>. <a href="http://www.wisdomgroup.com/blog/10000-hours-of-practice/">Here's another</a>, perhaps better researched article on how long it takes to achieve mastery of a discipline. For those too indolent to click a link, what it says is that it takes about 10,000 hours, or about five full-time years, to obtain a reasonable degree of mastery, and it doesn't matter what it is; playing the violin, swinging a baseball bat, or coding in C++. A study of violinists indicated that "natural" talent was not a factor. The people who were the best were the ones who practiced the most and the longest.<br />
<br />
This is something recent college grads all seem not to know about the careers on which they are embarking. They think (like I once thought) that their natural intelligence and their good education was what made the difference. As an Old Hand, I can tell you that practice has a lot to do with it, and good as you are, you will get a lot better when you've been doing the job for 20 years.Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com1tag:blogger.com,1999:blog-1497114473107445033.post-4325241636403719992015-12-04T17:30:00.000-08:002015-12-04T17:30:00.749-08:00Don't Teach Yourself to Code by Writing a LibraryIt is a <i>terrible </i>idea to teach yourself how to use some unfamiliar feature of C++ by designing a library that heavily uses this feature.<br />
<br />
I
cannot think of an easily explained example, because libraries that
come into existence in this way are very rarely easily explained. Even
experienced C++ folks look at the thing and say, "Huh...<i>WHAT</i>?! Can you
<i>DO THAT</i>?" Readers with more than a couple years of development
experience are grimacing right now, because chances are good that the
code they are paid to work in every day relies on a library that some <i>genius</i> thought would be cooler if it all used some tricks they'd been reading about.<br />
<br />
It
may be cool to the original author, but to anyone who hasn't read the
same blogs as the author, it's just mysterious. Especially mysterious
when the author has trouble doing what they originally imagined was possible, and
ends up covering this lack of experience with a hack, that then lingers
long after the author stops working on the library.<br />
<br />
Writing
libraries is a great time to slow down; to be conservative; to solicit
the widest possible review; to ask your peers, "Is this good style?"Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-51830222492167731422015-06-25T13:35:00.001-07:002015-08-27T15:48:15.587-07:00The Mysterious Hidden Languages of C++C++ is old enough to have teenaged children (like Java, conceived when C++ was itself a wild teenager). Some lucky developers have spent virtually their whole career writing C++. But while C++ grew and solidified, the world of programming languages bubbled and foamed around it. Languages and language ideas came and went. Lexical styles changed and changed again. In these modern days of Hascell, python and Javascript, it can be hard to remember that the folks who originally designed C and C++ learned to program in BCPL.
<br />
<br />
<h4>
The Secret Expression Language Inside C++</h4>
<br />
An <i>expression language</i> is a language where every executable statement produces a value. The vestigal expression language embedded in C++ includes individual expressions, sequences, blocks, if/else, and function call, but not iteration, alas.<br />
<br />
<code>
x = 1, y = 2, z = x + y
</code>
is a sequence. It sets the values of variables x, y, and z, and produces the value 3.<br />
<br />
<code>(rand(), 0)
</code>
is a block. It calls the function <code>rand()</code>, and produces the value 0.<br />
<br />
<code>
x == 1 ? y : (z, 0)
</code>
is an if/else statement. It evaluates the boolean condition <code>x == 1</code>. If x and y have the values set in the previous expression, it produces the value 2. If x is not equal to 1, it produces zero.
<br />
<br />
<h4>
C++ Has a Shiny New Functional Language Too</h4>
<br />
Here's the old syntax for a function.
<br />
<pre><code>
int foo(int x)
{
return x*x-1;
}</code></pre>
Here's the same function as a lambda. Return value in a different place. Syntax for associating a name with the function different. New rules to remember about the difference between lambdas and function pointers.
<br />
<pre><code>
auto foo = [](int x)
{
return x*x-1;
};</code></pre>
<pre><code> </code></pre>
Lambdas have a whole new scheme (ouch, pun) of type deduction rules. Someday they are going to be special. But today they are mostly syntactic sugar, for people who grew up with Javascript or some exotic functional language so they can pretend that C++ is trendy too.Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-32905650921491011942015-03-30T21:47:00.000-07:002015-03-30T21:47:41.571-07:00Aphorisms for Work<span style="font-size: small;">Here are some aphorisms that I think upon, usually during meetings with grumpy managers.</span><br />
<br />
<b><span style="font-size: small;">It takes the same time to do a project right as to do it wrong</span></b><br />
<br />
<span style="font-size: small;">You just spend the tine in different places. You can rush through coding without any planning, but you will spend a lot of time in front of the debugger, and maybe have to throw your code away and start over when you understand the problem better. Or you can do thoughtful design, code at a deliberate pace, run your unit tests, and be done. It comes down to a lifestyle choice.</span><br />
<br />
<span style="font-size: small;"><b>The most dangerous thing in the world is a half-understood <i>Harvard Business Review</i> article</b> </span><br />
<br />
<span style="font-size: small;">There's an <i>HBR</i> article that says, essentially, "All other things being equal, getting software done sooner results in greater revenue." This one paper is the cause of <i>so</i> much misery for development teams. Managers love to use this article as an excuse to pry the software out of development and jam it into production before it's finished. They never read the "all other things being equal" part of the article. </span><br />
<br />
<span style="font-size: small;">There is an <i>HBR</i> article that says, "Pay is not what motivates employees the most." There are managers who read this article and think they can overwork and underpay their employees. They don't read the part about what does motivate employees, like empowerment, recognition, and work/life balance.</span><br />
<br />
<span style="font-size: small;">The most pain is inflicted when the manager hears a summary second-hand, and doesn't even know he has </span><span style="font-size: small;">only </span><span style="font-size: small;">half the advice. He thinks, "There's an HRB article that says you should ship the project as early as possible", or "HBR says employees don't care that much about pay."</span><br />
<br />
<span style="font-size: small;"><b>When everything is important, nothing is</b></span><br />
<br />
<span style="font-size: small;">Ever have your manager tell you on Monday to work on <i>this</i>, because it is the most important thing, and then tell you on Tuesday to work on <i>that</i>, because it is the most important thing. And then you ask him to choose which is most important, and he says they both are? That is what a weak manager does when he doesn't want to make a decision. There must be a most important thing, the thing to finish first. </span><br />
<br />
<span style="font-size: small;">If everything is important, if everything is an emergency, then nothing is really important, because your manager will blame you for what you didn't choose, no matter what you did choose. If your manager behaves in this way, it's a good time to get your resume updated and start looking for work.</span><br />
<br />
<span style="font-size: small;"><b>The 90/90 Rule: The first 90% of development takes 90% of the time, and the last 10% takes the <i>other </i>90% of the time</b></span><br />
<br />
<span style="font-size: small;">Oh, how many times has a developer said he was 90% done in one month, only to spend a second month on that </span><span style="font-size: small;">last </span><span style="font-size: small;">pesky ten percent? You're 90 percent done <i>with the part of the task you know about</i>. Generally that's about half the task. It's a very mature organization indeed that can correctly estimate completion percentages. Your best chance is to estimate things using a consistent process, and then consistently record how your estimate matched reality. Then you can de-rate future estimates until your estimation process matures.<b> </b></span>Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-12972935411883413242015-01-28T14:38:00.000-08:002015-03-28T17:05:37.137-07:00Software Quality: A Race to the Bottom?Another Old Hand, whose opinions are based on very relevant experience, says that the software industry is trapped in a race to the bottom in software quality.<br />
<br />
The trap is that investors' needs are divorced from software companies' mechanisms for producing value. Investors want the stock price or corporate valuation to improve in every reporting period; every year, every quarter, every month, every <i>day</i>. Investors are entirely uninterested in what a company did <i>last</i> month. They invest today to reap profit in the future. Companies, on the other hand, can only demonstrate their ability to produce value by completing projects; shipping disks, posting content, publishing interfaces. But it is hard to encode much value into a software product in a day or a month.<br />
<br />
To impress investors, a company must ship, soon. Since investors aren't interested in what the software does, there is a strong incentive to ship early, but less incentive to ship complete or useful code. For a startup which has never shipped, it's all about who has the value story with the most zeros on the end of it and the shortest time to delivery.<br />
<br />
To impress partners and customers, a company must ship. Customers are largely uninterested in what a company plans to do. They want products now. If a potential customer wants functionality, and there are competitors, the one who ships first wins the customer. Having won, it's a relatively smaller problem to keep the customer. Customers are used to defective software.<br />
<br />
Thus, according to my friend, what wins is crazy, caffeine-fueled speed<i>. </i>Quality doesn't matter. By the time the customer finds out the product is imperfect, the sale is made, the money paid.<br />
<br />
This reasoning depresses me. I hate what it means for my profession. Yet I can find no flaws in the argument, only small exceptions; established quality brands; software products (databases, kernels) that can never work in the marketplace if they aren't reliable; special customers who know what they need and write quality into their purchase agrements.Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com1tag:blogger.com,1999:blog-1497114473107445033.post-46015440861769474022015-01-05T14:06:00.000-08:002015-03-28T17:07:58.994-07:00Reading Your Own Press Releases: A Management AntipatternTo customers, a new company is an unknown. A new company has no reputation. A new company must focus on providing innovative or cost-effective solutions to customer problems, because it's the only story they have to tell. Nothing wrong with that.<br />
<br />
Well-established companies have more to say. In addition to presenting their latest product's features, they can tell customers about their previous products, their many years in business, their reputation for quality. Nothing wrong with that either. It's easy for a customer to choose an established company versus an upstart competitor, even without doing a bunch of homework, because the established company is a known quantity.<br />
<br />
But sometimes, an established company loses its way. They begin to tell <i>themselves</i> about their reputation for quality, their years in business, and their leadership position. Their executives tell their product teams that they can charge a premium price because they are the "Cadillac brand", regardless of the strength of competitive products. If they say this often enough, it becomes received wisdom within the company. I call this behavior <i>reading your own press releases.</i><br />
<br />
A company that is reading its own press releases is already past its prime. When a company starts reading its own press releases, it stops worrying about solving customer problems, or being better, faster, and stronger than the competition. They may even get away with this for a few years if they really were market leaders. But eventually, they find themselves sidelined by their hungrier competitors, and their position of advantage evaporates. <br />
<br />
I've worked for two companies who had this problem. One is now a division of a conglomerate, who fixed the problem by replacing complacent managers. The other annoyed its partners so much with slow product delivery that the partners made the company irrelevant. Last I checked, this second company was still in business, but they shed three quarters of their staff in a paroxysm of downsizing, and never recovered their former greatness.<br />
<br />
I bet you can see some obvious examples in the news of large technology companies who have been reading their own press releases. Where are their new products? Missing in action or underwhelming critics and customers. When your division manager starts talking this way, tell them to wake up and smell the innovation. <br />
<i><br /></i>
Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-83656174041878990032014-12-31T13:57:00.000-08:002015-06-08T10:32:44.148-07:00Smartest Guy in the Room: An Organizational Anti-PatternEvery software developer thinks they're smart. Heck, I think I'm <i>very</i> smart. But organizations seem to go badly wrong any time they anoint one person (or a few people) as <i>the guy(s)</i> to make all the smart decisions, and demote everyone else to code monkey.<br />
<br />
I worked in a big organization where several senior developers convinced management to take them out of their business units, and put them in a special R&D cost center. They were going to do user interface research that would inform the next generation of products. Now, if this had been Bell Labs, and these guys had all been PhDs, they might have discovered the Cosmic Microwave Background or something. But these were just guys. When the team I was on asked these special devs to do some user interface research for our next product, they said, "Oh no, we can't be tied to a particular product." As far as I know this group never produced so much as a PowerPoint presentation. They were disbanded after a couple of years.<br />
<br />
A company where I worked purchased a startup that found itself out of money and on the market for cheap. Their fast-talking CTO was a former employee of my company. He talked my company into putting him in charge of all development in our division, singing the following siren song. "You've been spending way too much time and money on carefully designing and architecting your products. At my company, what we did was just built 'things' and put them in a pile. Once a year or so, I would reach into the pile and pull out enough 'things' to make a shippable product." This strategy had worked so successfully for his last two companies that one had been folded into the other, and the survivor sold to us. It worked so well for us that he went through two years and six million dollars without producing a single product. Our division was shut down and everyone laid off, including the fast-talking smart guy, but not the two managers responsible for hiring him.<br />
<br />
At another company, a smart team was created to write a big Windows editor to solve our very complicated configuration problem for a variety of products. They spent 18 months working (not too successfully) on a universal data input editor. But they never considered the complex problem of compiling the input data for each of several rather different products into usable files. They had in fact no idea how to solve this problem. So they never showed a single working version. They built a rather elaborate castle in the air, starting from the fancy gabled roof downward, hoping they would have an inspiration for how to build the foundation when they got to that point.<br />
<br />
Moral: The smartest guy in the room needs to be managed just as much as the most ordinary. Otherwise they are liable to go off course and waste a bunch of time and talent, just like anyone else. Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-16754921992065612752014-12-26T13:24:00.000-08:002015-12-04T17:33:57.077-08:00NASA's "Decline" is America's TriumphOn the day I was born, the only thing orbiting the Earth was the moon. By the time I was 5, however, the two most advanced nation-states had gotten men into orbit. This culminated, when I was twelve, in a manned moon landing. I recall very clearly how the entire world seemed to stop and take a collective breath as terrible, grainy TV pictures and prosaic radio traffic chronicled mankind's greatest technical achievement.<br />
<br />
Fifty years on, only one more nation has launched men into orbit, and a coalition of european nations can send hardware into deep space. But the United States no longer launches men and women into orbit. We retired the Shuttle fleet after demonstrating that this task, while risky and expensive, could be performed routinely.<br />
<br />
NASA has lost its way, some people say. America has lost its will, some people say. Another symbol of decline, say some.<br />
<br />
I don't think so.<br />
<br />
An American company called SpaceX, with only 1,100 employees, has learned to reliably launch payloads to orbit. Manned launches are close, held back mostly by concerns that their safety be more thoroughly demonstrated. A couple of other companies are close. Their cost per kilo to orbit is a fraction of that charged by the defense giants who assemble rockets for governments.<br />
<br />
This result is astonishing. It means, here in the U.S. at least, we don't <i>need </i>the government to fund commercial activities in space. They fund themselves. It is a triumph of capitalism, almost unheralded. What it means is, the United States wasn't sitting on its hands for the last fifty years. We were investing in materials science, electronics, software, and all the things that actually make up a space mission. We were making launch capability reliable enough that companies would risk nine-digit bankrolls on activities in space. In the language of business, we built a reliable supply chain to space. This was something NASA knew we needed to do way back in 1980.<br />
<br />
And where is NASA? Right where they should be, reaching out for another planet that we cannot yet grasp. Probably <i>all </i>other planets by the time we put boots on Mars. This year (2014), there isn't one part of a Mars mission that we really know how to do; keeping human beings healthy and strong on a long voyage; soft-landing a big payload on Mars; building a rocket on-site for the return to Earth. Some of these problems can be solved by brute force and expenditure of treasure. That's what NASA is for. And right behind are the entrepeneurs and their engineering teams, looking to finesse these problems to make it economical.<br />
<br />
To those who say we should forget about space and spend NASA's budget to end poverty and hunger, I have this to say. Poverty exists by definition. It can't be eradicated in a society that rewards achievement. And NASA's budget could not banish hunger from the world for as much as a single day, especially where and when evil men wield hunger as a political weapon. President Kennedy had it just right when he said we do things like exploring space, "not because they are easy, but because they are hard." Mankind needs something to strive against, in order to make progress. What Kennedy didn't mention was that the problem of going to Mars is actually more tractable than the problem of ending hunger.<br />
<br />
And to those who say manned exploration is frivolously expensive when robots can do it better, I say this. Who cares if there is an ocean on Titan if we will never stand on its shore? Why return pictures of Mars' dusty, cobbled plains if we will never walk them? Expanding mankind's reach is the <i>only</i> reason to visit space. We should only use robots where we cannot yet venture.<br />
<br />
Mankind's conquest of orbit is nearly complete. The geeky
men and women who will design, build, and fly the first manned Mars
mission are in high school right now. They grew up in a world where
manned space launches were so routine they only made the news by being
so dramatically photogenic. <br />
<br />
I expect to watch the Mars landing in beautiful hi-def color before I die of old age. Maybe on my wall-sized flat screen, maybe on my wristwatch. The men who landed on the moon were my father's age. The men and women who land on Mars will be my childrens' age.<br />
<br />
So stop wasting time reading this and get to work!Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-69658994157869338732014-05-13T11:16:00.001-07:002014-05-13T11:16:27.261-07:00One-Man Code ReviewHow do you do a code review if you are working alone? You obviously have already read your own code and found it beautiful. <a href="http://oldhandsblog.blogspot.com/2014/03/how-code-review-fits-into-development.html">Code review fits into the development process</a> as one means of getting feedback on the quality of the code you are writing. Basically, you increase use of all other tools that give the same kind of feedback.<br />
<ul>
<li>Turn the warning level of your compiler all the way up. Do
a release build if you're using Visual C++ because the release build reports more errors. </li>
<li>Install and run a static checker. CppCheck is a free static
analysis tool. Coverity is a paid tool. LLVM has a static checker, or so
I hear. If you have an expensive version of Visual Studio, there are
static checkers, but I've never gotten to use one. </li>
<li>Memory checking tools
that find frees of invalid or already-free storage are built into
visual studio and available for free for linux, and there's always
valgrind if you're patient. </li>
<li>Write and run a set of module tests.</li>
<li>Profiling tools produce results that may
cause you to rethink your interfaces. Writing module tests forces you to
use the API's you create, which often causes you to change things.
</li>
</ul>
Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-6766552986864168232014-04-01T14:08:00.000-07:002014-12-26T14:42:40.497-08:00We're Special -- a Conversational Anti-Pattern<div style="margin-bottom: 0in;">
I've worked within organizations that
told themselves that some best practice widely promoted throughout
the industry cannot possibly be applied at <i>this</i> organization, because
this organization's work is "special". Our code isn't like
other code. Our customers aren't like other customers. Our problems
aren't like other companies problems, so this commonsense rule does
not apply to us (and therefore we need not change our practice).</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
When I had the evangelical furvor of the rookie, this behavior made me wild. It was clear to me that there was absolutely nothing special about our code, and that industry best practices got to be best practices exactly because they were widely applicable. I came to understand that the purpose of the word "special"
in this conversation was to defeat any kind of reasoned argument, any
comparison or evidence, and defend the status quo. </div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
When I became an old hand (and by that I mean, as I was typing this blog entry after facing this anti-pattern yet again), I realized something else. I realized that "special" was the antidote to the phrase "best
practice", which itself is meant to defeat argument without presenting evidence.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
When you find yourself in such a
conversation, it means that both sides have staked out a position
that they are too lazy to defend with any actual evidence. To make
any progress you must change the conversation. Perhaps, "Best
practice X will improve our results in thus-and-such a way.", or, "Practice P is being used successfully by our own competitors."
This raises the level of the conversation so that the other
stakeholders must argue specifically against your evidence.
When they say "special", you can then say, "Yes, but
in what way does our special-ness invalidate the evidence?"
</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
It is tedious to argue from evidence, and
easy to resort to words like "special" and "best
practice". However, the comversation generally goes better if you come prepared with some actual data.</div>
<div style="border-bottom: 1px solid #000000; border-left: none; border-right: none; border-top: none; margin-bottom: 0in; padding-bottom: 0.03in; padding-left: 0in; padding-right: 0in; padding-top: 0in;">
<br /></div>
Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-45306306510179826482014-03-10T23:01:00.002-07:002014-05-13T09:55:07.351-07:00How Code Review Fits Into the Development ProcessCode review needs to be understood as a single tool in a toolbox that hopefully contains many tools that give feedback on the quality of the software development process. Which tool is most appropriate in a given situation depends on how much time and money are available for removing defects, and how much each remaining defect costs. Many tools point to defects in development<br />
<ul>
<li>code review</li>
<li>linters, static checkers, and compiler error messages</li>
<li>test suites </li>
<li>style checkers</li>
</ul>
Code review is very good at finding weaknesses in the way
individual developers understand their programming language tool.
Developers who get busted even once or twice for (for instance) not
destroying dynamic data or not initializing data structures quickly
internalize these skills.<br />
<br />
Human code review is good at finding coding errors that
escaped the compiler, but static checkers also find some of these
errors. Static checkers have little up-front cost and negligable cost
to re-run, but their coverage is limited. By contrast, human code review
is expensive each time you do it, but they have as much coverage as you can afford.<br />
<br />
As a human process, code review is not well suited to reveal defects like performance issues, that require both a specification of acceptable performance and an accurate measurement of a running system. Human processes are also expensive to use for checking conformance with style guidelines, for which fully automated tools are generally available. This doesn't mean you <i>can't</i> use code review to find these defects. It just means there may be more suitable tools.<br />
<br />
Human review of interfaces (for instance C++ header files) is good at finding squishy issues that automated tools aren't any good at finding. There isn't an automated tool yet that can judge the quality of a class or library API. A bad API isn't *wrong* per se. It's just more confused or more difficult to use than it needs to be. Class level APIs aren't captured as user requirements, but evolve out of design and use. Test cases developed early in the class design are also good at detecting API issues. The test writer goes to test a feature, and finds they can't get at the feature in a useful way. The advantage of test cases is that they are inexpensive to re-run if the API implementation changes, while code review is expensive every time you use it.<br />
<br />
Pair programming is the ultimate in code review. While one person types code, another reads the code and makes suggestions. It's also the most expensive form of review, costing a man hour of review for each man hour spent coding. I think code review meetings have almost the same coverage, but at a far lower cost.<br />
<br />
There are automated tools that seek to make code review efficient. You can get your source control system to hold off checkins until people have signaled approval of the code. I find these tools are less effective than a code review that involves an actual face-to-face meeting. When each developer reviews in isolation, it's too easy to get lazy and perform a prefunctory read of the changed lines before signing off on the review. I used a <a href="http://oldhandsblog.blogspot.com/2014/03/how-i-do-code-review.html">code review process</a> that required face-to-face meetings among three or more participants. I felt the cost was justified by the quality of the review.Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-53715134931028752162014-03-10T22:45:00.000-07:002014-05-01T11:52:38.707-07:00How I Do a Code ReviewI led a team to do a design review of every base class in a 40-man-year project; something like 200 C++ class definition .h files. If there was code in the corresponding .cpp file, we sometimes reviewed that too, but we performed this review early in the design phase, so there was often only a header file of 100-200 lines. <br />
<br />
We agreed as a team to follow good-meeting rules. Every design review meeting required a minimum of 24 hours notice, and the review materials also had to be complete and distributed 24 hours in advance. If the materials were not ready in time, the meeting was rescheduled. Each participant was required to have reviewed the materials in advance, and made notes. At the beginning of the meeting, the facilitator asked if everybody had done their homework. If there were not at least three people who had come prepared, the meeting was terminated and rescheduled. Meetings were held face-to-face in a conference room, were scheduled
for 60 minutes, started on time, and were stopped and rescheduled if
they ran over. In this way, we ensured that the client (the person whose class was being reviewed) had prepared, and that a high quality discussion would justify the cost of pulling three or more people away from work for an hour.<br />
<br />
A facilitator other than the client was selected for each meeting. The facilitator ensured the meeting stayed on topic, took notes on issues discussed, and circulated the notes to the participants after the meeting. After the meeting, the client edited the notes to indicate what action they'd taken on each issue. The notes were archived with the other project files.<br />
<br />
The materials prepared for each meeting were the class's .h file listing, printed with line numbers for easy referencing, the class's <a href="http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card">CRC card</a> (a concise and structured form of design document), and any diagrams or other materials the client considered relevant.<br />
<br />
Since I knew that having your code reviewed could be ego-busting, and because I was a relatively experienced C++ developer, I became the client of the first two or three review meetings. One point of these first meetings was to demonstrate that even an experienced developer could benefit from a design review, and the team did indeed find issues in my lovely code that needed addressing.<br />
<br />
When the inevitable snarky comments started coming in that first meeting, I reminded the team, "Today it's my turn. Next week, it'll be you. Lets keep the tone professional, because you want it to be professional when it's your turn in the spotlight." This set the tone for all the meetings to follow. I don't believe we had a single incident of hurt feelings over the whole project.<br />
<br />
After the first couple of meetings, it became clear that there were standard questions we would ask about every class. I compiled a list of these questions and archived it as a project document. (They read like Cliff Notes for Meyers' <i>Effective C++</i>). Within a couple of weeks, these issues disappeared from classes entering the review process.<br />
<br />
The cost of preparation, and the keenness of team questions pushed every developer to produce high quality artifacts for review. This had a corresponding positive impact on the quality of subsequent code. Questions about destroying allocated objects led the whole team to take up the use of smart pointers. The RAII idiom was demonstrated and became commonplace in the code. In this way, the best developers taught good practice to the rest of the team, who were learning C++ as they wrote the code.<br />
<br />
Later on, as the project approached code complete, we began to review the code, using the same meeting process. These code reviews captured many defects that had escaped testing. Our intention was to review only the most critical code, nominated by individual developers. By the end of the project, we had covered about 60% of the code with at least one review.<br />
<br />
The software for this project achieved all its design goals and delivered high initial quality. During the development, our company decided to do <a href="http://en.wikipedia.org/wiki/ISO_9000">ISO 9000</a>. This project received the highest marks from the auditors over a period of a couple of years. Subjectively, we all agreed that we delivered significantly higher quality work than previous projects.<br />
<br />
One important aspect of the review process was the team-oriented, consensual model we adopted. Developers were not required to remedy every issue raised at reviews. There was no sign-off or other coercive process in place. The team came to respect the review process precicely <i>because</i> it removed defects from their code. It also respected their individual judgement, both as coders and as reviewers.<br />
<br />
The cost of the reviews was significant. My own personal experience was that I spent several days after I was "finished" with a class, getting it ready for review, getting the documentation complete, printing listings, etc. On balance, I thought the cost was justified. I would use the same process again.Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-32192388812558637662014-03-06T09:56:00.000-08:002014-05-01T12:00:26.208-07:00Things Only Taught by TimeWhat do you learn over a career of coding, besides 123 different APIs? What's all this value in being an Old Hand? Well... <br />
<ul>
<li>When I was interviewing for work, right out of college, there was a job I didn't take because all the developers had foot-thick listings on top of their filing cabinets. I knew my modest brain could never comprehend such a massive amount of code. Ten years later, I delayed learning Windows programming because applications appeared indecipherably complex, with dlls and a configuration database instead of a single executable. <br />
<br />
I don't print paper listings any longer, but if I did, mine would be ten
feet tall. I've built many Windows apps. It sucks to manage dlls, but
not because they're too complex to comprehend.<br /> <br />
LESSON: Anything that other programmers are comfortable with is not too complex for you.
<br />
</li>
</ul>
<ul>
<li>I spent 10 years becoming a deep domain expert at my first company out of college. I figured I would become a "lifer", safe from the travails of the job market because of my valuable knowledge. Then during an economic downturn, the company changed strategic direction. They shuttered my whole division, laying me off along with 19 of 21 engineers, 12 of 12 marketing folks, and about 50 factory workers. <br />
<br />
It was hard finding a new job because (1) it was the bottom of a recession, (2) my deep domain knowledge was not applicable at any other employer in the city, and (3) I had neglected to learn the latest programming skills because I didn't believe, as a lifer, that I would need them to be up-to-date. <br />
<br />
LESSON: Skills and experience are only valuable if they help you find work.<br />
<br />
LESSON: Skills and experience that help you find work are valuable.
<br />
</li>
</ul>
<ul>
<li>The two engineers that my one-time lifetime employer retained? One was a very lucky new college hire. The company valued its reputation for firm job offers. The other survivor was a nice lady; very quiet, someone who never asked questions or made requests. She wasn't the smartest engineer. She wasn't the most innovative. But she turned out an utterly reliable so-many-lines of code each month without variation. <i>She</i> became a lifer at that company.<br />
<br />
LESSON: what managers value in a software developer is not intelligence, or innovation, or great code. They value reliably low maintenance workers.<br />
</li>
</ul>
<ul>
<li>My very favorite sister-in-law died of cancer at 39 years of age. When her cancer was diagnosed, she didn't quit her job right away, but she did change her behavior. All of a sudden there were some meetings and some tasks that seemed so unnecessary that they offended her sense of limited remaining time. She told me that a week before her diagnosis, she had wasted a bunch of time in these meetings, and all of a sudden she really wanted that time back. She began focusing exclusively on the parts of her job that added value and that gave her satisfaction. She put off the dumb stuff as long as she could. She discovered that lots of dumb stuff eventually just went away if she put it off, because it was dumb stuff. She didn't lose touch by skipping boring meetings. They were boring because nothing happened in them. In this way she became recognized by her managers as the most productive worker in her office. <br />
<br />I was going to boring meetings where nothing happened too. I vowed to behave as though I
had six months to live. I became more productive, because I only did activities that added real value, and that I enjoyed. I came to feel as though I had become
bulletproof. I reasoned that if I was ever let go for only doing productive work, the
company would be doing me a tremendous favor. Such a company would not
last long, and working there until the end would be awful.<br /><br />
LESSON: Only do tasks that add value. You will be the most productive member of your team.
</li>
</ul>
<ul>
<li>I became unemployed in the dot.com crash, becaue my dot.com employer collapsed. It was hard to find work because it was the dot.com crash, and nobody was hiring. It wasn't that I had the wrong skills or wanted too much money. There just wasn't anyplace to send a resume. It turned out that I wasn't bulletproof after all. I went from being the most employable guy I knew to being chronically unemployed. I became unemployed again in the Great Recession. Two employers in a row suffered dramatic, thirty per-cent revenue declines, and laid off their whole software team.<br />
<br />
LESSON: Bulletproof is not the same as invulnerable. Pride goeth before a fall.<br /><br />LESSON: Most software development work is project-oriented. Your job is <i>always</i> vulnerable between projects.<br />
<br />
LESSON: It is <i>always</i> the bottom of a recession when you get laid off. Nobody will be starting new projects then. It is prudent to have money in the bank to last you a year or so.<br />
</li>
</ul>
Looking back on these lessons, they seem very obvious. But each one had to be <i>learned</i>. They were all novel thoughts until after they happened. I'm not sure it's even possible for a rookie to internalize these lessons because the "duh" only comes with experience.<br />
<ul>
</ul>
Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-54746930500531314752014-03-02T17:52:00.000-08:002014-05-01T12:15:01.668-07:00Time to Change Jobs?<div style="margin-bottom: 0in;">
It sucks to be laid off. On top of the emotional response to being rejected and discarded, you have to begin a job hunt from a standing start, while simultaneously finding ways to keep food on the table. It's better for both your ego and your wallet if <i>you</i> pick
the day of your departure and move directly to a new job. <br />
<br />
When is it time to change jobs?<br />
<br />
Change jobs ASAP if you think the management is leading the company in the wrong direction, if they are mistreating you or other employees, or if they want you to do something illegal or unethical. There is no future in such a job. Even if you stay, you'll either get fired (because managers
can tell when you think they're leading the company to trouble), or the company will fold
(because the managers led the company to trouble).<br />
<br /></div>
<div style="margin-bottom: 0in;">
</div>
<div style="margin-bottom: 0in;">
Change jobs if your employer is working you 60
hours every week and they aren't paying you a salary-and-a-half.
There are lots of companies where employees work a reasonable
number of hours. Most companies that make you work long hours don't
pay any better than average. Why give them your life for
nothing? Yeah, every job has crunch time when a deadline looms and you gotta put in the hours. I'm not talking about that. I'm talking about companies who think all developers should work 60 hours a week because the founder worked 60 hours a week at Microsoft back before the IPO and got rich on stock options. Stock options are not all created equal. Most expire worthless.<br />
<br />
Change
jobs if you aren't challenged by what you're doing,
and you like to be challenged. HOWEVER, be mindful that you will continue to discover new and better ways to
use whatever tools you're using for five years or more. Folks just
out of school very often think they know all they will ever need to know by
the time they are 25. This is so totally not true, but you won't
realize it until you're 35 or 40. Find an old hand you respect and
ask them. They will say the same thing. You will just have to trust them
until you feel it for yourself.<br />
<br />
Don't change jobs if you are really happy where you
are. Happy matters a lot more than rich. That's my advice. HOWEVER, don't confuse mere comfort with happiness. It's easy to get comfortable, thinking you know everything
in the world about some mature product written in some old language,
and that you can set the cruise control and be employed for life. But your company may suddenly
drop that mature product, and then where will you be with your
out-of-date skills and no relevant industry experience?<br />
<br />
Change jobs if what you're doing at this job won't help you get another job. I interviewed a software engineer once who had never written any software. He administered contracts of the third-party companies who wrote tests for the software written by other third-party companies. He'd been in this job long enough to forget his CS classes, and had gained no relevant experience. Needless to say, he didn't get the job. I sat near a software engineer who wrote code for a ridiculously small microprocessor for embedded devices. It was so small, its program counter was a feedback shift register, not a counter (fewer gates). Branches and jumps could only target every 16th storage location. There was no macro assember that could emit code for this processor, so you coded it in by hand in hexadecimal bytes. He worked at this job for five years before getting disgruntled, and found he had zero relevant experience anywhere else on the planet. I am personally one of the planet's leading experts on functional RAM testing. Guess how many jobs there are in that field.<br />
<br />
Change jobs if you are being
paid less than friends make for the same work. HOWEVER, don't change
jobs because you heard that's the way to pump up your salary. If you
are underpaid and have hot skills and are just a couple of years out
of school, job-hopping might work for you once or twice. But in the
long run, you can't pump your salary infinitely high. HR directors meet in groups or exchange emails or subscribe to
reports that tell them what software developers with so-many years
experience are making. The only things that will improve your salary
in the long run are visible accomplishments, years of experience, and having a variety of very
up-to-date skills.<br />
<br />
A little humility goes a long way when
thinking about changing jobs. Don't change jobs because you heard a story on the
internet that some guy one year out of school is pulling down $150k. It
doesn't mean that you can get that much (even if you believe stories you read on the internet). Freakishly rich companies like
Facebook and Google do pay better than regular companies. Facebook and Google are correspondingly more fussy about who
they hire. You may not make the cut, even if you think you're a
smart guy.</div>
Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-69681392839542122032014-02-26T12:50:00.001-08:002014-05-01T12:27:35.302-07:00What I Hate About Agile<div style="margin-bottom: 0in;">
</div>
<div style="margin-bottom: 0in;">
Blasphemy, I know. Lest the keyboard burn my fingers, I should say that <a href="http://oldhandsblog.blogspot.com/2013/11/what-i-like-about-agile.html">I really like Agile a lot</a>. What I don't like about Agile is that it means
whatever you choose it to mean. Agile is a brand name, useful for selling books and expensive consulting. But it isn't a specific methodology. Consultants and Agile boosters use the Agile brand the way terrorists use the al Qaeda brand, to make whatever agenda they happen to be pushing sound more powerful.<br />
<br />
If a dev organization uses any Agile practices at all,
and delivers software at the end, its Agile boosters or Agile
consultants proclaim, "See, Agile works." If the
organization uses Agile practices and the software is late, broken or unusable, they say, "We just weren't Agile <i>enough</i>!"</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Because Agile doesn't mean anything,
it's easy to defend any practice, no matter how lame, by calling it Agile. Don't like being held to a schedule commitment? There are <i>agilistas</i> out
there saying, "You can't estimate schedules anyway so Agile
doesn't do schedules." Don't like specs and planning documents? There are Agile boosters saying, "The code is the documentation." Rather
jump straight to coding instead of doing design? There are Agile-branded supporters
for that too.<br />
<br />
Particularly disingenuous are allusions by agilists of a certain stripe to the Standish Group's CHAOS reports and the "Software Crisis". Standish makes money by selling an expensive annual report which perports to show that most software projects are delivered late and over budget (which mean the same thing). This particular strain of agilists proposes to solve the crisis by <i>refusing to schedule</i>. That might cut it on the web, but anywhere hardware must be manufactured or media ordered to coincide with release, refusing to schedule just won't satisfy stakeholders. These same <i>agilistas</i> like to compare their brand of Agile against a straw man comprising the worst habits of traditional development. This doublespeak put me off taking Agile seriously for years.<br />
<br />
I am also leery of developers who claim to be agilists, but whose agenda is to discard any rigor or discipline in an existing software process in favor of blasting off in a blaze of coding glory. There are Agile processes that don't do up-front design, and others that don't do documentation, scheduling, or whatever. These devs take this as an excuse to do away with <i>all</i> these things, with predictably appalling results.<br />
<br />
I am also suspicious of one-size-fits-all prescriptive agile processes like XP. Pair programming (a required practice in XP) is helpful, but very expensive. A mature team can be successful with a less expensive feedback method; code review or maybe static analysis. XP may be the perfect process for a particular team in a particular company. It's just not perfect for <i>every</i> team at <i>every</i> company.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Most Agile shops I've worked in
had decayed Agile processes, announced with great fanfare
by Agile boosters some years before I arrived, and since
collapsed to a few residual practices like feature request sticky-notes on the wall, or daily stand-up meetings. But the "sprints"
were ten week marathons, and the code only shambled out of QA into customer hands a couple times a
year. I'm sorry, but this isn't Agile. Not capital-A Agile, and not little-a agile either.<br />
<br />
I think this situation is sad, because if every dev team combined rapid iteration with feedback from design review and test, plus the amount of rigor in <a href="http://oldhandsblog.blogspot.com/2013/11/agile-practices-reviewed.html">other processes</a> that was appropriate to the quality desired from the work products, we would live in a world of far more beautiful software than what we see today. I don't know what to call this methodology. Sure it's Agile, but it's Agile in a specific way. </div>
Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com10tag:blogger.com,1999:blog-1497114473107445033.post-21080480445024727752013-11-10T18:23:00.001-08:002014-02-26T12:39:16.395-08:00What I Like About AgileAs an Old Hand, I've developed software under both Agile and traditional process methodologies. The traditional process enumerated requirements, architected the system, and produced the code as sequential phases. Each phase produced a document or artifact for formal review. Since the skills needed for these three phases are actually somewhat different, the various phases could even be done by specialist teams.<br />
<br />
What I liked about the traditional process was that it was thoughtful and disciplined. Reviews at the end of each step ensured that all stakeholders agreed that the step was complete and the project was still relevant before the project was allowed to progress.<br />
<br />
Several things were uncomfortable about the traditional process.<br />
<ul>
<li>The great bulk of the work took place during the coding phase. There was not an obvious place to review the relevance of the whole project during coding. </li>
</ul>
<ul>
<li>Too often, the team only discovered it had missed a requirement or failed to do some critical bit of design deep into the coding phase. The end-of-phase reviews were good at checking for incorrect requirements or design issues, but too often failed to catch missing ones. By the time problems were revealed in coding, the project had spent hundreds of man-hours on design or coding that had then to be discarded and re-done. </li>
</ul>
<ul>
<li>The team could not adapt its practice to improve the project because feedback only arrived at the end of each phase. End-of-phase reviews only helped improve the <i>next</i> project, and only if the team stayed together.</li>
</ul>
In my humble opinion, the Agile revolution brought just two new thoughts to software design.<br />
<ul>
<li>Performing many small iterations of the requirements-design-code cycle instead of one big one makes feedback available earlier in the project. This gives the team a chance to improve their process to reduce cost, decrease uncertainty, and improve quality. </li>
</ul>
<ul>
<li>If partially completed software has any functionality, it can be released and start to earn value at once.</li>
</ul>
<a href="http://oldhandsblog.blogspot.com/2013/11/agile-practices-reviewed.html">A host of specific practices</a>
like feature cards, test driven development, or pair programming have
arisen, and been packaged into name-branded methodologies like Extreme
Programming. But specific practices are not what makes a project Agile.
Frequent iteration, frequent release, and frequent feedback make a
project Agile, in my opinion.<br />
<br />
Agile projects do the
same three tasks (requirements, design, coding) that traditional
projects do, notwithstanding certain agile extremists who say they
don't. A sound Agile process adopts practices that ensure that all these
activities provide early feedback, and that the team acts upon this
feedback.Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com1tag:blogger.com,1999:blog-1497114473107445033.post-26947108847848304422013-11-04T17:04:00.000-08:002017-02-18T14:09:17.434-08:00Agile Practices ReviewedI was so horrified by the waste I perceived in prescriptive agile methods like XP that I came very late to the agile party. Here are some specific Agile practices about which I have thoughts.<br />
<ul>
<li>Pair Programming: Pair Programming provides great feedback to individual developers on code
quality, but it is very expensive. It's good for teaching inexperienced devs to
code, but not so helpful when your team is already competent. Code review
provides much the same benefit at lower cost.</li>
</ul>
<ul>
<li>Code Review: There are automated tools for code review that present the user a visual diff of the modified code, and allow commenting and approval. While these tools are great for
reviewing point-changes during maintenance, they discourage thorough
review of whole interfaces. It's too easy sitting at your desk alone, to take a perfunctory glance at the changed lines, and say, "Looks good. Ship it." Shops using automated review tools have to keep an eye open to be sure all reviewers are taking a decent amount of time to actually read the code. I have had <a href="http://oldhandsblog.blogspot.com/2014/03/how-i-do-code-review.html">good results from a heavy-weight design review involving actual meetings</a>. The formality
and required prep work for the meetings, and the expectation of
face-to-face feedback from peers induced higher quality even before the
review.
<br /><br />Linters and static checkers are tools you can use for code review too, even if you're only reviewing your own code.</li>
</ul>
<ul>
<li>Unit Test: I love unit test. A good set of unit tests remove much risk from changing software. Unit tests written alongside (not after) developing the code form a check on the consistency and completeness of newly designed APIs. The needs of unit testing focus attention on separation of concerns and isolation of dependencies, which both push up the quality of the resulting code. Unit tests are most effective when devs buy into the idea of testing as you go. If writing the unit tests is just an annoying check-box to a developer, they are unlikely to give it the attention required for a really good result.</li>
</ul>
<ul>
<li>Code as the Only Deliverable: Some agilists suggest that, since the code is the only artifact shipped to customers, no other artifact has any value. Production of requirements lists, design documents, schedules, and other non-executable artifacts should thus be viewed as wasteful.<br /><br />
This advice has merit from an aspirational standpoint, but has practical weaknesses. Code is too voluminous and precise a language for expressing requirements. Code is too low-level to express architectural decisions. Code cannot express schedules at all. Other kinds of documents may be necessary for internal communication and review, even if they aren't delivered to customers. </li>
</ul>
<ul>
<li>Schedules: There is a persistent myth that Agile methods don't do scheduling. This is untrue on many levels. <br /><br />At the micro level, the effort for individual features must be estimated, and big features broken up into sprint-sized pieces (if you're doing sprints. But otherwise you're doing big-bang development. Hisssss). <br /><br />At the macro level, Agile projects must do scheduling when stakeholders require it. This happens any time they interact with other projects, when long lead time hardware and mechanical packaging must be designed and ordered, or when the dev organization must release by a calendar date or forego important sales (in time for Christmas, for instance). Only a small subset of Agile projects can safely ignore macro scheduling issues, or refuse to predict completion.</li>
</ul>
<ul>
<li>Refactoring: The world of software development is of two minds on the subject of refactoring. One school believes that any change to released software must be minimal, lest the change introduce bugs. The other school says refactoring is OK if it adds value by making the software more maintainable or more flexible, or better supports new features.<br /><br /> In my opinion, both thoughts are schooled by experience. If the initial design and coding were weak, and there are no unit tests, then any change is risky, so change must be minimized. If, on the other hand, the initial design was well motivated and good unit tests are available, refactoring just makes things better and better.</li>
</ul>
Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com2tag:blogger.com,1999:blog-1497114473107445033.post-34096316088457328382013-11-02T15:39:00.001-07:002013-11-02T15:39:48.147-07:00Why Androids are a Bad ThingBuilding android robots must be absolutely the dumbest thing human
beings are trying to do. It is dumber than genetic tinkering, worse
than warming the climate, crazier even than atomic bombs.<br />
<br />
The reason is obvious enough. The purpose of a man-sized,
man-shaped, autonomous artificial intelligence, boiled down to its
essentials, is to replace man. I have absolutely no problem with
robots roving the surface of Mars, where I can't go, or cleaning up
radioactive messes that would fry my bacon. But seriously, androids
exist to put humans out of work, without replacing our need to eat.<br />
<br />
Having replaced telephone operators, drafters, assembly line workers, machinists, and
managers, (and with our sights set on teachers and university
professors) why are engineers beavering away so earnestly trying to
replace everybody else? It's not a very smart thing for smart people
to do. Haven't they read <i><a href="http://oldhandsblog.blogspot.com/2013/10/creating-frankensteins-monster.html">Frankenstein</a></i>? Or <i>I, Robot</i>?<br />
<br />
I try to be philosophical. <a href="http://en.wikipedia.org/wiki/Hominidae">Hominids</a> were evolutionarily successful
because they could adapt knowledge and social structures faster than
DNA could mutate. Androids can evolve their physical structures and
processing horsepower faster than DNA too. Maybe the last <a href="http://en.wikipedia.org/wiki/Neanderthal">Neanderthal</a>
admired that gracile, tall-walking <a href="http://en.wikipedia.org/wiki/Homo_erectus">Homo Erectus</a>. Maybe I can manage to
be proud of our robot descendents too.<br />
<br />
I'm sincerely hoping to die
peacefully in my sleep before this particular turd hits the turbine.
Good luck to you new hands though.
Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-55646895893407805192013-10-29T16:31:00.000-07:002013-10-29T16:45:31.578-07:00Creating Frankenstein's MonsterIn the familiar story of <i>Frankenstein</i>, Dr. F creates a
monster, which later destroys him. Conventional criticism of
<i>Frankenstein</i> refers to Prometheus, punished for stealing the
gods' fire, or speaks of Dr. F's flawed relationships. But I draw a
lesson about the unintended consequences of technology.<br />
<br />
See, <i>everyone</i> wants to create the monster. In your mind, you see
how it will be; new, and big, and so very, very cool. And you will
control it. It will do your bidding. So you build the thing, all in a
rush of late nights and exciting revelation. It is only when the
monster rises from its slab and starts crashing around that you
realize your control may be imperfect. Then the monster does
something scary and altogether unexpected, and you realize that
control was always an illusion. From apps with security holes to
drugs with side effects to disruptive technologies that unravel
social structures, unintended consequences are the dark side of
innovation. When you solve a problem in a new way, you must consider
whether your solution enables unintended results forbidden to
previous solutions.<br />
<br />
RFID tags are one of my favorite examples of Frankenstein
technology. An RFID tag works like a paper label, only you can read
it instantly, with a radio instead of your eyes. It doesn't matter if
the tagged item is upside-down, on a pallet with 99 other items, or
behind another object. At first, RFID looks like a very cool
technology. It makes inventory or checkout a snap.<br />
<br />
But then the monster starts to stir. RFID facilitates locating
items in inventory. It also facilitates theft of valuable items
without the need to hunt for them in every crate in the warehouse.
RFID facilitates instant checkout, replacing human eyes, so it also
enables theft by simply removing the tag. RFID provides remote
reading. The walls that once kept your stuff apart from temptation
suddenly might as well be glass, except that a metal box or plate is
opaque, when you expected all tagged items to be visible. RFID tags
on credit cards, driving licenses, and passports, and even the tags
on ordinary items like subway cards and card-keys identify
individuals, evaporating the anonymity of the crowd. If RFID tags
cannot be turned off, they are permanent beacons of identity. If they
can be turned off, that function enables a potent denial of service
attack against any user dependent on the technology.<br />
<br />
These risks emerge directly from unintended uses of the technology
as designed, in a world with multiple stakeholders. These risks are
quite aside from risks arising from errors in realizing the
technology. Any risk might have been mitigated in the original
design. Some may still be, but only if all the stakeholders voices
are heeded. Dr. F may care less that the monster terrifies some
peasants, and more when it kills his own wife. The central problem is
that Dr. F created his monster without even considering the trouble
it might get into.<br />
<br />
The more rush in development, the fewer use cases are considered.
If you're building a video game, maybe the worst that happens is the
game is unplayable due to griefers. If you're embedding software in a
device with a long service lifetime, the greater is the chance that
someone will exploit any lack of care in a way that you (or your
company) will find painful.<br />
<br />
Let the technologist beware, lest your name go down in history as
the man who created the monster.Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-35045448807013949022012-08-14T20:54:00.001-07:002014-03-02T17:07:51.158-08:00Resumes: The 80% RuleI've sat on both sides of the interview table. I've been a lead looking for competent hires for a complex software project. My experience hiring staff can't be that different to the mainstream.<br />
<br />
I'm amazed at the resumes I receive. I'm amazed at the quantity; about 100 resumes back in the day when we wrote newspaper ads. Somewhat fewer for an ad on hotjobs or monster. When I'm hiring, I don't have HR filter the candidates, because if they do, I don't get any resumes. I love the folks in HR, but they just don't know enough about software. So, 100 resumes in a pile, or 100 resumes in my in-box.<br />
<br />
About 80 per cent of the resumes I receive are unqualified on their face for the clearly described position for which I'm hiring; retreaded poets and astronomers; guys with no experience at all in the languages or technologies I specified; people with no degree and no experience and no apparent ability to write grammatical english sentences. People whose home address is on a different continent (plus they have no experience). I guess these guys send a resume to absolutely every job posting, web site, and advertisement. They might as well not bother. These resumes go in the recycling on the first pass. (HR keeps a copy for awhile, because there is a requirement that they do so).<br />
<br />
That leaves about 20 resumes that are worth a second look, which is to say a careful, front-to-back reading. Of these resumes, about 80 per cent are unqualified in some specific way. You can understand why they applied, but they are not the droids you are looking for. Not enough experience, not the right experience, or there's just something funny about them.<br />
<br />
That leaves five resumes that are people you want to call up and talk to and maybe have in for an in-house interview. Of these five, there are maybe one or two (20% again) that you might make an offer to.<br />
<br />
And there is another one who is lying to you. You bring them in for an in-house interview and their experience melts away. They clearly don't know what they're talking about. They just aren't what they say they are. Posers; fakes; cheats. And not very good ones, because you bust them in a couple of hours of interviews.<br />
<br />
In the modern age, the barriers to submitting a resume are far lower, but there are more jobs. What that means to a hiring manager is more resumes that do not make the first cut, and fewer qualified candidates from whom to choose. You might not even get one candidate you want to hire, so your job stays open longer...and longer...and longer, while your team misses milestones because they are too few. <br />
<br />
So, if it seems like your beautiful resume disappears into a black hole every time you submit it, remember that it's a needle in a pretty big haystack. If you get called, you made the first two cuts, the 20 per cent of the 20 per cent. That's pretty good.Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com1tag:blogger.com,1999:blog-1497114473107445033.post-14283172541112596612012-08-09T13:34:00.000-07:002012-08-14T20:36:24.172-07:00Coder's BlockI used to get coder's block, which is like writer's block, only for software. I'd stare at an empty screen, having no idea where to start. I'd dither between two implementation directions, unwilling to commit to either course, while the cursor blinked away the seconds in the corner of that empty screen.<br />
<br />
I cured my coder's block, by the same technique recommended to cure writer's block; <i>write <u>something</u></i>.<br />
<br />
OK, initially this is hard advice to follow. By definition, if I didn't know what to write, what could I write? If I didn't know which implementation path was best, wouldn't I potentially be wasting my effort writing the wrong thing?<br />
<br />
The solution that worked for me was to write something <i>different</i>. If I didn't know what code to write, I would write down a list of requirements (in prose) for the code. If I was looking at a big undefined area and I didn't know just what I'd need, I would write a structured walkthrough, again in prose. Or, I would write the function header, so that what I was doing had a name and an argument list and a return value. If I was feeling particularly virtuous, I would write a module test attempting to use the unwritten method to solve the problem. <br />
<br />
And this is what happened. As soon as there was <i>something</i> on the screen, I could begin to review it. I might realize that I didn't know what the requirements were. That gave me something to think about, and pretty soon I did know. If I did a walkthrough, I would find myself writing in the passive voice, which would mean that I didn't know what object called which method. Now I had a hook on which to hang further thought. If I wrote the function name, I could begin to think about whether I really needed to do a thing with that name. Every word I wrote got thoughts out of the nebulous fog inside my skull and down in (temporarily) solid and immutable text where I could see it and analyze it and refine it.<br />
<br />
If I couldn't write a paragraph, I'd write a bullet list. If I couldn't write a bullet list, I'd write a few conceptual phrases. What I would <i>not</i> do is get a cup of coffee or read my email or surf the web. That way lay madness. OK, maybe just a little surfing, but I would hold it in mind that I was procrastinating, and what I needed to do was to grind it out.<br />
<br />
I know some people who deliberately distract themselves with some email or web surfing. Maybe that works for them, or maybe they are self-deluded. But for me doing something else is just postponing the hard stuff. I know some people who say the answer comes to them in a dream. In my dreams I just worry about being blocked, although sometimes in the morning I have amazing insights in the shower, when I'm very fresh.<br />
<br />
When I grind it out, I almost never find I've gone down the wrong road. Perhaps that's part of being an Old Hand. Come to think of it, I conquored my coder's block about the same time <a href="http://oldhandsblog.blogspot.com/2012/08/how-i-became-old-hand.html">I became an Old Hand</a>.Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0tag:blogger.com,1999:blog-1497114473107445033.post-89301117648769936552012-08-09T13:27:00.001-07:002014-05-01T12:51:21.579-07:002,000 MondaysThis post is a warning to undergrad CS majors. The stories you hear about the "real world" are not the truth. <br />
<br />
There's this place called Xerox PARC. At the dawn of the Computer Age they invented personal computers, and Ethernet, and Smalltalk, and windows and stuff. And the conference rooms were full of beanbag chairs and the streets were paved with gold. This is what your professors think the real world looks like.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.w2vr.com/archives/Kay/03_PARC.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.w2vr.com/archives/Kay/03_PARC.jpg" height="216" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Xerox PARC, ca. 1980: A fantasy of the real world</td></tr>
</tbody></table>
There's this cool startup you'll hear about (a different one each year), where they <i>give</i> you a MacBook to develop on, and there is free pop and snacks in the fridge, and wine on Fridays, and the office is decorated in twenty-something chic, with a universal gym and foosball tables, and you can work any hours you want, and dress like a slob.<br />
<br />
This is the "real world" you hear about in college. It's a world where nerds rule and employers are so desparate for top talent that they'll do <i>anything</i> to keep you happy.<br />
<br />
It's a fantasy; a fairy tale told by people (students) <i>who have never even seen the real world</i>, and people (professors) <i>who turned their backs on the real world</i> in favor of a place where you could never ever ever be fired no matter how you behaved, once you got tenure.<br />
<br />
Mostly, the real world looks like this.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.thenewatlantis.com/imgLib/20080409_cubiclesfromofficespace.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.thenewatlantis.com/imgLib/20080409_cubiclesfromofficespace.jpg" height="136" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Sorry, this is a lot more real</td></tr>
</tbody></table>
The real world is a very interesting place. There are lots of challenging, engaging projects in the real world. But it's not a playground. Most offices are cube farms or open bullpens. There are a whole lot of add/change/delete screens
and login pages to code for each unique and challenging algorithm you get to invent. There are a thousand lines of somebody else's poorly written code to patch for every line of your own unique software stylings. <br />
<br />
Employers really are desparate for top talent. Only the thing is, new grads
aren't top talent, no matter how smart you are. You're a n00b, a
novice. You won't even know how much you don't know for a couple of
years. To employers, <i>top talent</i> means that one guy on the team who turns out
10 times as many lines of solid, functioning code as anyone else; who works 80
hour weeks for 40 hours of pay; who's been coding since he built his
first computer from individual logic gates when he was six. Top talent has already worked for Microsoft
and Google and Facebook. That's how your employer knows they're top
talent. You haven't worked for anyone at all.<br />
<br />
There are indeed startups with free food, and wine, and foosball, and a fancy office. They just aren't all the same startup. And most of them are in just one or two cities; cities where a decent house costs a million bucks; cities you don't currently live in. What <i>every</i> startup has is long hours and low wages and stock options, which 99 times out of 100 expire worthless, and 1 percent of the time make you a millionaire. Most startups only live for a year. Then they crash and take your dreams of wealth with them, leaving you unemployed, wondering why you worked so hard for so little.<br />
<br />
In the real world, <i>if you're lucky</i>, you either play nice with others, or find yourself suddenly unemployed. If you aren't so lucky, your employer doesn't care if you smell like sweat socks and annoy your colleagues with conspiracy theories, because basically they don't even care if you are a carbon-based life form, as long as you crank out code.This type of employer treats you like a replaceable part, and discards you like last years' cell phone when they're done with you.<br />
<br />
In the real world, your CEO is probably not a geek. He's probably an extraverted, glad-handing, back-slapping, ex-frat-rat, because weirdly enough that's the right skill set for a CEO. He definitely votes Republican. And he thinks you look a lot like the nerdy kids he used to stuff into lockers and trip in the cafeteria.<br />
<br />
Working in the real world is a <i>job</i>. It can be a lot of fun, but it's also a lot of work, and a certain amount of tedium, and a certain amount of putting up with stuff you don't like. There are 2,000 Mondays in the average career. Anyone who tells you different doesn't know what he's talking about.Kurt Guntherothhttp://www.blogger.com/profile/17676474940081443428noreply@blogger.com0