Write code like you just learned how to program (2010)

I think this misses why we structure code in the first place. It&#x27;s not because it&#x27;s aesthetically pleasant or anyone cares about or cool usage of the visitor pattern, but because unstructured newbie code only takes you so far in the most literal sense.<p>There&#x27;s a point, a number of lines of code, where unstructured code becomes completely unmaintainable. You can&#x27;t add to it, you can&#x27;t change it, you certainly can&#x27;t understand it. It&#x27;s just what it is.<p>Structure, modeling, software architecture, testing, development practices, those sorts of things, these are basically the entrance fee for getting to work on larger problems.

This kind of straight forward&#x2F;naive code actually tends to contain many bugs. I once worked with a guy who very quickly produced stuff. One thing he wrote was a program to display a table on a small screen. He mentioned that he thought that something was off in the drawing api or the hardware because it would not show a border around the table. That sounded strange, but whatever. Then I inherited his code and was tasked with extending it. Because I found these very large functions of &#x27;doing straightforward stuff&#x27; rather hard to extend reliably, I wrote some automated tests for it. During writing the tests I found the cause of his &#x27;border issue&#x27;. There were two off-by-one errors in this. Firstly, when there were N rows&#x2F;columns he would draw borders by iterating from 1 to N. However, between N rows&#x2F;columns there are N+1 boundaries, so the iteration should be from 0 to N (inclusive) instead. Next, he was drawing the border with a coordinate that was one too large, making it fall of the screen by one pixel. I think this &quot;write code like you just learned how to program&quot; does not result into very maintainable stuff. And maintenance is generally is an important issue because people keep wanting us to produce features and extensions....

I think the disagreement to this generally falls into the trap of taking(rejecting) this advice as a purported unbreakable law. I can&#x27;t speak for the author, of course, but I think like most (good) advice about <i>how to do a thing (better)</i>, it&#x27;s simply a suggestion that maybe some of the time you should try to be <i>more like this</i>.<p>YAGNI is a somewhat similar advice, and a good one -- at least for my overengineering inclined brain. But if for every single decision you invoke YAGNI, because overengineering is bad, you can also end up with bad code. Even in that case though, the standard for what is &quot;bad code&quot; depends on context (goals, deadlines, etc.). Even <i>&quot;objectively&quot;</i> bad code might not have a significant impact on the project, again depending on context.<p>Article is from 2010-12-24, posted a bunch of times. Earliest: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2037576">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2037576</a>

As professional developers we are usually in a business context and our purpose is not to be artists, to <i>create</i>, we are there to provide the reliable building blocks out of which actual creation can arise.<p>The focus here is “reliable”. Let the creative guys mess around, we should focus on keeping stuff clean. If we start becoming messy that’s no good, because it’s all downhill from there. How can you draw skulls, no matter how messy, if the drawing functions don’t work?<p>Using this article’s story, we are the ones creating the drawing functions, not the “skulls”. We make sure those guys that actually see the skulls can do whatever it is they do. We are bad at that, so when we are asked to be creative we arrive at what the author describes: few lines, something simple, something algorithmic.<p>That’s not because you are all about cleanliness.. you just lack creativity and vision and an artist’s drive to make it reality. And that’s OK.

&gt; Write comically straightforward code, as if you just learned to program, and go out of your way avoid wearing any kind of software engineering hat<p>Can we stop saying this? Has anyone who said this actually TA’d for an intro programming class? It’s not as beautiful and “straightforward” as you imagine.

I don&#x27;t agree with this article. To me, clean and concise code is a skill that you should work to improve. When you have to solve difficult problems, that skill should be automatic and improve the entire process.

I have one colleague who makes beautiful architecture: he thinks where things should go, how things might evolve, how to encapsulate things.<p>I have another colleague who “digs straight tunnels”: long functions, huge if&#x2F;else’s embed things instead of reusing them.<p>I’m more like the first guy. Which means I have a lot to learn about simplicity from the second guy. The second guy’s code is easy to modify, because control flow rarely jumps file, or even function. It never ping-pongs messages between actors. He never prematurely optimises or generalises.

I think this is a good perspective to keep in mind, but you don&#x27;t want to let yourself being trapped in a mode where you very conservatively reject &amp; close yourself down to ideas &amp; possibilities.<p>Systems &amp; software reward greatly those who can keep a broad mentality, who are excited &amp; happy to investigate possibilities &amp; spring for bigger wins. Too often I&#x27;ve seen teams just grow sour &amp; sad &amp; turn into gatekeepers of code &amp; what happens; it&#x27;s a social loss &amp; even if some of the ideas would have gone bad I feel like in the balance keeping an agile mind is effectively necessary.

