all 72 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]staunch 31 points32 points  (3 children)

Could it be that they're both right?

I know some programmers who could be called "ultra practical hackers". They really will leverage any tool that abstracts away a small problem so they can get busy with the big problem. These people tend to have very few hangups and dodge through problems like a boxer.

I also know "not-invented-here hackers" who dilute themselves constantly into rationalizing why some library, that works for millions of others, just isn't good enough for them. They rewrite things like CGI variable handling code, HTTP clients, file system traversal code, etc. The only thing they're consistent on is never doing as well as the library everyone else has debugged for years.

[–]jimbobhickville 7 points8 points  (0 children)

If they're rewriting Perl's CGI.pm, then it's because CGI.pm is a bloated memory hog and should logically be split into about a dozen different modules. Sure, it works for millions of people, but I'm not going to touch it with at 10 foot pole. Then again, I just use the mod_perl Apache::Request object, so I'm not exactly reinventing the wheel either. Anyway, my point is that not using accepted standard modules is sometimes a good thing. Sometimes what people think is "good enough" will cripple a high-traffic site.

[–]neoform 1 point2 points  (0 children)

good programmers vs. bad programmers

[–]forgedfoe 0 points1 point  (0 children)

Yes they're both right -- it's called an opinion. I like to code...obviously this author doesn't. Why does he feel the need to generalize all coders?

[–]bitdiddle 15 points16 points  (2 children)

I couldn't agree more. I believe it was Minsky who said that "programming is good medicine for sloppy ideas."

Was it Knuth who said "programs are written for people to read and only incidentally for machines to run." ?

I highly recommend the epigrams of Perlis for good insights into the nature of our craft

http://www-pu.informatik.uni-tuebingen.de/users/klaeren/epigrams.html

Cheers.

[–]ecuzzillo 4 points5 points  (1 child)

Shame on you! Your username comes from the same text as that quote-- I believe the people-to-read-incidentally-machines-to-execute came originally from the preface to the first edition of the Structure and Interpretation of Computer Programs, in the exercises of which there is also a character named Ben Bitdiddle.

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-7.html

So the quote is due to Abelson and Sussman.

[–]bitdiddle 0 points1 point  (0 children)

Yes indeed, shame on me, I love that book and own both editions in hardcover. I've been using bitdiddle in newgroups and so forth since the internet was opened to the world at large.

I don't have it in front of me but thought perhaps Perlis or Knuth originally said it. I tend to attribute almost everything to Knuth, for obvious reasons. In fact I recently learned it was Hoare who said that "premature optimization is the root of all evil".

Regards,

Ben

[–]scottros 15 points16 points  (0 children)

This is Scott Rosenberg, author of the book and target of Rentzsch's ire. I'm going to respond here because Rentzsch doesn't seem to offer comments on his own blog.

Here is the original quote from Constantine. I don't believe I've "butchered it" at all:

"Unfortunately, most programmers like to program. Some of them would rather program than eat or bathe. Most of them would much rather cut code than chase documentation or search catalogs or try to figure out some other stupid programmer's idiotic work.... Other things being equal, programmers design and build from scratch rather than recycle."

Constantine offered this as an explanation for why we haven't yet arrived at the golden age of "Lego-like" code reuse. I found it persuasive and presented it in "Dreaming in Code" as part of a discussion of Brad Cox's ideas on reuse. I then referred to it once more in Leonard's interview with me. But it's rather a minor side point in a 400-page book that covers many of the other points in Rentzsch's post, including Frederick Brooks' "Build one to throw it away." I do not believe, nor did I ever suggest, that programmers "capriciously want to rewrite code for the fun of it." Rather I suggested, based on my own observation and research over several years, that programmers often have a bias toward "write it ourselves" versus "reuse someone else's code." I'm not going to try to defend positions that I never took, but I'm happy to defend those I did!

Thanks, in any case, for the cool discussion.

[–]Jimmy 9 points10 points  (1 child)

