<story><title>Too scared to write a line of code</title><url>https://medium.com/i-m-h-o/eef96ea6f4cb?imm_mid=0a9102&amp;cmp=em-velocity-newsletters-vl-save20-20130523-direct</url></story><parent_chain><item><author>cheald</author><text>This is really kind of the whole idea behind the &quot;red, green, refactor&quot; mantra. The point isn&apos;t to write perfect code right out of the gate, it&apos;s to write &lt;i&gt;working&lt;/i&gt; code. Once the test is green, then you can refactor as necessary with the confidence that you aren&apos;t going to accidentally break things (as the test will backstop you).&lt;p&gt;Ironically, I think this is something that affects seasoned programmers more than new ones; the more you know about the trade, the more voices you have saying &quot;no, that&apos;s wrong! Don&apos;t do that!&quot;, which can freeze progress. The way I combat it is by writing down pseudocode in my source code - literally just english, non-compiling pseudocode - which I then &quot;refactor&quot; into working code (thus the first &quot;green&quot; is &quot;it parses&quot;). By making step 0 the expression of the idea rather &quot;writing the fist line of code&quot;, I can get right into the process rather than getting hung up on the &quot;how&quot;.</text></item></parent_chain><comment><author>minikomi</author><text>Also kind of related - programming by &quot;wishful thinking&quot;. You first lay out the flow of the program as calls to high level functions which don&apos;t yet exist, and then go back and fill in the functions as you can. The first few SICP video lectures are all about this style, and I found the idea simple but very useful to avoid trying to hold too much of a problem in your head at once.</text></comment>
<story><title>Too scared to write a line of code</title><url>https://medium.com/i-m-h-o/eef96ea6f4cb?imm_mid=0a9102&amp;cmp=em-velocity-newsletters-vl-save20-20130523-direct</url></story><parent_chain><item><author>cheald</author><text>This is really kind of the whole idea behind the &quot;red, green, refactor&quot; mantra. The point isn&apos;t to write perfect code right out of the gate, it&apos;s to write &lt;i&gt;working&lt;/i&gt; code. Once the test is green, then you can refactor as necessary with the confidence that you aren&apos;t going to accidentally break things (as the test will backstop you).&lt;p&gt;Ironically, I think this is something that affects seasoned programmers more than new ones; the more you know about the trade, the more voices you have saying &quot;no, that&apos;s wrong! Don&apos;t do that!&quot;, which can freeze progress. The way I combat it is by writing down pseudocode in my source code - literally just english, non-compiling pseudocode - which I then &quot;refactor&quot; into working code (thus the first &quot;green&quot; is &quot;it parses&quot;). By making step 0 the expression of the idea rather &quot;writing the fist line of code&quot;, I can get right into the process rather than getting hung up on the &quot;how&quot;.</text></item></parent_chain><comment><author>mawhidby</author><text>Recently (as in a crazy experience over the past week), I&apos;ve been feeling the same way described by you, and by the OP; but I&apos;ve scaled this up to a much higher abstracted level.&lt;p&gt;The only way I can really describe it is (in terms of what you just said): &quot;red, green, refactor&quot; your life, not just your job. Constantly question everything you&apos;re doing, and find out what you don&apos;t like about it. Find the root cause of that feeling, and figure out what you can do to fix it. Find and take the steps to complete that.&lt;p&gt;Edit: I will add though, that the trick is to do so without stopping progress, as you said.</text></comment>