Most Important To The Practical Programmer

[woodwardiocom]

Assume you are a computer programmer working in a real-world job. Which is most important?

A) Being able to write clear code that others can understand and work with.
B) Being good at interface design, so that the user can use the application easily.
C) Having read and understood most or all of Knuth's Art Of Computer Programming.

Comments

[caulay.livejournal.com]

D) Code that is unreadable and lacking comments, leading to job security.

[archangelbeth]

I vote for B and D, then -- unclear code that doesn't make the users happy is likely to be thrown out eventually, with poor references.

[klingonlandlady.livejournal.com]

I'd say A.
B is what interface designers are for, and you rarely have one person who's exceptional at both.

[fadethecat.livejournal.com]

I'm going to go with A for pretty much the same reason. Clear, well-documented code can get a good interface added by someone else much more easily than a glorious interface can have bad code beneath tidied up.

[mrw42.livejournal.com]

All of the above?

I'd say (B) was most important, except that I rarely design code that _has_ a user interface, in the sense that you probably mean. If I said (B), I'd more often be talking about well-designed, extensible protocols that embedded devices use to talk to other devices, or APIs that are used by others (often third-party developers) to access the capabilities of my product. If those would be covered in your definition of (B), then (B) is most important in my real-world job, IMO.

[tactical-grace.livejournal.com]

Depending on exactly what sort of software you are working on, Knuth may have limited value.

But if you can't write clear code, then you're a walking maintainability issue.

So I vote for (A). But they're all pretty damned important.

[woodwardiocom.livejournal.com]

Given that you're the first to say Knuth has value, could you elaborate on your feelings re: TAOCP?

[tactical-grace.livejournal.com]

(Not sure I'm the first, since the comment right above mine starts with the words 'All of the above'.)

Not Knuth specifically, but it's certainly an excellent repository of data structures and algorithms. You may learn what you need to know elsewhere, but there is a lot of value in those books.

I wouldn't say that I would expect a good programmer to have read or understood all or most of it, but I do think that you should have the capability of doing so -- if I tell you that I've implemented an AVL tree, you could do a lot worse than to look it up in Knuth if you don't know what an AVL tree is...

Knuth is a big toolbox, and if you have those tools at your disposal you are likely to be more effective.

[be-well-lowell.livejournal.com]

The "most or all" was the key phrase, I thought; I crack my copy of Knuth periodically, but the number of pages I've opened is pretty small.

Not that I'll be looking at it soon; I'm currently dealing with a processor that is incapable of looping...

[ceo]

A, absolutely. A crappy UI or inefficient algorithms over a clear and well-documented codebase are a lot easier to fix and maintain than an undocumented mess.

Unless, per mrw, you're talking APIs and protocols, in which case the interface is everything, because the second someone starts writing code to it, it can't be fixed.

[tk7602.livejournal.com]

Somewhere between A and B, depending on what exactly my role is.

For instance, I'm a sysadmin, and the code I write will never be seen by "end users", but will be worked with by other sysadmins. For me, A is most important.

If I was writing user facing code, I'd care more that it was easy and intuitive for the end users.

[dmmaus.livejournal.com]

In my job, it's (E) Get the code written as fast as possible so you can get experimental results completed. Documentation, maintainability, algorithmic efficiency, and UI are all secondary to that.

My job is not exactly a "computer programming" job though. For me, code is merely a tool used to do research, not something anyone else will ever use.

Having said that, I do place a high premium on documentation, because it helps when looking back on what I did a year ago. My code generally is about 40-50% comments.

[jeffrey cuscutis (from livejournal.com)]

A. Clear code will help the next coder as well as yourself when you look at the code months or years later.
Everywhere I have worked as a developer someone else designed the interface and the product was better for it.
Programmers are notoriously bad at UI.

Speaking as a guy who stopped coding about 15 years ago

[drwex]

A more or less presumes C, though few people actually read Knuth himself. The difference between a "guy who can bang out code" and a "programmer who can write clear understandable code" is some level of understanding of programming and software engineering. Knuth embodies a lot of that knowledge, but Knuth isn't the only way for someone to pick that knowledge up.

Finally I agree strongly with klingonlandlady that programmers and UI designers are different beasts with adjacent but not identical skill sets.