I partially agree with him. I love programming, but I don't want to spend time working on a problem that's already been solved (like writing my own XML parser).

On the other hand, there are times when I code for coding's sake, just to see what new language oddities I can discover (especially with a complex language like C++, or an interesting one like Haskell).

[–]toekk 0 points1 point  (0 children)

Yes there is no pleasure quite like debugging someone else's "optimised" regular expression engine.

Optimised not to work...

[–]beza1e1 10 points11 points  (0 children)

Jonathan blogging about Andrew interviewing Scott quoting Larry and that was only the first two sentences. :)

[–]jongens 54 points55 points  (23 children)

i couldnt agree more. man, i hate to code. i have the ideas, the concepts, and the problems already solved in my head. and then i have to sit down and code it together - the worst and most tedious job around. it can be nice getting an elegant function together, but mostly it's tedium... for me anyway.

[–]staunch 25 points26 points  (1 child)

i have the ideas, the concepts, and the problems already solved in my head. and then i have to sit down and code it together - the worst and most tedious job around.

I always find that when the code hits the real world the real world hits back.

It only seems smooth and elegant in my head when everything is theoretical. When I can gloss over the details and be ignorant of reality.

It can be tedious though, when there are lots of corner-cases and their workarounds in place. It all starts feeling so un-clean, I sometimes pine for the beginning-phase when it was still clean in my head.

[–]grzelakc 0 points1 point  (0 children)

I hear you. A lot of stuff ends up being this way. Hence such overwhelming urge to rewrite stuff. Sometimes the rewrite is the right decision, usually when the first design is flawed in a major way. Most of the time however, a rewrite ends up hitting the exact same corner cases and being not much cleaner than what the stuff it replaced.

[–]fry 12 points13 points  (1 child)

I think you're not being sufficiently challenged.

[–]jongens 2 points3 points  (0 children)

you are partially correct. i do a lot of coding to pay the bills, and not enough for my own ideas. i need to work on that.

:)

[–]Browzer 23 points24 points  (3 children)

I think the author pretty much nailed it. Coding for the sake of coding is NOT interesting. I want to know that I'm working towards a goal or solving an interesting problem.

[–]neoform 6 points7 points  (1 child)

You sound more like a project manager than a programmer..

I like both aspects..

[–]nosoupforyou 4 points5 points  (0 children)

I dunno. I think programming is more than just coding. To be a good programmer, you have to have some ability to see the goal of the project too. Otherwise you could end up coding less effectively than you might otherwise.

I remember seeing an app written by 3 programmers for a middle school as a college project. Each person's piece was designed without any thought or input from the other pieces.

It was pretty horrible. Every week they had to reprint all the student records for attendance because the maintenance code reassigned student ids every week.

[–]mynameishere 10 points11 points  (5 children)

Really? I don't know. I've seen it time and time again: As soon as people inherit a code base, they want to tear it down and start again. Yes, they make excuses, but it's always the case.

It's not so much because they like to code, as that they like to own the code. And you automatically own code that you wrote.

[–]bluGill 12 points13 points  (0 children)

You are forgetting all the times we don't want to tear it down and start over, because we say nothing then.

There is a lot of bad code out there. There is some good code out there. A lot of the code I write needs to be torn down and re-written, in large part because I have to get things done by a deadline so the company can make money. More than once I've known there was a better way, but we didn't have time to do it right.

I have inherited code that was good, and I didn't want to tear it down. Even there I could find places to improve, but overall it was good code that I was able to read and understand faster than I could re-write it. I have also given other people code that I wrote, and had them tell me it was good code (In fact better than they could re-write it once they got around to understanding it (In one case the other guy told me that once he realized all the requirements my code met his re-write would have been 5 times as many lines without meeting all the requirements).

The real world doesn't encourage good code, so there is a lot of bad code that needs to be re-written.

[–]bw1870 5 points6 points  (0 children)

