February 25, 2005

Free Programming Tips are Worth Every Penny.

Sometimes people say to me, "Hey, Wil, you've been programming since dinosaurs roamed the earth... do you have any advice for young whippersnappers like us?"

And I always respond, "Hey, you kids, GET THE HECK OUT OF MY YARD!"

No, no, I usually demur with, "Oh, gosh, I don't know," as I look down shyly and shuffle my feet.

But, I've thought about it a lot recently, after writing so much solo code for Delicious Library (for the first time in many years), and then taking on a new programmer and trying to impart my style on him. And what I've come up with is a style I call:

* The Way of the Code Samurai *

Now, I don't actually know much about real samurai, but the basic thing I've heard is they stand and stare at each other for hours, and then suddenly BAM strike once and the other guy is down.

That's how you should code.

- Think first. Think some more. Think about the whole problem. Think about a little part of the problem you're going to start with. Think about the whole thing again, in relation to your idea on the starting point.

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 -- one for the video barcode reader, one for the store, one for amazon XML parsing, one for talking to Bluetooth scanners, etc. We learned how to do what we were going to do BEFORE we uglied up the main project with a bunch of code.

Then we copied the good parts out of the test project, and left the cruft. This let us observe rule #2...

- Write all your code "clean," the first time you write it. Make classes for everything. Use enumerated types. Don't take shortcuts. Don't have any part of the code where you say, "Oh, yah, I just glossed over that for now." You are NOT going to go back and fix it. 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?" Nobody is going to pay you for that. In fact, I got called on the carpet for cleaning code during a major update to a piece of software at a previous job -- "What are you doing spending time modifying code that already works? Just add your new features and be done." Never mind that I couldn't understand the code, or that clean code is stable, maintainable, extensible code.

Don't gloss over anything. Write every line to be bulletproof. Write every method as if every other method was out to get your code and try to make it crash, and your job was to make sure it wasn't going to happen in YOUR code. Assume the user is going to hit keys randomly. Assume the network is going to get disconnected. Assume the hardware will fail.

Explain your routines aloud. Do you find yourself saying, "Well, this isn't totally correct, but it works because I know that at this point..." STOP. Redo it. Write it the correct way.

And, if you're in code anyways to extend it or fix a bug, CLEAN IT. Clean as you go, always. Don't consider code to be static. Turn those constants into an enumerated type like you always meant. Take those hard-coded strings and make class variables for them. Replace english phrases with NSLocalized versions. Clean, clean, clean as you go.

- Less source code is better. This is almost always true. The exceptions to this are so rare that every time you think you've found one you should REALLY doubt yourself. Less lines of source code almost always means less code that new programmers have to understand when they come on the project. It means less stuff for you to remember next year when you are in the middle of another version. It means fewer places for you to have mistyped something. It means fewer instructions to execute. It means fewer things to change when you re-architect.

There are some interesting corollaries here. For instance, if you're writing a class to display some text in red (for some reason), don't add a bunch of methods "for the future" that allow you to draw the text in blue or green or purple. Because that's more code than you need right now, and "less code is better."

But, if you suddenly realize you want to draw purple text, you could write the red code again, except put in the color purple. But, "less code is better," so you really need to abstract out the text-drawing code and make it take a color parameter, so you can re-use the same code.

The lesson I'm getting at is, don't try to make code general until you actually need it in more than one place. The worst libraries in the world are the ones people write without actually writing any code that uses them to do actual work for actual users.

And don't write longer, more obtuse code because you think it's faster. Remember, hardware gets faster. MUCH faster, every year. But code has to be maintained by programmers, and there's a shortage of good programmers out there. So, if I write a program that's incredibly maintainable and extensible and it's a bit too slow, next year I'm going have a huge hit on my hands. And the year after that, and the year after that.

If you write code with more code that's fast now, you're going to have a hit on your hands. And next year, you're going to have a giant mess to maintain, and it's going to slow you down adding features and fixing bugs, and someone's going to come along and eat your lunch.

