Programming with a love of the implicit
DHH says that explicit code favors novices and those with &#x27;fresh eyes&#x27; on a problem while burdening experienced veteran programmers with bloat of boilerplate to read and to write.<p>I may as well come with fresh eyes for any code I wrote over a year ago. I&#x27;m reading _my own code_ with an eye to figure out how it was put together. I should be courteous to my future self and to anyone else who wants to read my code.<p>I pick up a new framework every year or two. I&#x27;ve been a full time software professional for over 16 years and I&#x27;m picking up new tools all the time. I prefer tools that tell me things explicitly so that I don&#x27;t have the steep learning cliff of grokking the entire system in order to be able to work with one little part.<p>And isn&#x27;t this hypocritical? So many people (probably DHH too?) gush about how easy Rails is to get started with, but here DHH argues that it&#x27;s so much butter for the veteran who knows what all the implied magic is. Doesn&#x27;t all that implied magic also leave the beginner kinda helpless? There&#x27;s so much Rails tutorial with the attitude &quot;here, do this, trust me, it&#x27;ll work&quot;. And I&#x27;ve found that trust to be misplaced. The underlying implied design isn&#x27;t actually what I wanted, and it&#x27;s really hard to get it to do what I want because the convention is so baked in.<p>On the other hand, Go is a bit tediously boilerplate heavy. I&#x27;m still looking for the right balance.