There is in my opinion a plateau where you are focussed on cleanliness that it slows your programming down as you apply more technique but which also produces the cleanest result. Some improvements are disproportionate in time cost. However as your experience with a language, libraries and approach grows you gain productivity even when focussing on just making something it still ends up cleaner with less repetition. You often can save yourself considerable time on the lines you don&#x27;t have to write.

Make it work. Make it nice. Make it fast.<p>Don&#x27;t forget the second step, otherwise your nightmares will haunt you...

I don&#x27;t want to build prototypes or startups. I have a job. And in my job, my task is to write stable, bug free code that scales. Keeping it simple is important. But code patterns and software architectures exist for a reason.

It&#x27;s an interesting blog. Their whole idea is that you should focus less on beautiful code, computer science stuff, and superficial things like code formatting; you accomplish more when you focus on the problem domain, and try to accomplish what it is you set out to accomplish, even if it means ugly and repetitive code, or hacking something together sometimes.

Sure, if you are only coding for today. But as a software engineer, I&#x27;m coding for <i>tomorrow</i>.<p>Next you&#x27;ll be telling Magnus Carlsen to always capture a piece every move, no matter what.

I usually follow the approach of first writing my feature in the most dead simple way. Only after I finish it I do a pass where if needed. Only if needed I refactor it based on convention and architecture patterns.<p>Ive found this a good way to first understand my solution before I optimize the code. I create less confusing abstractions and more code that’s easy to change. If i try to architect it first I end up always getting the abstractions wrong.

I call this 1-dimensional programming and 3-dimensional programming. (i&#x27;m working on a catchier title)<p>The sort of &quot;excel but in Java&quot; approach, or the no-code lo-code solutions out there work, kinda. They enable the business world equivalent of dropping blood - lots of boxes with if then statements.<p>But try to repeat the blood dripping (or business process encoded in lo-code). Try to use meta-programming techniques to dynamically tweak or even just print it out in logical sequence for the auditors to look at and you have major problems.<p>Computing should be topless - at no point shoukd the format of the code &#x2F; what it represents be &quot;that&#x27;s it, no more programming with this data structure&quot;. And lo-code deliberately does this for strategic reasons, where as the skull blood coder did it for knowledge and experience reasons<p>And he (?) will have another experience - he will find the ways of being more &quot;professional&quot; with his code, and then he will use his creativity to get what that better structured code <i>affords</i> in the donald norman sense, and he will create something even more awesome than a dripping skull.<p>Mozart was always going to make great music. Giving him an orchestra and teaching him music theory just added rocket fuel.

Dance like nobody&#x27;s watching<p>Love like you&#x27;ve never been hurt<p>Sing like no one&#x27;s listening<p>Code like your PR won&#x27;t be reviewed?

<p><pre><code> 10 PRINT$ &quot;HELLO, WORLD&quot; 20 GOTO 10</code></pre>

This was how I learned to program, also, on my dad&#x27;s HP-85. I would animate text on the screen by writing multiple print statements with the correct number of spaces. I drew pictures by drawing lines (HP basic has a DRAW command that draw a line between two coordinates) by writing a new DRAW statement for every line.<p>Much later I learned to encode the position information in DATA statements and loop over them. This is an important leap in skill.<p>Maintaining the balance between quick and dirty and maintainable is one skill that separates the great engineers from the good ones.

&gt;It&#x27;s extremely difficult to be simultaneously concerned with the end-user experience of whatever it is that you&#x27;re building and the architecture of the program that delivers that experience. Maybe impossible. I think the only way to pull it off is to simply not care about the latter. Write comically straightforward code, as if you just learned to program, and<p>So to succeed in being simultaneously concerned with both the UX and the code, just forget about the code. Great advice. Pass.

&gt; After all, look at how many bands find success without the benefit of a degree in music theory.<p>(With the help of producers who most likely do have a degree in music theory)

Related:<p><i>Write Code Like You Just Learned How to Program</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2261458">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2261458</a> - Feb 2011 (6 comments)<p><i>Write code like you just learned how to program</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2037576">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2037576</a> - Dec 2010 (51 comments)

aka drive it like you stole it

It took me four years to paint like Raphael, but a lifetime to paint like a child. - Pablo Picasso

Why skulls though?