I'm not saying slow code is good. There's a time and a place for optimizations...

- The time and place are AFTER YOU ARE DONE. Optimize methods ONLY after they work and are bulletproof AND you've done testing in Shark and discovered the method is critical.

Don't optimize as you write. Why not? Because, in all probability, you're wasting your time. The VAST majority of the code programmers optimize is executed so rarely that its total speedup to the program can be measured only in nanoseconds. Also, you're probably not very good at it. No insult, but machines and libraries are complex systems, and your guesses as to what's slow are probably pretty bad. You need to run testing tools to find out what is ACTUALLY slow. The results are often surprising. (For instance, in the Mac OS 10.3, having lots of tooltips in a view that you remove and add back to a window a lot is EXTREMELY slow. This is not something you can possibly know to optimize without doing testing in Shark.)

The next time you go to make something a little harder to read but a little faster, ask yourself, "How often will this REALLY get called?" Is the answer less than a hundred times a second? Because processors can now process several BILLION operations a second.

Now, Delicious Library isn't the zippiest program in the world on all hardware, but, actually, it's a LOT faster than it was initially. Those huge, beautiful covers really suck down memory. When we first wrote Library, if you loaded more than about 400 items, the cover images would suck up all your main memory and the program would just crawl. (It was like iPhoto 1.)

I re-architected the entire cover caching and compositing system, and got it so that we could comfortably handle several thousand items, and, if you use the table mode, possibly tens of thousands (I've never had that many items). This took several weeks to do. Now, I'm not as zippy as iPhoto 4, but I'm actually pretty close to the performance of iPhoto 2, and considering I'm just one guy and this was Delicious Library 1, I'm pretty proud of that.

What's the point? The point is, if I'd spent a bunch of time optimizing other parts of the program as I wrote it, I would not have had those weeks at the end to fix the imaging path, which was the slowest part. I would have had to have shipped with a program that could only handle a couple hundred items, and then I would have immediately had to patch it when people started scanning in thousands.

--

[Parlez-vous Français?]

Labels:

47 Comments:

Blogger Jesper said...

Great tips - frank and true. I'm looking forward towards your next post. You're not as bad as you may think.

February 27, 2005 2:48 PM

 
Anonymous cesar said...

hey, cool tips! thanks for all the comments... I will be keepin' a eye in this blog....

saludos (regards in spanish)

February 27, 2005 8:23 PM

 
Anonymous Pearl said...

The Samuri analogy is harilous... but so true.

I'm finding that keeping a (pen and paper) journal is really helpful too. Commenting your code only explains so much and usually only explains the final result. But when it's on paper and you can see exactly what you scratched out because it didn't work... soooo helpful.

(btw, found my way here from the TED feed)

Pearl

March 03, 2005 11:53 AM

 
Anonymous Mark Onyschuk said...

Good post Will. Pearl mentions a paper journal - I do the same, plus make much use of a big honkin' whiteboard...

And a test project, as per your post - it beats working out classes and concepts inside a larger build - once things are worked out inside the test, then they tend to go into the main application.

-Mark

March 04, 2005 7:13 PM

 
Anonymous Richard Albury said...

Amen, brother. As someone who's been spanked for cleaning up crufty code and for having the temerity to say "Make it right, then make it fast" while dragging out my ancient copy of Kernighan and Plauger's "The Elements of Programming Style," I totally agree with this post.

-- Richard

March 07, 2005 4:30 AM

 
Anonymous Max said...

Some great points you have there -- I've seen them before in Extreme Programming, but they're important enough to stand by themselves. =]

November 21, 2005 4:14 PM

 
Anonymous jesse said...

I some times like to spot optimize when a small function is O(n^2) or greater and n is massive... but I alway leave the original C code commented out as a rule.

November 22, 2005 11:31 AM

 
Anonymous Niklas said...

Those tips are equivalent to those that any professional and/or experienced database administrator or tester would hand out.

