Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Too scared to write a line of code

medium.com

Post reply on HN
Print view View original

11–20 of 130 posts

Re: Too scared to write a line of code

#11

Post by stevewillows »

cheald wrote: 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…

I really like your common English approach to coding. As a designer I often do the same with a few key points that my client and I have discussed with some additional influences taped up around my desk.

Great comment!

Re: Too scared to write a line of code

#14

Post by bitwize »

stephengillie wrote: post #4
cheald wrote: 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?

Code is a planning language, so rather than boxes and noodles or pseudocode, I tend to sketch out my plans in code itself. In SICP this is called "design by wishful thinking": you pretend that you already have a library of primitives that do the nitty-gritty work and write the high-level bits of your program using those primitives. Then, you go back and implement the primitives.

It's surprisingly effective.

Re: Too scared to write a line of code

#15

Post by stephengillie »

modarts wrote: post #10
stephengillie wrote: post #4

Earlier quoted context omitted.

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 w…

Maybe I've been spoiled by working with embedded C++ on Arduinos, where we have 3 sections -- Initialization, Setup function, and Loop function. We set variables and include libraries in the Initialization section at top. We run first-time code and open serial & other connections in Setup. Most code goes into the Loop section, which is the function that does the heavy lifting. Extra functions (i.e. the math to convert inches to mm) can be written below, and called in either Setup or Loop.

Re: Too scared to write a line of code

#17

Post by minikomi »

cheald wrote: 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…

Also kind of related - programming by "wishful thinking". You first lay out the flow of the program as calls to high level functions which don'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.

Re: Too scared to write a line of code

#18

Post by johnvschmitt »

This is good advice when you're new to a stack.

But, if you know better, do better please.

After writing tons of code, I've come to realize that 80% of the time, it takes about the same time to do it "right" (scalable/secure/modular) as it does to do it "OK".

Ex: Are plaintext passwords any faster to build/code than encrypted+salt passwords? Nope.

And, it's fine to intend to refactor later. But, too many organizations have no tolerance later to let engineers do things that don't have visible results. I've suffered through a stint of handling "legacy code" like that & it was painful & demoralizing.

Re: Too scared to write a line of code

#19

Post by manmal »

cheald wrote: 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…

Using a visual git client greatly helps with this approach, especially if you are coding in multiple files at once. Once you have "green" status, look over the changed lines in the git GUI and look for lack of patterns, code smells, etc. This separates the coder in you from the reviewer in you.

Re: Too scared to write a line of code

#20

Post by systematical »

I disagree. Too simplistic. It's my job as a developer to try and think of all the ways my project can fail and bog down before hand (within reason on the performance). I've got a list of items I am actually working on and will post it above my desk when done:

1. Let me think about this some more before giving you an answer.

2. I will use my debugger.

3. I will create a new branch for this task.

4. I have commented my code and commented it well.

5. I have accounted for fail scenarios.

6. I have considered multiple solutions to this task.

7. I have not begun hacking away immediately at a task.

8. I have attempted exploiting my code.

Post reply on HN