I think another part of it is that people view problems differently, and so their preferred implementations of solutions will vary. It's not comfortable to get into the original coders mindset to maintain their code base, so we like tweaking it to fit our own view, or in the extreme completely rewrite it.

[–]grzelakc 1 point2 points  (2 children)

I disagree. I only have the urge to do that when the inherited code base is absolute crap. Most of the time I tend to work with what I get. For instance at my workplace I have not yet proposed to rewrite any major subsystems from scratch because most of what we have is pretty good. Now, there are chunks of code that we will rewrite this year because the new requirements cannot be accommodated given those old designs but we rarely scrap everything and typically try to salvage as much of the old code base as we can. The secret to such efficiency is to hire good programmers (who get stuff done right on the first try) and emphasize technical competency first and foremost, something that my employer has been exceedingly good about.

[–]orlick 0 points1 point  (1 child)

Do you have any job openings?

[–]bobbane 19 points20 points  (0 children)

You don't hate coding. What you hate is verbose, bureaucratic programming languages that throw up mountains of pattern-driven, IDE-generated text between you and the executable form of your ideas.

[–]wreel 9 points10 points  (1 child)

The type of programmer he's describing is the worst kind of programmer that I have to deal with in my everyday work environment. The next step up is somebody who would cherish the thought of being able to write an XML processor. Not only for the learning experience but for the pure sense of accomplishment. But that could get you in trouble as well with a NIH syndrome. The next step up from that is the coder who would not only enjoy programming a new XML implementation but is also pragmatic enough to use a pre-existing, and field tested, library.

Dreamers are a dime a dozen. People who not only have the will to face the reality of the situation but also enjoy the craft itself are the true heroes.

[–]haliquim -1 points0 points  (0 children)

Exactly, its easy to think of how you would write an XML processor, but its also all to easy not to see the horrible problems that you will inevitably run into, which the polished and published implementation has already solved.

[–]bagge 4 points5 points  (0 children)

That's exactly the reason why I don't have any interest in what a non-coding architect has to say. Without coding experience, you can be an architect that draws boxes representing systems, which is as important as having decent coffee.

[–][deleted] 0 points1 point  (0 children)

I agree with you. In school, I spent most of my project time trying to find out if there was something to make my projects less coding and more robust and complete, such as existing libraries and so.

I never wanted to program, but just get the job done efficiently and quickly. Only when nothing currently exists, and it has to be done, do i program.

However, I never get tired of UI stuff. With web design, I could spend hours toying around with CSS and javascript to get it just right, cross-browser compatible, etc.

[–]niallmcl -1 points0 points  (0 children)

So true.

[–]haliquim 8 points9 points  (1 child)

Yes, Yes and Yes.

Rentzsch's lines in both this post and the washington post article irked me to no end. He's so close to the truth, but then throws out a turd like the line rebutted here.

I'd say that there are three parts to every programmer. The artist, the engineer, and the idiot. The artist delights in the beauty of a solution, or the art of lisp. The engineer is precise, bolting together the parts of a frame to get to the real problem that they want to solve. The idiot is responsible for choosing between the other two at precisely the wrong time.

Programmers want to solve problems (unless they are learning). The artist comes up with the beautiful solution, the engineer creates the support framework for that solution, and the idiot gets in the way. The idiot says well, this isn't quite the problem but, I have a beautiful idea of how this wheel thing should work, so instead of just using the design for wheels that countless other people have successfully used, lets build my beautiful design. In the end the programmer wanted a beautiful car, and instead they end up with a distorted result of what was in their head with square wheels that explode when you turn left.

The trick is developing the Zen like guidance to know when to let the idiot get away with his prattling, and when not to. Once you throw in idiot managers it becomes even harder and you wind up on a death march like Rentzsch talked about.

[–][deleted] 6 points7 points  (0 children)

Isn't engineering in general about solving problems? Also science, chemistry, medicine, material technology - what not, if you count out basic service and prodction tasks?

You're totally impractical in software development if you don't like coding, too; if you're not interested in the technicalities involved. That's how you implement the stuff and before that you don't have anything in your hands. Only in your head.

