<story><title>South Park&apos;s creators on how the series has evolved</title><url>http://www.vanityfair.com/hollywood/2016/09/south-park-20th-anniversary-interview</url></story><parent_chain><item><author>dave_sullivan</author><text>This kind of reminds me of something Louis CK said during this talk about George Carlin: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=R37zkizucPU&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=R37zkizucPU&lt;/a&gt;&lt;p&gt;He talks about how he got good at standup after 15 years of doing the same thing. He threw away all his material (material he&amp;#x27;d been working on for 15 years) and just started trying different things. Then he started throwing away his material every year and creating new material. He noticed that he got better and better by doing this.&lt;p&gt;This also reminded me of another anecdote I&amp;#x27;d heard somewhere where you have a pottery class with 20 students.&lt;p&gt;The class was split: 10 students would make a new sculpture every day while the other 10 would have to produce only 1 sculpture for the class (which of course would represent all the extra planning and execution that went into the solo sculpture). At the end of the quarter, the 10 people who made something new every day and then threw it away were far better at sculpting, while everyone in the other group made something kind of shitty and spent a lot of time doing it.&lt;p&gt;So maybe it&amp;#x27;s not &amp;quot;lack of planning&amp;quot; quite so much as willingness to kill your darlings, again and again.</text></item></parent_chain><comment><author>blowski</author><text>This is probably true for going from novice to mediocre in many things, and there might be some skills where you can become great by constantly starting again.&lt;p&gt;But in software development, the most valuable skills you learn are not those you pick up when throwing a quick CRUD app together, but those you learn when debugging, refactoring and optimising legacy code.&lt;p&gt;I see too many junior devs get frustrated with something, throw it away, only to rebuild it with very similar problems because they didn&amp;#x27;t really understand the root cause in the first place.</text></comment>
<story><title>South Park&apos;s creators on how the series has evolved</title><url>http://www.vanityfair.com/hollywood/2016/09/south-park-20th-anniversary-interview</url></story><parent_chain><item><author>dave_sullivan</author><text>This kind of reminds me of something Louis CK said during this talk about George Carlin: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=R37zkizucPU&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=R37zkizucPU&lt;/a&gt;&lt;p&gt;He talks about how he got good at standup after 15 years of doing the same thing. He threw away all his material (material he&amp;#x27;d been working on for 15 years) and just started trying different things. Then he started throwing away his material every year and creating new material. He noticed that he got better and better by doing this.&lt;p&gt;This also reminded me of another anecdote I&amp;#x27;d heard somewhere where you have a pottery class with 20 students.&lt;p&gt;The class was split: 10 students would make a new sculpture every day while the other 10 would have to produce only 1 sculpture for the class (which of course would represent all the extra planning and execution that went into the solo sculpture). At the end of the quarter, the 10 people who made something new every day and then threw it away were far better at sculpting, while everyone in the other group made something kind of shitty and spent a lot of time doing it.&lt;p&gt;So maybe it&amp;#x27;s not &amp;quot;lack of planning&amp;quot; quite so much as willingness to kill your darlings, again and again.</text></item></parent_chain><comment><author>mcmatterson</author><text>I started doing something similar with the small amount of UI work I do, modeled after [1] (a great watch, BTW). For example, my flow for app icons is like so:&lt;p&gt;1. Spend some tiny amount of time building the simplest thing that represents your idea on an artboard. The focus here is to function as a first step, not to strive for perfection.&lt;p&gt;2. Identify one thing to change (shapes, colours, font, etc).&lt;p&gt;3. Duplicate the whole artboard, and tweak that one thing on the copy.&lt;p&gt;4. GOTO 2. Keep looking back at previous artboards and don&amp;#x27;t be afraid to revert if you notice that you&amp;#x27;ve been off course for the past few iterations. Never delete an artboard, just go back and fork.&lt;p&gt;5. Stop when there&amp;#x27;s nothing immediately obvious to tweak.&lt;p&gt;It&amp;#x27;s a simple workflow that produces much better results than endlessly tweaking a single artboard, and you can see your evolution over time, so it&amp;#x27;s easier to identify the things that work &amp;#x2F; don&amp;#x27;t work to improve your skills the next time around.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;vimeo.com&amp;#x2F;113751583&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;vimeo.com&amp;#x2F;113751583&lt;/a&gt;</text></comment>