Thinking first, then doing, is #1. I find it applies to more and more in life. If one gets too finicky, one will surely end up a very sad, lonely Mr. Spock type-of-person, but in many ways this fascist dogma is very good, and extremely healthy - if you want to remain sanely in business for long.

I've come across a lot of people who always start by saying "well, let's just do this quickly and clean up afterwards". My experience also says these people aren't into ninja, but seppuku; they rarely aim to clean their own mess up themselves, but think you should do it, as you're the clever one.

I say: diss them. Like Triumph The Insult Comic Dog once said to Bon Jovi: "It's my liiiife/For me to poop on". What I'm trying to say, is having standards and pushing yourself to code as neatly as possible is not only good for you, but for everybody. So there.

November 22, 2005 2:09 PM

 
Anonymous Pradeep said...

Your tips are worth atleast a dollar each ;)
The Samurai analogy made me laugh.

Thanks for a great article.

November 23, 2005 2:22 AM

 
Anonymous Tom said...

So that's what they're called. No wonder why they're so hard to find!

Great post... Oh so very true...

November 23, 2005 7:08 AM

 
Anonymous Luke Redpath said...

Its a shame you didn't seem to mention testing! Unit test your code, and ideally, write the tests first. Write a test, make it pass. Do the simplest thing that works. Refactor, rinse, repeat.

November 24, 2005 4:24 AM

 
Anonymous Funbug said...

Thanks for sharing. Great post. :)

November 24, 2005 7:45 AM

 
Anonymous Danny said...

While there's a lot of good points in your post, I'm not too sure about your advise to 'clean as you go'. Too often I've seen fresh new bugs being introduced by people who were asked to make just one small adjustment to existing code, and who decided to clean up a little while they were there. In an existing application with a lot of code, it's often difficult to oversee all the consequences of changing existing code. You might even change something which you think is erratic, but which the rest of the application has come to depend upon. I know, in a well-written application, this sort of thing should never happen; but then, if it were well-written, you wouldn't have to do any cleaning anyway...

November 26, 2005 5:14 AM

 
Anonymous wheels said...

The comment about minimizing code resonates with me. It's related to Occam's Razor. As I've described it to others, moving parts have friction. The fastest-executing, most error-free code in your application is the code that isn't there.

Of course, at the moment, my job involves porting some code that uses (to me) massive levels of abstraction and multiple-level indirection. Karma, no doubt.

November 29, 2005 9:56 PM

 
Blogger Dan Bernier said...

About thinking everything through before building it: I often find I think better about the problem after building it through some. I also find that a good instinct about designs can go a long way towards preventing a bad one. If you try to keep the desing generally clean and pleasant, then as you go, you'll probably be able to "bolt on" new features pretty easily. If you just wham it together, adding features will probably be a bit of a mess.

Everything with a grain of salt, I guess.

December 01, 2005 7:46 AM

 
Anonymous Anonymous said...