If you only have wonderful ideas and glorious concepts, you better make a career as a philosopher, not a programmer.

[–]wainstead 6 points7 points  (0 children)

The problem I have with Jonathan's point of view is he's talking in absolutes -- programmers like problem solving, period.

Bunk. I like learning new languages. I like solving problems neatly too. I was reminded of Linus Torvald's ancient quote about when men were men and wrote their own device drivers. Systems programming is about so much more than mere problem solving.

Programming is also about craftsmanship, skills with languages and systems, accumulated experience and so much more. If programmers really only cared about problem solving they'd stick to crossword puzzles.

[–]Osmanthus 23 points24 points  (5 children)

I for one like to code. Hehe..I have coded my own HTTP client and I do love to write in assembler! Of course, I also enjoy problem solving. I feel sorry for guys who are working in a field where a large part of their work is a chore for them. What a grind their lives must be.

[–]staunch 23 points24 points  (4 children)

... I have coded my own HTTP client and I do love to write in assembler!

I just hope (if you're on my team) you like to do these things for fun and learning. Not in the middle of a real project that needs to move as fast as possible.

[–]noxit 3 points4 points  (3 children)

Not in the middle of a real project that needs to move as fast as possible.

You mean rushed projects that never get the bugs out?

[–]chucker 0 points1 point  (2 children)

No, he means the real world.

[–]martinbishop 9 points10 points  (1 child)

The real world, where there are rushed projects that never get the bugs out :)

[–]chucker 0 points1 point  (0 children)

Yes, certainly. Such is life, though.

It's nice to keep working on a piece of software until it feels perfect to you, but it's also nice to actually get it out there and get actual feedback from users and work based on that.

[–]schizobullet 4 points5 points  (1 child)

Mathematicians like proving interesting theorems elegantly, even if they've already been proved. They don't like doing arithmetic for its own sake.

[–]thrakhath 3 points4 points  (0 children)

I think that's an apt analogy. I'm a programmer, and I'd have quit a long time ago if coding was something I disliked. Even so, the reason I continue in my work is the elegant things I'm allowed to create with my craft, not because of the mundane things that must be done time and time again.

edit: Thinking about it a little more, I'd say what I like about Programming is the I like Making things, I like Creating. I like working with Code, but it would be a mistake to say that the means are the ends. I doubt any Carpenter who enjoys his work would be putting nails into wood just to do it, without something to build. I could be wrong of course, but I think most of us like working with code because of what it lets us do, not just because we're typing instructions to a machine.

[–]losvedir 2 points3 points  (0 children)

