<story><title>Rob Pike&apos;s Rules of Programming (1989)</title><url>http://users.ece.utexas.edu/~adnan/pike.html</url></story><parent_chain><item><author>andrewl</author><text>In &lt;i&gt;The Mythical Man Month&lt;/i&gt; Fred Brooks said &amp;quot;Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won&amp;#x27;t usually need your flowchart; it&amp;#x27;ll be obvious.&amp;quot;&lt;p&gt;I first read that on Guy Steele&amp;#x27;s site: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;www.dreamsongs.com&amp;#x2F;ObjectsHaveNotFailedNarr.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.dreamsongs.com&amp;#x2F;ObjectsHaveNotFailedNarr.html&lt;/a&gt;</text></item></parent_chain><comment><author>vishnugupta</author><text>&amp;gt; Show me your tables, and I won&amp;#x27;t usually need your flowchart&lt;p&gt;A couple of years ago I spent quite some time trying to evaluate the tech stack (and general engineering culture) of merger&amp;#x2F;acquisition targets of my employer. It was quite a fun exercise, all said and done. I encountered all sorts; from a small team start up who had their tech sorted out more or less to a largish organisation who relied on IBM&amp;#x27;s ESB which exactly one person in their team knew how it worked!!&lt;p&gt;I discovered this exact method during the third tech evaluation exercise. When the team began explaining various modules top-down and user-flows etc., I politely interrupted them and asked for DB schema. It was just on a whim because I was bored of typical one way session interrupted by me asking minor questions. Once I had a hang of their schema  rest of the session was literally me telling them what their control and user flows were and them validating it.&lt;p&gt;Since then it&amp;#x27;s become my magic wand to understand a new company or team. Just go directly to the schema and work backwards.&lt;p&gt;Conversely, I&amp;#x27;ve begun paying more attention to data modelling. Because once a data model is fixed it&amp;#x27;s very hard to change and once enough data accumulates the inertia just increases and instead if changing the data model (for the fear of data migration etc.,) the tendency is to beat the use cases to fit the data model. It&amp;#x27;s not your usual fail-fast-and-iterate thing.</text></comment>
<story><title>Rob Pike&apos;s Rules of Programming (1989)</title><url>http://users.ece.utexas.edu/~adnan/pike.html</url></story><parent_chain><item><author>andrewl</author><text>In &lt;i&gt;The Mythical Man Month&lt;/i&gt; Fred Brooks said &amp;quot;Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won&amp;#x27;t usually need your flowchart; it&amp;#x27;ll be obvious.&amp;quot;&lt;p&gt;I first read that on Guy Steele&amp;#x27;s site: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;www.dreamsongs.com&amp;#x2F;ObjectsHaveNotFailedNarr.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.dreamsongs.com&amp;#x2F;ObjectsHaveNotFailedNarr.html&lt;/a&gt;</text></item></parent_chain><comment><author>rjsw</author><text>&amp;gt;I first read that on Guy Steele&amp;#x27;s site.&lt;p&gt;It isn&amp;#x27;t Guy Steele&amp;#x27;s website. That page was written by him but the website is owned by Richard P Gabriel.</text></comment>