This sort of advice is commmon, and rather insideous. "Plan for a long time before you do" is a fine approach to most forms of engineering, but not to programming (which is supposed to be engineering; they call it "software engineering", don't they?). This is because programming is not really engineering. When you engineer a bridge, a flaw in design is not an option. If it is discovered halfway though the "do" phase, millions of dollars will have been wasted. With software, however, it is as easy as retyping a bunch of text. I suspect that if people were somehow able to make bridges in this way, we'd have extremely cheap, plentiful and well desgined bridges.

December 01, 2005 9:03 AM

 
Anonymous Kristian Dupont said...

I agree with anonymous. "Think hard before you code" is called up-front design and that is against the spirit of agile development.
Code is easy to change! As long as you have tests, the cost of changing working code is very low and letting the design evolve as you get wiser (no amount of thinking can give you the insight that just a little coding does) results in designs that are much better and much more YAGNI conformant.

December 01, 2005 9:58 AM

 
Blogger Samrobb said...

Anonymous, Kristian - you're both wrong about changing software. While changing software may always be easy, it is not always cheap.

Regardless of the model you use (waterfall, XP, etc.) the cost of changing software always increases as a factor of time. You may be able to minimize that cost via methdology, but you can't eliminate it.

In some models, fixing a defect after software has been released can be 100x more expensive than "fixing" the software up-front by producing a design that avoids the defect in the first place.

"Think hard before you code" doesn't neccesarily translate into an up-front design methodology. It does mean that you make sure you understand the assumptions you're making about your project - including those assumptions that might otherwise be made implictly and come back to haunt you later on down the road.

References:
* Examining the Agile Cost of Change Curve
* Case Study: Finding Defects Earlier Yields Enormous Savings

December 01, 2005 1:47 PM

 
Blogger Wil Shipley said...

I don't mean you should draw out every interaction in your entire program before you write a line of code. I know some people do this, and I find it unnecessarily pedantic and rigid.

I mean, you should understand what you're about to write before you write it. You should know how your drawing routine is going to work, for example.

Now, if you don't know, you have to experiment. That's necessary. But understand that your experiments are NOT final code. Understand you need to write this again, because you didn't plan before you wrote it.

anonymous: I'm not sure where this plentiful, well-designed software is that you're referring to. I've seen plentiful crap, and if Microsoft designed bridges I'd stay the fuck home.

December 01, 2005 3:37 PM

 
Anonymous anonymous (the same one) said...

When you know exactly what you're doing before you're doing it, you are either doing something very simple, or reinventing the wheel. Or, more generally: "Nothing where you know what you're doing before you're doing it is worth doing". In other words, this necessity to experiment Wil Shipley mentioned should be there always. Undoubtably, many of will find this contentious, so let's assume it is there at least some of the time.

Why, after writing "experiment code", does one have to write it again? Why does the final code have to be "planned"? Is it not enough that it's code and it does what it's supposed to do? It has always been enough for me. If your answer is "no", and if there are valid reasons why your final code can not naturally "grow" out of experiment code, it effectively means that your language and your methodology are discouraging experimentation, and with it creative thought. To me, this would be enough reason to ditch them. The tools, that is, not experimentation and creative thought.

December 03, 2005 8:23 AM

 
Blogger Wil Shipley said...

Experimental code is usually horrendously ugly, riddled with odd fiddly bits that we stuck in to see what they did.

December 03, 2005 3:14 PM

 
Anonymous Kristian Dupont said...

Of course, discovering bugs after a release can be disastrous but I don't believe that up-front design has a better chance of avoiding such. Evolving design does not mean "no design" (read Martin Fowler's "Is Design Dead", for instance). And I didn't mean to imply that changing code is costless - just that the total cost in my experience is lower.
Whatever I work on, be it the largest of architectures or the tiniest of functions, I often find that my initial thinking was wrong and I will have to change my approach. It may be just my ability to think that is malfunctioning but I have definitely learned not to fool myself into believing that I can think out solutions. I have to let them reveal themselves.

December 04, 2005 1:28 AM

 
Anonymous Scott Bruce said...

Hi Wil,

I've just finished reading your post and I resonated with much of what you had to say. Great tips, with a focus on flexibility and the foreknowledge that at some point you'll probably have to revisit what you've written. I find programming very karmic like this "what goes around, comes around"...usually to bite you in the ass if you didn't do it right the first time.

With regards to the comments posted by anonymous, and to a lesser extent Kristian, your comments worry me. It would sound that you've adopted the "it'll do/good enough" philosophy.

Quote: "Is it not enough that it's code and it does what it's supposed to do? It has always been enough for me."

If my limited experience has taught me anything that these approaches will either come back to haunt you or the poor bastard that has to go through your code after the fact.

There is all kinds of room for creative thought and experimentation in thinking a problem through and having an idea or several ideas on the best way to solve it and working towards implementing the best solution.

Cleaning as you go and making your design as flexible as possible can in itself inspire creativity because the more flexible your code is the more possibilities there are as a result.

