Gradual Programming
<p><pre><code>    &gt; A basic observation about the human programming process is 
    &gt; that it is incremental. No one writes the entirety of their 
    &gt; program in a single go, clicks compile + publish, and never 
    &gt; looks at the code again. Programming is a long slog of 
    &gt; trial and error, where the length of the trial and the 
    &gt; severity of the error depend heavily on the domain and the 
    &gt; tooling. 
</code></pre>
I don&#x27;t know about others but I&#x27;ve done this quite a few times. When I have to write some code for a personal project of moderate size (10k LOC) I like to just sleep on it for a while, stay up very late, chug some coffee, and write the entire program. After that I click compile and run a few times, fix any variable names that I&#x27;ve undoutably misspelled, and then maybe 1 or 2 bugs. It&#x27;s basically delaying starting a project until you have a perfect mental image of what that code needs to do, how it looks, and understand mentally every tradeoff you&#x27;re making. I wish I could do this with larger code bases but unfortunately, from my own experience, planning time is exponentially related to the projected lines of code. A 5K to 10k LOC project usually takes me on the order of 2 weeks of thinking. If you go higher than that you&#x27;re talking about months.<p>If you wanted to change the world of programming I would think of a way to abstractly describe dataflows in the vain of unix pipes. Define every part of the transforms you need to do on incoming data, where those responsibilities should be, and then link them together. Current abstraction methods are subpar: they require inherent complexity, are language specific, and are not easy to change after you&#x27;ve using them (unless you have adapters on every part of the code base which in it&#x27;s own right becomes a mess).