Live data from Hacker News

Too scared to write a line of code

medium.com

1–10 of 130 posts

Re: Too scared to write a line of code

#2
This is really kind of the whole idea behind the "red, green, refactor" mantra. The point isn't to write perfect code right out of the gate, it's to write working code. Once the test is green, then you can refactor as necessary with the confidence that you aren't going to accidentally break things (as the test will backstop you).

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 "no, that's wrong! Don't do that!", 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 "refactor" into working code (thus the first "green" is "it parses"). By making step 0 the expression of the idea rather "writing the fist line of code", I can get right into the process rather than getting hung up on the "how".

Re: Too scared to write a line of code

#3
What keeps me from coding is not necessarily optimization (well, at least its connotation connected to speed), but maintainability...By that I mean the constant battle between, "Do I write the boilerplate I need to set this up right?" and "Let me just copy/paste/mock all of that". To me, this is a more sapping concern than optimized code, because taking too many shortcuts makes the project harder to maintain in its midstages...even worse, the shortcuts can cause sloppiness to cascade into the design of all the other dependent objects and interfaces.

Doing some nominal TDD has helped quite a bit for me, because it does require writing code, but not code that I have to worry too much about (and if it happens to be a pretty shitty, shortsighted test, I can delete it without it, theoretically, hampering the app) screwing me over. Sometimes this physical act is enough to get me past the code-writing block.

Also, if I actually do the testing right, it prevents regression, improves code quality, etc. etc.

Re: Too scared to write a line of code

#4
post #2

This is really kind of the whole idea behind the "red, green, refactor" mantra. The point isn't to write perfect code right out of the gate, it's to write working code. Once the test is green, then you can refactor as necessary with the confidence that you aren't going to accidentally break things (as the test will backstop you). Ironically, I think this is something that affects seasoned programmers more than new on…

Sometimes I'm surprised at the lack of parallels between writing long-form articles and writing code. How many people draw a general outline of their program, what they want each part to do, and how the whole thing should be layed out? Who plans before they start coding it?

Re: Too scared to write a line of code

#9
I remember when Facebook's front page code leaked. I am no PHP expert, but it was pretty ugly code. Probably today you couldn't get hired at Facebook if you wrote code like that.

http://techcrunch.com/2007/08/11/facebook-source-code-leaked...

I've heard many arguments where people will tell you, it won't scale. Or you're doing it all wrong by writing quick and dirty procedural code. Quite frankly scaling is about the nicest problem to have if you're a startup. Without traction your ugly code simply isn't going to matter. With traction you will gain funding and the ugly code problem quickly disappears like I assume it did at Facebook.

Re: Too scared to write a line of code

#10
post #2

This is really kind of the whole idea behind the "red, green, refactor" mantra. The point isn't to write perfect code right out of the gate, it's to write working code. Once the test is green, then you can refactor as necessary with the confidence that you aren't going to accidentally break things (as the test will backstop you). Ironically, I think this is something that affects seasoned programmers more than new on…

Sometimes I'm surprised at the lack of parallels between writing long-form articles and writing code. How many people draw a general outline of their program, what they want each part to do, and how the whole thing should be layed out? Who plans before they start coding it?

I think these types used to be derogatorily referred to as "cowboy coders" in the 90's by overly process oriented developers who came from an era of mainframes and punchcards.

I think a big shift in modern software development came about when people finally realized that developing software is by nature a "messy" process. Loose text files, REPL sessions filled with red lines on the console, randomly scribbled boxes with arrows on loose sheets of paper strewn about the room; traversing object graphs in your head while on the drive to work. There is no "outline" to frame any of that. The outline only exists after the software has been built.

Post reply on HN