(public).sospep.subjects ~ view article ~ how-i-learned-to-program

<h1 style="text-align: center;">how i learned to program</h1>
<h2>[WHAT]</h2>
<ol>
<li>[SUMMARY] by Dan Luu - explains his programming life story, what he learned, when he learned it, the most important things,</li>
</ol>
<h2>[WHY]</h2>
<ol>
<li>]&nbsp;</li>
</ol>
<h2>[WHERE]</h2>
<ol>
<li><strong>] READ THE FULL ARTICLE</strong></li>
<ol>
<li>]&nbsp;<a href="http://danluu.com/learning-to-program/" target="_blank">http://danluu.com/learning-to-program/</a></li>
</ol></ol>
<h2>[WHEN]</h2>
<ol>
<li>] 2016-11-01</li>
</ol>
<h2>[EXAMPLE]</h2>
<ol>
<li>] <strong>The only book I read back then that changed how I write software</strong> in a way that&rsquo;s obvious to me was&nbsp;<a href="https://www.amazon.com/gp/product/0465050654/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&amp;tag=abroaview-20&amp;camp=1789&amp;creative=9325&amp;linkCode=as2&amp;creativeASIN=0465050654&amp;linkId=48b09d6605f7fcaa58922dcf4060a7df" target="_blank">The Design of Everyday Things</a>. The core idea of the book is that while people beat themselves up for failing to use hard-to-understand interfaces, we should blame designers for designing poor interfaces, not users for failing to use them.</li>
<li><strong>] version control -</strong> The other thing I encountered for the first time at IBM was version control (CVS, unfortunately). Looking back, I find it a bit surprising that not only did I never use version control in any of my classes, but I&rsquo;d never met any other students who were using version control. My IBM internship was between undergrad and grad school, so I managed to get a B.S. degree without ever using or seeing anyone use version control.</li>
<li><span style="background-color: #888888;"><strong>[2005-2013]</strong></span> the<strong> three most useful meta-skills</strong> I learned back then, I&rsquo;d say they were&nbsp;<strong>debugging</strong>,&nbsp;<strong>bug tracking</strong>, and figuring out&nbsp;<strong>how to approach hard problems</strong>.</li>
<li>]&nbsp;I read a lot of software engineering papers and came to the conclusion that we know very little about what makes teams (or even individuals) productive, and that the field is unlikely to have actionable answers in the near future.&nbsp;</li>
<li>] I hadn&rsquo;t realized <strong>how effective pair programming with someone is in terms of learning how they operate and what makes them effective.</strong> Since then, I&rsquo;ve asked a number of super productive programmers to pair program and I&rsquo;ve gotten something out of it every time.</li>
<li><span style="background-color: #888888;"><strong>[2013-2014]</strong></span> working on Google's Tensor Processing Unit(TPU) project - google tensorflow (deep learning) - a better understanding of what&rsquo;s possible when a company makes a real effort to make engineers productive.</li>
<li>]&nbsp;Many <strong>people consider writing design docs to be a waste of time nowadays</strong>, but going through this process, which took months, had a couple big advantages. The first is that <strong>working through a design collaboratively teaches everyone on the team everyone else&rsquo;s tricks</strong>.It&rsquo;s a lot like the kind of skill transfer you get with pair programming, but applied to design. This was great for me, because as someone with <strong>only a decade of experience, I was one of the least experienced</strong> people in the room.</li>
<li><strong>]&nbsp;Google was the only place I&rsquo;d worked where a lot of the tools seem like magic compared to what exists in the outside world7</strong>. Sure, people complain that a lot of the tooling is falling over, that there isn&rsquo;t enough documentation, and that a lot of it is out of date. All true. But the situation is much better than it&rsquo;s been at any other company I&rsquo;ve worked at. That doesn&rsquo;t seem to actually be a competitive advantage for Google&rsquo;s business, but it makes the development experience really pleasant.</li>
<li><span style="background-color: #888888;"><strong>[2015-current]</strong></span> MSFT project -&nbsp;<a href="http://bitfunnel.org/on-the-road-to-open-source/" target="_blank">bitfunnel</a>&nbsp;-&nbsp;</li>
<li>] but <strong>I&rsquo;ve noticed that feeling like I&rsquo;m learning a lot at the time is weakly correlated to whether or not I learn skills that are useful in the long run</strong></li>
<li>]&nbsp;<strong>I&rsquo;ve never seen an environment go from &ldquo;bad&rdquo; to &ldquo;good&rdquo;</strong> and I&rsquo;d be curious to know what that looks like and how it happens. Yossi Kreinin&rsquo;s thesis is that&nbsp;<a href="http://yosefk.com/blog/people-can-read-their-managers-mind.html">only management can fix broken situations</a></li>
<li>]&nbsp;"a common failure mode is that you&rsquo;re given work that&rsquo;s a bad fit, and then maybe you don&rsquo;t do a great job because the work is a bad fit. If you ask for something that&rsquo;s a better fit, that&rsquo;s refused (why should you be rewarded with doing something you want when you&rsquo;re not doing good work, instead you should be punished by having to do more of this thing you don&rsquo;t like), which causes a spiral that ends in the person leaving or getting fired."</li>
<li>] note - Centaur = awesome place to work</li>
<li>] + collection related stories on - "how i became a programmer"</li>
</ol>
<h2>[HOW-TO]</h2>
<ol>
<li>]</li>
</ol>
<h2>[REFERENCE]</h2>
<ol>
<li>] # # - CREATE-article# # (this)</li>
<li>] SRC = HN, <a href="https://news.ycombinator.com/item?id=12478408" target="_blank">comments</a></li>
</ol>
<h1 style="text-align: center;">&nbsp;</h1>

~ view article ~ Chapter] index FROM [ Book] analysis-software-developer IN [ libraries] technology-developer-software