There was a reference to agile development - perhaps I'm misunderstanding the term (and if so I apologize for my ignorance) but it would seem to me that for something to be agile implies that it needs to be responsive and flexible - if that is the end goal then when not try to maximize your potential for success?

I hate to criticize anyone's style because we all have our own ideas of what will and won't work, but I've seen and had to deal with the aftermath of the "good enough" approach too many times to remain silent – history has proven to me time and time again that those who practise that form of programming are asking for trouble.

Anyway, that's my 2 or 3 or 4 cents worth on that. Thanks for a great post.

December 08, 2005 11:43 AM

 
Anonymous Anonymous said...

Interesting comments. If you are the driving force behind the project, you can specify what you want, plan it in general concepts, and the program.
If someone else is specifying the goal/s then I have found that goalposts are always moving, and quite often a trivial change in goalpost means a major re-engineer of the original design concepts. Any tips on manageing that?.
You end up with what amounts to a test program as your production product, and you would have to re-write it from scratch, as the goalposts finally settle down, but who would pay for that when they have a working "test". Probably because people never realise the cost of the samuri watching bit :-)
- and, like you said about computer speeds going up, software expectations change just as fast.

December 12, 2005 3:39 AM

 
Anonymous Scott Bruce said...

Quote: If someone else is specifying the goal/s then I have found that goalposts are always moving, and quite often a trivial change in goalpost means a major re-engineer of the original design concepts. Any tips on manageing that?.

Yes. Take the time to make your design as flexible as possible so you can respond more rapidly to trivial changes in what your client wants. Code is not meant to be written in stone so why program in that way?

Once again my 2 cents worth - but that's the way it seems to me.

December 13, 2005 7:49 AM

 
Anonymous Viktor said...

Very interesting article. Paper and pen is the best way to start programming something.

December 14, 2005 8:02 AM

 
Anonymous Balmore said...

Great tips. I love the paper and pen also. :)

January 29, 2006 9:54 PM

 
Anonymous Balmore said...

Awesome tips! -- I, too, love the pen and paper style.

January 29, 2006 10:29 PM

 
Blogger RSS Spirit Combine said...

Entertaining reading even for us noncoders. Creative types should read this because it applies to their work. Design elements require lines of code. Information requires classes and categories. The creative applications that will win in the long run are the simplest (i.e. fewest code lines) and most elegant (i.e. most efficiently organized).

February 09, 2006 1:08 PM

 
Anonymous Julio Nobrega said...

The optimization tip is the most repeated but the least used.

Just last week, a co-worker was concerned that we are storing multiple clients on a single database. He said tables would get huge, with 500K records, and therefore he wanted to code optimizing loops, iterations on huge arrays, not writing functions (so there's no overhead), a lot of bs.

So I went and inserted one million records, and the current code managed just fine. He said the data I inserted was not enough, because the real data has bigger text strings. So I went and increased the table size to 1GB, and the system ran just fine.

He finally said that it was running fast because it had a lot of RAM, so people understand the problem and know the solution, but I think there's a little bit of pride in these optimization tricks. Newbie programmers, that never had to maintain 2 years old codebase, think that the "cool" thing to do is write efficient code.

It's a quality, indeed, slow algorithms have an impact. But compared to maintenability...

Back to my co-worker friend, I told him: *WHEN*, or *IF* we get to one million records, and 1GB table size, on the production server, that means we have over 100 costumer using the program. By that time, we will be swiming in money, so we will be able to spend a couple hundred bucks and buy more RAM memory, or another computer to act as an standalone DB server.

Just a rant, because I was really annoyed by his comments.. :p

February 21, 2006 7:08 AM

 
Anonymous Andrew S. Townley said...

Hi Wil,

Ancient NEXTSTEP/OmniWeb user here from back when I worked at Informix. Hadn't realized you had split with Omni. Kinda gave up on Apple when Rhapsody->OS X dropped the intel support, so been outta the loop. Looks like you're still doing pretty well though...

Anyway, I thought this was a really good article. Lots more people should follow your advice. I don't know that I agree 100% with your thoughts about don't generalize until you actually need it. I think if you've followed your first rule, you'll know which ones to generalize and which ones not to--at least, that's how I generally work.

Like some of the other readers, some of the comments you got are a bit scary. Anonymous was talking about moving goalposts. Yeah, that tends to happen, but if the person running the project (lead developer or architect) doesn't understand Musashi's Way of Strategy, you're in for a lot of pain anyway. Wil was spot-on with the Samauri analogy. However, even as a developer on a large project, you're assigned specific deliverables. You should approach those deliverables in exactly the same way Wil described: think, think and think some more.

There are a lot of people who think that Agile means that it's got to be "quick and dirty", but that's really just the wrong interpretation, I believe. Agile's a way, not the way (see Joel on Software's Aardvark Spec and another one I can't find, but that's in his book).

