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…
Recently (as in a crazy experience over the past week), I've been feeling the same way described by you, and by the OP; but I've scaled this up to a much higher abstracted level. The only way I can really describe it is (in terms of what you just said): "red, green, refactor" your life, not just your job. Constantly question everything you're doing, and find out what you don't like about it. Find the root cause of th…
Too scared to write a line of code
71–80 of 130 posts
Re: Too scared to write a line of code
#72Earlier 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?
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.
For smaller segments though, I'll just write out function signatures, an then go back and fill em out or restructure them.
Re: Too scared to write a line of code
#73People interpret "just do it" as practical advice to write good code, but really it's practical advice to get code from people who won't otherwise write anything. Good code comes from both will and knowledge. When you don't have knowledge, will alone will do. "Just do it" is the best advice for stuck people - you tell them to just start doing the thing, not worry about details, and eventually you'll do it right. This…
Re: Too scared to write a line of code
#74The Bad Guys want you to feel insecure about your work, your position, your relative standing, and everything else because their worst nightmare is that software engineers and scientists and thinkers wake up and realize how much leverage they would actually have if they were organized and capable of looking out for their own interests. We'd reshape the entire business landscape, and the power relationships between us…
Really? From my experience the "Bad Guys" don't give a shit about code quality and will shower you with praise if you give them the crappiest code possible, as long as you make the changes they want 5 minutes ago. This article is really talking about the insecurity that other programmers inculcate, because we're all very smart and all very competitive.
Re: Too scared to write a line of code
#75This 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.
It makes laying out the program much simpler and gives me a birds eye view of how easy it's going to be to maintain.
Re: Too scared to write a line of code
#76Re: Too scared to write a line of code
#77The Bad Guys want you to feel insecure about your work, your position, your relative standing, and everything else because their worst nightmare is that software engineers and scientists and thinkers wake up and realize how much leverage they would actually have if they were organized and capable of looking out for their own interests. We'd reshape the entire business landscape, and the power relationships between us…
The Bad Guys are plentiful and they include scope creepers, late/non payers and idea guys offering equity.
Our tribe (to borrow from your parlance) is goodhearted and kind and usually sees the best in people.
That is until we are crushed under the disillusioning reality that the Screwheads (to borrow from HST's parlance) rule the world and will exploit us instinctively. Our relationship with the Bad Guys/Screwheads is no different than the lion and the wildebeest.
Fortunately we can outsmart the bastards and destroy their outdated business models by harnessing the power of networked machine intelligence.
Re: Too scared to write a line of code
#78"And all that is fantastically interesting, but completely beside the point. I just fell into the classic programmer trap of exploring and learning about (what I find) fantastically interesting things that will address all sorts of amazingly complex situations, but which the learning of said things resulted in absolutely nothing of tangible value being created."
Re: Too scared to write a line of code
#79I don't know--my impression is that most people go to far in the other direction. They write code with no thought at all for the future, and then shortly have nightmarish debugging sessions in spaghetti code that's impossible to extend or reuse. All in the name of a rather extreme "worse is better" philosophy. I've certainly experienced this with some of the people I worked with recently. Anything you win in the shor…
If you write code too slowly, go faster. If you write code too quickly, go slower. You can tell if you're too slow when you've spent two weeks thinking about the program and have neither working code nor a detailed design, or if you've created a detailed design only to realize upon implementation you'd gone about it entirely the wrong way. You can tell if you're too fast if you find yourself spending more time cleani…