Free programming tips are worth every penny

http://wilshipley.com/blog/2005/02/free-programming-tips-are-worth-every.html

by bootload • 18 years ago

49 21 18 years ago

psyklic2• 18 years ago

This is a GREAT article. I love the author's "axiomatic" approach to programming -- these aren't your standard programming tips.

michaelneale• 18 years ago

Yeah - its a good read - his approach seems quite at odds with the currently heavily talked about "agile" approaches.

kirubakaran4• 18 years ago

"Don't write code until you know what you're doing. Now, you may not be able to "know what you are doing" just from thinking, in which case you should start a TEST project and write a bunch of ugly code to make sure your ideas are correct.

Then, start again, in a new directory. We had seven or so different test project directories during the making of Delicious Library"

Wow! Must some inflexible language. In Python, Lisp and Javascript, (those are the ones I am 'happy' with) you can coax "test project" code into real and beautiful code. You can explore as you code.

Many other issues he mentions can be transcended simply by using a better programming language and a good helping of bottom-up programming.

snprbob863• 18 years ago

Maybe for a small bit of code: a method or a simple class.

But once you are talking about a serious system? Your prototype code is guaranteed to be of prototype quality. Starting over from scratch is a strong way to mitigate the risk of it infecting your production code.

kirubakaran4• 18 years ago

In the languages that I mentioned (js,lisp,py), you will write a small function in the interactive shell (repl) and play with it and tinker it until it works perfectly. Then you'll write another function that uses this and other such functions etc. You'll build functions on top of functions until you have a fully usable system. As you know, this is bottom-up programming. While you can continue to improve things and refactor code as much as you want, at no point do you have to throw everything out and start clean. You don't lose any work.

I don't know much Objective C. I've just written some tiny iPhone apps in it. But my feeling is that it strongly encourages top-down programming, which results in the programmer having to do the things mentioned in the article (plan ahead, rewrite from scratch etc).

statictype2• 18 years ago

In the author's case, its Objective-C.

May not have the elegance of a dynamic language but it won't have the sluggishness either.

kirubakaran4• 18 years ago

Your username clearly indicates where you stand :-)

neilc• 18 years ago

Seriously, how often do you say to yourself, "I think I'll dive into this messy code today and try to make it nice and pretty without adding any functionality?"

Maybe I'm just weird, but I do that all the time.

Nobody is going to pay you for that.

Sure they will: refactoring and code cleanup is a commendable activity at plenty of competent software shops.

snprbob863• 18 years ago

You're not weird. Or at least you are no weirder than me.

I sometimes enjoy refactoring more than writing new code. Deleting code, in particular, is pretty much my favorite professional activity.

kirubakaran4• 18 years ago

Unacknowledged type-B procrastination? :-)

http://www.paulgraham.com/procrastination.html

apsurd• 18 years ago

+1 I'm on your side too. A benefit of "cleaning house" is that it does not take as much planning/thought as actually creating new code so this allows me to turn up my favorite music, get into a nice groove, and have at it...now that's what I call a good Friday night!

joe_the_user• 18 years ago

Well, Using Test Driven Development is a new thing. I find that using it, I now can clean-up code as I go along. I have one cycle for implementing new features and one cycle for clean-up currently. But it took learning TDD to be able to do that. And it took extreme programming for SOME shops to see the value in this. The trick is finding those shops.

psyklic2• 18 years ago

You are weird ;-)

I actually agree with the author on both points. There just isn't a good way of measuring how you use your time refactoring and cleaning code, when you could be fixing bugs or adding features (both of which are always-present).

Hence, it's difficult to justify too much time in "beautification" if your code works, even at competent shops. At some point, all of us just need to get the code out, so we must all strike a reasonable point between beauty and reality.

On the first point, I release a fair bit of code into the public domain. Even though I do make it nice and pretty as I code, it always takes additional beautification work before I'm ready to release it to the world (i.e. better commenting, code structure, or documentation). I'm pretty sure it takes a rare programmer with a lot of free time and great experience in the domain to actually have beautiful code at the conclusion of a project.

scott_s• 18 years ago

Constant refactoring makes it easier for me to add new features.

The first time I get something working, I often don't have the perspective to know how the best way to organize or abstract it. If I didn't go back and clean that up, it would be significantly harder for me to add on new features.

schtog• 18 years ago

I do that all the time.

I like the Dijkstra quote: "Elegance is not a dispensable luxury but a factor that decides between success and failure. "

I also think it is a great way to become a better coder to refactor programs until you think it is perfect or close to rather than just make it work and then leave it because then you will never get better than that.

jcromartie• 18 years ago

I do enjoy it, but as I gain more experience in building software for other people I have realized that they usually don't appreciate it. Corporate development sees this sort of activity as a liability. You can break things quite easily when you "correct" something. Poorly-written software tends to have tight coupling all over. Many parts of a system may depend on the "broken" definition of a function. Some things are just too broken to be tackled by this approach.

My current environment is much more receptive to this kind of activity, though.

mjgoins• 18 years ago

The article's tips are mainly aimed at beginners, but I think correct.

tokipin• 18 years ago

funnily, this approach is the complete opposite of the way of the samurai, which stresses swiftness and decisiveness

cf. kamikaze

hboon• 18 years ago

It is important to realize that different styles suits different programmers doing different things. Wil Shipley works better with being more careful and spending more time analyzing before coding. I remember reading about a programmer who writes hours of code (or was it days) before compiling. Or TDD where iterations are shorter and focus on incorporating unit tests. Etc.

Free programming tips are worth every penny

Related Stories