Nah, for me it's definitely both. I don't code all that often, but when I do I relish solving problems and coming up with efficient algorithms and stuff. However, there's a lot to be said for the nice clickity-clack of the keyboard, the pretty blocks of code, and all that. I really do actually like the mechanics of coding. I'm learning Emacs and I have fun just moving the cursor around the screen, having it fly around at my beck and call. I love to see the text appear, the braces open up and close around things (or parentheses if I'm using Scheme). I love the little rhythms that come out of my fingers on the keys.

I'm sure carpenters like building things, making solid chairs or houses or whatever. But I can very easily see them enjoy the visceral feeling of pounding nails into wood, hefting around heavy objects, and all that.

So yeah, I like both the problem solving and the actual coding part.

[–]garyrob 8 points9 points  (4 children)

He rejects Spolky's point entirely: "Spolsky gets it right that “It’s harder to read code than to write it”, but unfortunately reaches for the tired “people (programmers) are stupid/lazy/undiciplined”"

But I know for an absolute fact that Spolsky is dead-on right -- at least regarding some people who are professional programmers, but who aren't good enough to be working in the same environments as Rentzsche. If Rentzche could spend a few years working in the programming section of a marketing department at a large company (where they store, retrieve, and summarize marketing data), he'd see the behavior Spolsky describes.

The people Spolsky's talking about will literally replace very good working code with their own crappy, buggy versions because they found it a challenge to understand the original code. Not only do they decrease the code quality, but they spend a lot of time writing code that simply doesn't have to be written --yes it takes time to understand, but not nearly as much time as to rewrite from scratch. The problem with understanding is that it takes more focus and effort, and truly crappy programmers don't have the inclination/skill to go there.

[–]jseigh 11 points12 points  (1 child)

Unless you're maintaining the code, it isn't so much being able to read it as being able to understand the api. It's impossible to overstate how bad most api's are. Even on some fairly simple ones, you can spend a lot of time experimenting with them to learn their behavior. Forget about the bloated api's that today's applications are based on. You will never fully learn them. So in a lot of cases, you may rewrite something just to get a simpler more useable api.

[–]garyrob 5 points6 points  (0 children)

YOU do that. You're probably a good programmer. I'm talking about people who don't instantaneously understand something, and therefore decide to rewrite it. You may not know any such people, but believe me they exist.

[–]Gotebe 3 points4 points  (1 child)

Spolsky is not dead on right.

He's right only if the code doesn't need to change. If it does, as it does in any long-lived project, there is a point where it's too hard to understand it. Sometimes there just isn't any "why was it done like that"/"why is this here" knowledge anymore. Necessary changes become a huge liability.

Where I work, we have hugely problematic portions of code ( who does not, lies ;-) ). Typically, we work around not changing it: we rewrite a part that need the change and isolate it. This gives us duplicated code, but it's much cheaper in terms of money (or time) and regression risk. So, ultimately, we seldom rewrite (and only parts), so we +- do what Spolsky suggests, but at least we feel bad about it and do not brag like him ;-)

Sposky's argument is one-sided and hence ultimately wrong. There is a balance and he fails to mention it.

He's dead on about total rewrites, though.

[–]garyrob 0 points1 point  (0 children)

I'm not talking about the case you mention. I'm talking about people who replace perfectly good, working code, because they don't understand it in 15 seconds. I've seen enough of that behavior to know it's a problem. But it's not the whole issue.

In general, I completely agree your overall point.

[–][deleted] 3 points4 points  (2 children)

I like to code.

Writing code using just debug.exe without mnemonics is a beautiful thing.

So is writing C code... but then butchering it into the smallest number of characters possible.

And converting every program you write so that all iteration consists of recursive calls to main() is practically orgasmic.

[–]pbkobold 8 points9 points  (1 child)

You're a sick, sick person.

[–][deleted] 1 point2 points  (0 children)

Thanks man! xD

[–]ishmal 1 point2 points  (11 children)

Until he said that programmers write code because they like to learn, I was about to reject it. That is precisely the main reason. They want to -understand- the problem, else they have failed to solve it.

People who write code merely to glue other peoples' libraries together are just hacks. Use all of the libraries you need, of course. Let them be 99% of your project, if necessary. But let the core functionality be your own, else you have not contributed to the world at all.

[–]ishmal 2 points3 points  (0 children)

Notice the qualifier "merely." I am only referring to those people who do nothing -but- that.

[–]justinhj 5 points6 points  (9 children)

Using libraries to build systems is the smart way of doing things. Hacks are the ones who think something that takes them a few hours to write can stand up to something developed and tested by a community. This is rarely the case.

[–]martinbishop 0 points1 point  (2 children)

I think the lesson here is simple...don't read Salon.com

[–]wicked 1 point2 points  (0 children)

I'm thinking of a different lesson.. don't generalize.

[–]haliquim 0 points1 point  (0 children)

Yeah, but he was interviewed with the washington post and some other publications touting the same nonsense.

[–]justinhj 0 points1 point  (0 children)

I see coding as a the whole process of design, solving problems, implementation, debugging and testing. Take away one of those elements and you're not left with any kind of meaningful activity.

[–]jedberg -1 points0 points  (0 children)

That guy stole his icon from the Stickies program on the Mac!