The way is a bit like truth: it's only a matter of observing what works in a particular situation. The reference that I was looking for talks about agile development and how easy it is to change code. He rightly said that selecting the text in the specification and hitting delete cost zero development dollars vs. actually having to change the code if that feature had been implemented. He also goes on to say that agile and more structured processes all have their place.

Still, regardless of the methodologies, you should still think through your solution. If you let your solutions "evolve" as you work through it, you're seriously in danger of missing the mark with the deliverable.

In response to Julio and optimization in general, it still goes back to rule #1. In Julio's situation, if the requirements were--or were likely to be--supporting large tables, then you need to plan for that (see rule #1). If you are storing entries in the fortune database, you probably don't. The key is, you know from the beginning which is the case.

"Code cleaning" is also a necessity that I stress to my teams (and did myself before I had teams). Yes, you risk introducing regression bugs, but if something is just wrong, and you would point it out in a code review as needing to be fixed, you should fix it then and there. This is another theme explored by Joel in Things You Should Never Do, Part 1, but that's at a different level; you're not rewriting the whole thing. It can even be down to formatting if code doesn't follow the agreed upon coding standards. This arguably doesn't change code, and, if you've unit and/or regression tests, you know you can make such changes without too much risk that changing something doesn' re-indroduce that really nasty bug reported by Phil in 1998. As Wil says, everyone wins.

Oops. Sorry, Wil. This got a lot longer than I intended. Good luck with the new venture.

Cheers,

ast

March 21, 2006 10:29 AM

 
Anonymous Anonymous said...

you're an idiot. no one can write bulletproof code the first time. you don't even understand the problem the first time.

April 09, 2006 9:27 AM

 
Anonymous F Cairo said...

You don't understand the problem the first time because you are not thinking enough. Coding will help you understand the solution more but don't mistake that for understanding the problem.

April 14, 2006 8:12 PM

 
Anonymous Anonymous said...

Cleaning code can have severe consequences. If you clean code it can lead to extra testing. It depends I suppose on your target application I work in Air Traffic Management and our testing to coding time is about 3 to 1 so if I spend a day cleaning code its 4 days potential cost on the project. Plus the time I have to spend explaining to safety engineers why something unexpected changed.

May 05, 2006 11:49 PM

 
Blogger Eric Blade said...

Let's think here...
"Mac OS 10.3, having lots of tooltips in a view that you remove and add back to a window a lot is EXTREMELY slow. "

Slow system. Slow tooltips, slow graphics subsystem, doing a slow operation "a lot". I can definitely predict that it would be slow!

I think the best tip I could give for optimization, is to learn exactly what parts of the language that you are working in are slower than others. Then you automatically know to use the faster methods. Like, in the language I am working in right now, ++a is faster than a++. And I know that, and use it wherever I would reflexively use a++ if i don't particularly care if A is incremented before or after. Also that multiplication, even by a float, is faster than division, even by an int. weird, but thats the way of hte language i am using.

June 14, 2006 7:43 AM

 
Anonymous adonis said...

Amen brotha Wil!

Less is more. Even in Unix :)

Erik: and if your code is riddled with ++a's and you decide to compile on another CPU or architecture that decides that ++a is slower?

You and others have apperently not read or understood the article: profile before you optimize. Of course you don't have to listen... but I'm sure you'll come to the same conclusion as the rest of us: "what goes around, comes around"

August 19, 2006 3:17 AM

 
Anonymous xyz3 said...

BEST CODE ADVICE EVER . Repost this every 6 months or so..

December 20, 2006 8:34 AM

 
Blogger Eridius said...

About half of your tips seem to come straight from XP. Which is probably a good thing.

December 20, 2006 11:30 PM

 
Blogger Wil Shipley said...

Well, many come from WIS and INT, as well.

December 21, 2006 1:42 AM

 
Anonymous Tarwn said...

Thinking ahead of time is mandatory. There is nor rule that says that putting a lot of thought in ahead of time requires a certain programming model or will result in a 200 page design specification that will be out of date the first time a customer changes their goals. Even with an Agile model, you should have at least a decent idea what objects or technologies you will need.
Not thinking ahead of time is the single largest cause of ugly design and ugly code that I have seen. I like the Samurai example. It may feel like your doing absolutely nothing for a period of time, but what is really occurring is your getting ready to expend yourself entirely towards the goal in a short burst. Compare this to the coder that puts little or no thought in ahead of time and just begins to type code. That code has a vague purpose and as functionality is needed extra chunks are added. this poorly planned code is almost always a mess, very difficult to understand after the fact, fragile, and a nightmare to maintain. And usually takes as long or longer to write and debug, it just feels faster because you code from day one to release day (and usually several months past).

I do agree that clean code should always be a goal. Clean and commented. Even if no one else will ever read your code, you will have to go back to it in 6 months or a year. Cleaner code means it takes less time for you to remember what you were doing. Clean, well-planned code also means that when you have to go back an add a feature, it is that much easier to understand everything and that much easier to understand the best method to add the feature.

December 21, 2006 5:31 AM

 
Blogger Gieno said...

Coding and coding,
testing and testing.
The boss is seeing,
the boss is smiling.
But we are sorrow.
sorrow?
Who can tell me why we are coding.

January 14, 2007 8:46 PM

 
Anonymous xtra said...

well... imo you can't call your self a programmer if you don't know that.

@gieno lol

June 08, 2007 6:32 AM

 
Blogger juananruiz said...

Thanks for this great and useful post. I have published a resumed translation to Spanish in my own blog (http://zumodewiki.wordpress.com) Hope it doesn´t bothers you.

August 03, 2007 3:38 PM

 
Blogger Lars said...

Yes, you're right down my alley. But sometimes I believe, that you actually have to learn it the hard way. Otherwise you want be able to grasp the importance of these tips ;)

October 22, 2007 5:05 AM

 
Blogger Marc said...

You are my long lost brother:

Confessions of a Terrible Programmer

Dinosaur Programmers Know More Than You

October 22, 2007 6:17 AM

 
Anonymous Anonymous said...

You know - I totally agree with all of this but, the last project I did we followed none of this, we did cowboy code meets blind cowboy on crack with an IQ deficit. The code for that project is appalling. It's a pain in the ass to maintain. We made millions off it. We coded it faster than any elegant, tdd, bdd, uber-agile project I've been on. We always sided with "barely good enough" and we were able to put something usable (if not ugly) out much faster because of that.

So - from a code perspective, yuck, from a typical startup perspective of "get big, get bought, move on", yum.

I still hate that it succeeded :)

October 22, 2007 12:31 PM

 
Anonymous Ptah Dunbar said...

the only point I'm not sure about is coding everything "clean" the first time around. Sure, your points are valid, but I find when programming the first "test" proof of concept or whatever, it's best just to get code down that works, then go through it again, learning from your mistakes, and doing it right the second time adding comments, the whole nine.

Also, after finishing up the first version, a better way almost always pops up in my head but hey, I'm still learning.

great article.

February 06, 2008 9:00 AM

 

Post a Comment

<< Home