Coders At Work

Vladimir Sedach writes "Aside from authoring narrowly focused technical books, teaching university courses, or mentoring others in the workplace, programmers don't often get a chance to pass on the knowledge of the practise of programming as a profession. Peter Seibel's Coders at Work takes fifteen world-class programmers and distills their wisdom into a book of interviews with each of them." Keep reading for Vladimir's review. Coders at Work author Peter Seibel pages 632 publisher Apress rating 8 reviewer Vladimir Sedach ISBN 978-1430219484 summary How the best programmers in the world do their job The list of coders interviewed includes some geek household names like Donald Knuth and jwz, but also some not so well-known ones such as Bernie Cosell (one of the programmers behind the ARPANET IMP, the first Internet router) and Fran Allen (compiler pioneer). The full list of people interviewed is available on the book's website. The eras embodied by the interviewees range from the very beginnings of software as we know it today, to the heyday of the Internet boom, when people like Brad Fitzpatrick made their mark.

Seibel himself is a coder and author (having the well-received Practical Common Lisp under his belt). It is then no surprise that the interviews are packed with technical details, which (with one exception, explained below) restricts the intended audience of the book to those already familiar with programming.

Coders at Work manages to communicate the wisdom of programmers of bygone eras, while simultaneously being heavily colored by very contemporary issues. JavaScript, its consequences and its discontents, is a topic recurring throughout the book. More than just a recounting of history, Coders at Work should inspire readers to learn about the wider context of their craft and stop the reinvention of the proverbial wheel decried by several of the interviewees in its pages.

Given the related subject matter, the people interviewed in Coders at Work who played a role in creating major programming languages (Armstrong, Eich, and Steele), and close publication dates of the two books, inevitable comparisons will be drawn between Coders at Work and Federico Biancuzzi and Shane Warden's Masterminds of Programming (I previously reviewed Masterminds of Programming on my blog). There is a lot of common ground between the two books in terms of technical areas covered, but Coders at Work clearly comes out on top.

Part of the reason has to do with the fact that Seibel's choice of interviewees is stellar. Masterminds of Programming's niche focus on programming language designers meant that its authors had a tougher job than Seibel, but details like the omission of Alan Kay (creator of Smalltalk and one of the most influential programming language designers in the field's history) from Masterminds are nothing short of dumbfounding.

Just as important to making Coders at Work a good book is the fact that Seibel is a great interviewer. Seibel's questions felt more open-ended than those in Masterminds, and the resulting interviews have a flow and narrative that makes them engrossing to read and gives the programmers interviewed a chance to explore details in-depth.

A refreshing aspect of Coders at Work are the interviewees who don't shy away from strong opinions or humor, as shown in this remark by Peter Deutsch, "I think Larry Wall has a lot of nerve talking about language design--Perl is an abomination as a language." One aspect where Coders unintentionally shines is as a guide to finding and hiring programming talent. Even non-technical managers will benefit greatly by reading those excerpts of the interviews concerned with hiring programmers.

Another unexpected aspect of the book is the breadth of topics discussed — everything from debugging machine code to women's issues in computing workplace and education.

One area where Coders could stand improvement is in its length. Not all of the coders interviewed possessed the gift of brevity, and many interview answers could have been edited to reduce their length without affecting the message.

In her interview, Fran Allen makes an interesting assertion — programming and computer science need to become more socially relevant. Other scientific and engineering fields are filled with well-known personalities, described in prominent interviews, biographies, and major Hollywood films. The only "software people" to appear in the public spotlight are the CEOs of major software firms. Ultimately, its role in helping programming assert its status as a socially relevant profession may be the most important contribution of Coders at Work.

You can purchase Coders at Work from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Microserfs

[proslack]

I still think "Microserfs" is the best book about coders, ever. I worked as a programmer in Seattle for a year back in the late 90's and it was pretty much dead on.

Re:Microserfs

[micromuncher]

Nah, Death March by Yourdon. I re-read it frequently and it never loses its luster.

Re:Microserfs

[mweather]

You think companies spent billions fixing Y2K bugs even though nothing bad was going to happen?

Re:Microserfs

[eln]

There was undeniably a lot of hyperbole, but I would argue at least some of that was necessary to get the powers that be to pay attention and actually commit to solving the problem. After billions of dollars and countless man hours, we managed to largely avert the problem. So, rather than going around telling everyone that Y2K was a hoax, it would be much more accurate to go around congratulating all of the thousands of programmers who worked around the clock for more than a year to make sure Y2K didn't live up to the hype.

Re:Microserfs

[RetroGeek]

The look of disappointment on the faces of the major news anchors was priceless and underscored their severe lack of understanding of technology.

It was if someone had said that a bridge needs repairs (the experts can see the rot), the billions were spent fixing the bridge and when the first person crossed the bridge it did not collapse. Then they whine that there is no sensational story, that the bridge would not have fallen anyway and why was the money spent, what a waste?

I hate news people. I find them shallow, news bite hunting morons.

Re:Microserfs

[rider_prider]

The problems due to y2k were for the most part well understood and easily fixed. Also even if left unfixed they could not possibly have caused a meltdown of our society. The main thing we should have learned from y2k was we should avoid the massive overstatement of the risk and just plain fabrication that went on in the lead up to the big day. As we can see from today's media that is no longer a problem,...

Re:Microserfs

[Anonymous Coward]

YES! That's exactly how corp culture works. The shareholders don't make decisions... it's the folks whose compensation/position depends on how much money flows through their department that make decisions---most huge corps have these very expensive projects of no particular use to anyone.

Re:Microserfs

[sbeckstead]

Oh kind of like the calendar ending in 2012, the one the Mayans just didn't bother to update past that point?

Re:Microserfs

[umghhh]

This is of course not to say that negative result of a search is something to snare upon as it provided some certainty instead of hope only but how serious these bugs were and why we have not seen much slipping trough these bug catching parties as it could be expected from any software enterprise? I mean there is no ideal tester so something gets always true.

Re:Microserfs

[Samgilljoy]

While criticizing the media for its usual stupidity, we shouldn't forget the equally stereotypical self-aggrandizement of hordes of old programmers who claimed they foresaw the problem way back in 197X and how no one would listen to them.

I can't tell you how many gray-haired Cobol programmers tried to make themselves out to be prophetic heroes in last few years before 2000.

The lesson to be learned? Most people are idiots, and the rest of us are somebody's idiot at least some of the time.

Re:Microserfs

[Opportunist]

How much money do you think is spent despite knowing that it's an utter waste of time and resources, for the only reason to limit liability? All that matters is that you did what you could so you cannot be sued for neglect.

Re:Microserfs

[Anonymous Coward]

I hate news consumerists. I find them shallow, news bite hunting morons.

Coders that work?

[Anonymous Coward]

Coders that work?

Re:Coders that work?

[Anonymous Coward]

by "work" they must mean reading slashdot all day.

Re:Coders that work?

[sep0209]

Depends on the time zone, Bubba.

Re:Coders that work?

[mh1997]

From the summary "Aside from authoring narrowly focused technical books....Peter Seibel's Coders at Work takes fifteen world-class programmers and distills their wisdom into a book."

So, instead of writing a narrowly focused technical book, they wrote a narrowly focused technical book?

Re:Coders that work?

[Anonymous Coward]

As long as we are talking about technical books, a book aimed at every computer programmer ever is not narrowly focused.

Women's issues in computing workplace

[Dystopian Rebel]

I know I am not alone in deploring the puerile comments and immature attitudes of male programmers.

In every computing workplace where I have worked, men have behaved like sex-crazed animals and women have *never* felt comfortable working topless.

Re:Women's issues in computing workplace

[Anonymous Coward]

Brilliant.

Re:Women's issues in computing workplace

[Matheus]

Curious: What employer asked/required you to work topless? ...and where might I submit my application?

Re:Women's issues in computing workplace

[Swizec]

women have *never* felt comfortable working topless.

But I thought it helps you concentrate when we can see your bewbs O.o

Re:Women's issues in computing workplace

[Anonymous Coward]

We'll get to that in a minute. First, What's your cup size?

Re:Women's issues in computing workplace

[masmullin]

are you sure? there are sure to be a lot of fat pasty white male nerds going topless too... you might never again be able to achieve an erection!

Re:Women's issues in computing workplace

[WilyCoder]

I'll grunt to that.

Now where are the topless pics?

Re:Women's issues in computing workplace

[Anonymous Coward]

We'll get to that in a minute. First, What's your cup size?

34D. Suck it. (not literally)

Re:Women's issues in computing workplace

[Anonymous Coward]

That's too bad!

Re:Women's issues in computing workplace

[Rastl]

And who's fault is that? If you didn't set the damn air conditioning at 'sub zero' then maybe we would stop poking the menu options on the monitor, making us less efficient.

Quite frankly, the temperature thing doesn't help you either. Think about it.

Re:Women's issues in computing workplace

[Fulcrum of Evil]

women have *never* felt comfortable working topless.

Why would you? All I can think of is nudie bars, and no, the bartender doesn't write code.

Re:Women's issues in computing workplace

[auLucifer]

Lack of bra . $0
Glass office for all to see in . $10,000
Woman is approached less due to coder geeks fear of naked breasts . priceless

Re:Women's issues in computing workplace

[Velex]

Haha, fuck you bitch.

That is all. Thank you.

Re:Women's issues in computing workplace

[Anonymous Coward]

First, if you're a woman, what's your cup size?

there, fixed that for you

Re:Women's issues in computing workplace

[apoc.famine]

My powers of repression and selective memory are pretty impressive. I've seen goatse, and still manage to live a pretty good semblance of a normal life.

Re:Women's issues in computing workplace

[clickclickdrone]

>First, What's your cup size?
Depends, Latte or black Americano?

Re:Women's issues in computing workplace

[cerberusss]

I know I am not alone in deploring the puerile comments and immature attitudes of male programmers.

In every computing workplace where I have worked, men have behaved like sex-crazed animals and women have *never* felt comfortable working topless.

I'm male and I have the same issues. I best code pantless, but the team of female kernel hackers down the hall will harass me to no end when all I want is to fetch a cup of coffee and finish this damn script.

Re:Women's issues in computing workplace

[badkarmadayaccount]

Try getting some real baggie pajamas and no underwear underneath. Pretty much the same effect.

Re:Women's issues in computing workplace

[Anonymous Coward]

women have *never* felt comfortable working topless.

But I thought it helps you concentrate when we can see your bewbs O.o

your right bewb is significantly larger than the left

Coding philosophy book: Writing Solid Code (1993)

[davidwr]

I found Writing Solid Code (Maguire, 1993) worth the read. Sure, some of what's in there is dated but many of the concepts are timeless and part of today's conventional wisdom.

Things like coding for security, coding for readability/maintenance, etc. etc.

Granted, those concepts weren't new in 1993 either, but many in the generation of programmers that cut their teeth on Turbo Pascal and 8-bit-machine BASIC never learned the lessons from 1960s mainframe code jockeys.

Useless book.

[140Mandak262Jamuna]

It does not mention me or Steven Colbert.

Re:Useless book.

[_PimpDaddy7_]

Who the hell are you?

Re:Useless book.

[idontgno]

Judging from the construction of his statement*, not Steven Colbert. That narrows it down a bit.

*My evidence? The use of the "or" conjunction, which in English is semantically equivalent to a logical XOR.

Re:Useless book.

[bencoder]

*My evidence? The use of the "or" conjunction, which in English is semantically equivalent to a logical XOR.

That would only narrow it down if Steven Colbert actually WAS mentioned in the book. Anyone got the book to check it out?

Re:Useless book.

[jo42]

A reject from Digg.

Re:Useless book.

[Anonymous Coward]

No. If `me' is Steven Colbert then if it would have mentioned Steven it would also have mentioned me. Look at $me like a reference to $Steven_Colbert.

$me == $Steven_Colbert

Re:Useless book.

[zindorsky]

The use of the "or" conjunction, which in English is semantically equivalent to a logical XOR.

_Usually_ equivalent to XOR. Consider the following statement:

"It will rain today or tomorrow".

If, in fact, it rained today _and_ tomorrow, would you consider the statement false? Most people wouldn't. Therefore, in that particular case, English "or" is equivalent to logical OR not XOR.

Re:Useless book.

[Dragonslicer]

Judging from the construction of his statement*, not Steven Colbert.

The fact that he spelled "Stephen" incorrectly might be a hint, too.

Does this complement "Code Complete"

[line-bundle]

How does the info in this book compare to Code Complete (2)?

Re:Does this complement "Code Complete"

[vsedach]

Code Complete obviously has a lot more technical details in its advice on writing code. A lot of them are very specific to C/C++. A lot of them should be obvious. Coders at Work has a lot more general guidance that can be applied in any programming setting, and more importantly they're put into better context so you can kind of get why people recommend doing what they recommend. Code Complete is not that great at explaining "why." I think both are worth reading.

So what will they do?

[Anonymous Coward]

"Aside from authoring narrowly focused technical books, teaching university courses, or mentoring others in the workplace, programmers don't often get a chance to pass on the knowledge of the practise of programming as a profession."

Then they author another narrowly focused and self-centered book?

Andy Hertzfeld...

[sycodon]

... is not interviewed.

WTF?

Re:Andy Hertzfeld...

[DustCollector]

You'll find him in "Programmers At Work" by Susan Lammers. That book was published by Microsoft Press back in 1986.

ah yes, anti-perl tirades are refreshing

[doom]

A refreshing aspect of Coders at Work are the interviewees who don't shy away from strong opinions or humor, as shown in this remark by Peter Deutsch, "I think Larry Wall has a lot of nerve talking about language design--Perl is an abomination as a language."

Yes, it must be refreshing all right, listening to aging Computer "Scientists" reciting crap that's been stale for years. It certainly is courageous for an ACM member to continue the smear campaign against perl. His friends in the gentleman's club will be shocked at his outspokeness.

You might think that the obvious utility of perl, the fact that perl and perl derived languages remain tremendously popular with people writing actual code, might blunt the man's opinion that it's an "abomination". Is it at all possible that Larry Wall got a few things right, and that the CS field's decades-long obsession with elegance and reductionism was somewhat misplaced?

(And if you want to take the line that the CS attitude is correct, how would you prove that it's correct? Writing working code is evidently not relevant. And if you can't prove it, then what does the "S" stand for in "CS"?)

Re:ah yes, anti-perl tirades are refreshing

[wurp]

In general, I agree with you. To nitpick, though...

Proving things is the domain of math, not science. In science, you can only find models which aren't disproven in a particular domain or by the body of experimental data. You can't prove your model is correct.

And the only reason you can do it in math is because you get to choose the assumptions and assume they're absolutely true.

Re:ah yes, anti-perl tirades are refreshing

[Anonymous Coward]

Anything with "science" in the title, isn't.

Re:ah yes, anti-perl tirades are refreshing

[Anonymous Coward]

It certainly is courageous for an ACM member to continue the smear campaign against perl
 

What have they got against perl? She's just a singer ... and she sings songs for the lost and lonely ... which is a fair description of Slashdotters.

Re:ah yes, anti-perl tirades are refreshing

[pileated]

I was looking forward to reading this book based on the thread above. But you're right, Peter Deutsch's comment about perl is less refeshing than asinine. I'd love to see a thoughtful analysis of perl compared to other languages, because sometimes, even though it's the language I use most frequently, it drives me nuts. But calling it 'an abomination' doesn't quite qualify as thoughtful analysis. And it certainly doesn't consider that it must be doing something right to still be used in so much functioning code.

As essay or two on elegance and reductionism versus practicality would be nice to see in the book.

Re:ah yes, anti-perl tirades are refreshing

[RightSaidFred99]

As a language it is an abomination. As a tool used for its intended purpose it's a masterpiece.

Re:ah yes, anti-perl tirades are refreshing

[Anonymous Coward]

With a randomized experiment, you can prove a causal model within a probabilistic system (i.e., to any degree of belief you want, with enough data). I guess it depends on what you mean by "prove". Your view is a rather shallow one in my opinion (any many other philosphers and scientists).

Re:ah yes, anti-perl tirades are refreshing

[steelfood]

The thing is, from an application standpoint, I wouldn't consider perl a programming language. To me, it's an advanced scripting langauge. And it does that really, really well. But as a programming language, it isn't exactly the best.

Re:ah yes, anti-perl tirades are refreshing

[Tetsujin]

(And if you want to take the line that the CS attitude is correct, how would you prove that it's correct? Writing working code is evidently not relevant. And if you can't prove it, then what does the "S" stand for in "CS"?)

Hal Abelson says Computer Science isn't really a Science, nor is it about Computers. It's more like magic!

As for Perl... Whether or not people have said bad things about Perl before, whether or not people do good work in Perl, I can't find fault in anyone who feels it's still worth mentioning that Perl is a horrible jumble of a computer language.

Re:ah yes, anti-perl tirades are refreshing

[VirginMary]

If the popularity of a programming language were a sign of it being a "good" language, then how come there is so much COBOL and FORTRAN? This reminds me of an old saying: "Eat shit, 10 billion flies can't be wrong!" I'd also like to point out that most programmers are hacks. I don't doubt that languages like Perl are useful for small scripts but I think it is not a language that scales up very well. Google for example uses C++ and Python and they try really hard to hire only the best programmers they can find. Many languages are culturally assimilated. I come from a physics background and most physicists used to, and may still, program in FORTRAN, yet FORTRAN is a terrible programming language. But guess what, if challenged on this, most physicist programmers might have replied that they can readily solve any problem of interest to them in it. I'm sure the same is true of the armies of Perl programmers. But, using the popularity of anything as a measure of its quality is questionable.

Re:ah yes, anti-perl tirades are refreshing

[mbkennel]

Fortran, as in am modern Fortran like Fortran 95, is [b]not[/b] a terrible programming language for physics problems.

For some of those problems, it's better than almost all alternatives. I like it much much better than perl.

It's suited to its domain at least as well, and is far less idiosyncratic.

Re:ah yes, anti-perl tirades are refreshing

[Fulcrum of Evil]

You might think that the obvious utility of perl, the fact that perl and perl derived languages remain tremendously popular with people writing actual code, might blunt the man's opinion that it's an "abomination".

Excuse me, but why can't it be both? It's nasty, but it works for a lot of things. That said, python does what perl does with easier syntax, so I'll be using that.

Re:ah yes, anti-perl tirades are refreshing

[Grishnakh]

It kinda reminds me of the English language.

Re:ah yes, anti-perl tirades are refreshing

[Grishnakh]

But, using the popularity of anything as a measure of its quality is questionable.

Yes, but the popularity of something can absolutely be used as a measure of its utility.

The reason for something being popular may be nothing more than an accident of history, but because it's popular, it's useful in ways that something obscure cannot be.

Re:ah yes, anti-perl tirades are refreshing

[Grishnakh]

As for Perl... Whether or not people have said bad things about Perl before, whether or not people do good work in Perl, I can't find fault in anyone who feels it's still worth mentioning that Perl is a horrible jumble of a computer language.

People do lots of good work in English too, including writing computer code (all the syntax, keywords, etc. are in English), doing aviation, and many other thing. But English is a horrible jumble of a language.

Re:ah yes, anti-perl tirades are refreshing

[pileated]

Not trying to be sarcastic here but let me try to get straight what you are saying:

1)Application standpoint -> Perl's bad
2)Programming language -> Perl's bad
3)Advanced scripting language -> Perl does that really, really well.

So I assume that 1 and 2 are more or less the same. Programming languages are used for applications and Perl is not a real programming language and thus bad for building applications. Not trying to put words in your mouth here but just making sure I understand you.

On the other hand Perl is great at advanced scripting.

Don't you think that the line between advanced scripting and an 'application' can sometimes be very thin? Do you see them always as very far apart?

What do you think about what seems to be the rising popularity of scripting languages? Is it possible that some users think that programming languages for applications might be beautiful but aren't always as practical as advanced scripting languages? I realize I could be wrong about the 'rising popularity' of scripting languages. It's based more on what I read than on actual experience. Still it does at least look like there is a trend towards dynamic scripting languages.

Re:ah yes, anti-perl tirades are refreshing

[Dragonslicer]

I come from a physics background and most physicists used to, and may still, program in FORTRAN, yet FORTRAN is a terrible programming language.

They use Fortran because the language is designed and optimized to be the best language at what physicists and other physical scientists most often need it do: crunch a whole lot of numbers. I wouldn't use Fortran to make a word processor or web browser, but if you need a program to spend two weeks doing a lot of math, you just can't beat it.

Re:ah yes, anti-perl tirades are refreshing

[Rising Ape]

I come from a physics background and most physicists used to, and may still, program in FORTRAN, yet FORTRAN is a terrible programming language.

Ah yes, but in fairness most physicists are terrible programmers :) I'm not excluding myself either, but it stands to reason that someone who uses programming as just one of a multitude of tools to do their job won't be as good at it as someone who's job *is* programming.

Fortran has the virtue of being simple - certainly compared to C++, which has replaced it, at least in particle physics. It's thus less likely that a non-professional programmer will shoot themselves in the foot.

Re:ah yes, anti-perl tirades are refreshing

[Tetsujin]

As for Perl... Whether or not people have said bad things about Perl before, whether or not people do good work in Perl, I can't find fault in anyone who feels it's still worth mentioning that Perl is a horrible jumble of a computer language.

People do lots of good work in English too, including writing computer code (all the syntax, keywords, etc. are in English), doing aviation, and many other thing. But English is a horrible jumble of a language.

See? That's exactly what I'm talking about. That there is a fair criticism.

Re:ah yes, anti-perl tirades are refreshing

[VirginMary]

> They use Fortran because the language is designed and optimized to be the best language at what physicists and > other physical scientists most often need it do: crunch a whole lot of numbers. I wouldn't use Fortran to make > a word processor or web browser, but if you need a program to spend two weeks doing a lot of math, you just
> can't beat it.

I'd strongly disagree with your statement. I have written plenty of numerical code in C++ and I claim that it is a better language for writing numerical code. Also I have taught FORTRAN at an engineering school and consulted engineers and scientists in programming (primarily in FORTRAN) at a major university for several years and I would say that any programming language has been "designed" to some degree but FORTRAN is certainly one of the weaker efforts. Every statement type in FORTRAN looks like it is a separate language. Most of its practitioners don't even bother to learn the full language and the language is so weak that every vendor felt compelled to add lots of extensions to the core language. The only really strong reason for using it is the availability of huge numerical libraries that have been thoroughly debugged. I would admit that that is a pretty good reason. Another might be that FORTRAN vendors have put a lot of effort into optimising loops etc. This has nothing to do with the language itself and could equally be done in many other languages.

Re:ah yes, anti-perl tirades are refreshing

[VirginMary]

I would agree with you that FORTRAN is significantly simpler than C++. On the other hand, FORTRAN-77 for example was significantly more complex than C, if you take the language descriptions as the measure of comparison. And yet back when I had to deal with these languages almost no scientist nor engineer was willing to give C a chance. C++ is harsh for casual users. One of it's advantages is that you can create classes that make the solution of certain types of numerical problems fairly simple and intuitive. For the casual scientist or engineer programmer, I'd recommend Python. Unless you need very high performance, that is.

Re:ah yes, anti-perl tirades are refreshing

[VirginMary]

The reason for something being popular may be nothing more than an accident of history, but because it's popular, it's useful in ways that something obscure cannot be.

I don't see how that follows in every case. If you mean, for example, that there is more documentation available and you can ask more people for help with a popular language than an obscure one, you are correct. On the other hand, I believe that using the wrong or at least suboptimal tool for a job will cost you big time long term. And there are certainly well supported and documented alternatives to Perl, like Python for example. For many years I observed colleagues around me flailing around in FORTRAN because they refused to use what was an obscure tool, "C", in their community at the time. That's because FORTRAN "got the job done" and everybody else was using it, too. Today I am convinced that the world of software development would gain an order of magnitude in time-to-product efficiency if most of us programmers used some object-oriented flavour of Lisp.

Re:ah yes, anti-perl tirades are refreshing

[Grishnakh]

It doesn't follow in EVERY case, it's just a general statement I made up and I think to be true in many cases.

For instance, some CS people might claim that Plan9 (or insert other favorite, but highly obscure and unpopular OS here) is the best OS in existence. Well, maybe technically it is, I don't know. However, if I want to do useful work on a computer, like buying something online, playing an MP3, desigining a PCB, or whatever, Plan9 may very well not allow me to do some or all of those because it simply doesn't support the software needed to do so, whereas with Linux I can just download a distro for free, install it and the software packages to do what I want, and get to work. (Or, with Windows, I could buy it, install it, buy the software I need to do those things, and get to work.) With Plan9, I might very well have to figure out how to port my favorite software to that OS, if that's even possible and the source code available.

Or, for a transportation analogy: someone might claim that some railway locomotive X is the "best", although it has a track width of 6 feet. Well, that's great, but since all the railroads in the USA (and much of the world) have a track width of 4'5.5", it's completely useless for actually transporting cargo compared to locomotive Y which uses the standard gauge. This person might argue endlessly about how standard gauge is too narrow, and 6 feet is much better, but it doesn't matter: no one's going to rip up tens of thousands of miles of rail track just because 6 feet is slightly better in some way.

Your FORTRAN vs. C example is much less black-and-white than this, because presumably, at the time you observed this flailing-around, C was not only in existence and available for use, but widely used in certain industries, just not yours. So it's not like you were proposing that everyone move to Ada, or Lisp, or your own language that you wrote but which no one actually uses. In a situation like that, there's valid arguments on both sides. Use the solution that your industry favors and is familiar with, or switch to another widely-supported solution that's used in other industries and has certain advantages?

Re:ah yes, anti-perl tirades are refreshing

[Anonymous Coward]

Are you fucking kidding? whitespace as syntax is an abomination. I can't stand python. Perl is incredibly good at what it was designed for, which is parsing and manipulating textual data.. the E and R in perl, extraction and report(ing)... The syntax is not that confusing, is very concise, and the execution speed is perfectly fine for just about any task that involves chopping up and reformatting text input.

Re:ah yes, anti-perl tirades are refreshing

[Fulcrum of Evil]

yeah, that sucks, but guess what? $ and \ bug me more. Python has straightforward OO stuff + okay syntax (modulo the whitespace thing). It also has a big enough lib collection that I'm happy. Python does re stuff fine, but most of what I use it for is scripting in a more general sense, so python it is.

Re:ah yes, anti-perl tirades are refreshing

[Anonymous Coward]

Every bit as refreshing as the anti-intellectual tirades like yours against those out of touch ivory tower computer "scientists".

Re:ah yes, anti-perl tirades are refreshing

[19thNervousBreakdown]

Calm down, Larry, it was a joke.

Re:ah yes, anti-perl tirades are refreshing

[ghmh]

>(And if you want to take the line that the CS attitude is correct, how would you prove that it's correct? Writing working code is evidently not relevant. And if you can't prove it, then what does the "S" stand for in "CS"?)

Stuff: Computer Stuff. It's what we all do.

Have to agree with the sentiment above though, reminds me Steven Levy's hackers, where they spend so much time on deciding on what "The Right Thing" was, that it left little time for application to the real world. I'm not a fan of perl (chose ruby over it/python back in 2001 or whenever it was), but can't deny its success for both itself and its successors.

Re:ah yes, anti-perl tirades are refreshing

[tgv]

If that purpose is making life difficult for programmers in general and obfuscation in particular, then I agree. If the purpose is doing something with /etc/passwd that you can't do with grep, I'm already less inclined to agree. Unless of course the word masterpiece was used in the sense that the atomic bomb is a masterpiece of physics and engineering, then I fully underwrite your sentiments.

Re:ah yes, anti-perl tirades are refreshing

[renoX]

>>You might think that the obvious utility of perl, the fact that perl and perl derived languages remain tremendously popular with people writing actual code, might blunt the man's opinion that it's an "abomination".

The men is criticising perl, why are you talking about 'perl derived languages', straw man?

I use Perl when necessary (because I don't have much choice of the language I can use: my boss do otherwise I'd use Python/Ruby or Scala), so it's useful, but I consider it to be an abomination too: a language which makes writing *maintainable* code very, very difficult.

Re:ah yes, anti-perl tirades are refreshing

[danieltdp]

So fresh new things always start being useless?

Re:ah yes, anti-perl tirades are refreshing

[danieltdp]

This has nothing to do with the language itself and could equally be done in many other languages.

But its not done in other languages, which makes Fortran the best option. You are thinking in a CS way. Physicists don't care about the language design. They are looking for the best tool for the job.

For them, it is not important if the tool is good because of design, because some vendor made and extension or because there is a lot of code available. What matters is that it gets the job done

Re:ah yes, anti-perl tirades are refreshing

[danieltdp]

Perl's syntax is not confusing for those who code. But when it comes to *read* code done in perl, then its syntax is an obfuscation masterpiece

Re:ah yes, anti-perl tirades are refreshing

[Grishnakh]

Depends I suppose.

Changing to a new system or standard usually isn't easy, because you have to overcome the inertia of the old way. But if it offers enough benefits, it may be worth it. However, you may not be able to convince people of that (look how long Lisp has languished in obscurity despite its supposed superiority).

Re:ah yes, anti-perl tirades are refreshing

[RightSaidFred99]

The "write-only" nature of Perl doesn't matter when nobody will be reading your 200 line perl script. Furthermore, even for some types of larger automation tasks you're more likely to find a System Admin type who can hack at your Perl application than e.g. Java or Ruby or Python or C#.

I'm as much of a snob when it comes to people writing big ass applications in Perl as the next guy, but it has its place in certain scenarios and for certain tasks.

Re:ah yes, anti-perl tirades are refreshing

[danieltdp]

I didn't get my point. It was a counterexample for parent's argument:

Yes, but the popularity of something can absolutely be used as a measure of its utility.

My take is: if its popular, is useful. It it's not popular, nothing can be said about its usefulness.

BTW: I don't know if its "counterexample for parent's" or "counterexample to prent's". Sorry. English is not my first language

Re:ah yes, anti-perl tirades are refreshing

[Grishnakh]

My take is: if its popular, is useful. It it's not popular, nothing can be said about its usefulness.

I disagree, at least for certain things. But a lot of it depends on compatibility.

For instance, suppose you download and use a drawing program which is highly unpopular (only 2 people use it). This program however reads and writes in standard file formats: .png, .jpg, .gif, etc., just like any comparable drawing program. This program could very well be quite useful, regardless of its lack of popularity. People just need to try it out, and because it uses the same standard file formats that other drawing programs use, the transition should be easy.

But for a counterexample, look at the BeOS operating system (sorry, BeOS fans). It's highly unpopular, and because of this it's not very useful. Because of its unpopularity, it's not being developed and maintained like other mainstream OSes, it doesn't have driver support they do, and it doesn't have application support they do. So unless you don't mind being stuck in 1998, using BeOS probably isn't going to be very useful to the typical computer user who wants to use Firefox 3.5, edit SVG drawings, use modern computer hardware and USB devices, do videoconferencing with Skype, etc. Even if BeOS's technical merits are good (this is debatable, but let's assume for argument that it's great technically), the lack of support, due to lack of popularity, makes it not useful as an operating system to get work done with.

Just like my prior example with the train locomotive with non-standard 6-foot gauge that won't run on any existing track that I know of, an unpopular OS isn't very useful because of the lack of compatibility.

So I guess in summary, the popularity of something, when combined with the factor of compatibility, can be used as a measure of usefulness. Unpopular but highly compatible with competitors: usefulness can't be determined. Unpopular and incompatible with competitors: not useful.

Re:ah yes, anti-perl tirades are refreshing

[tgv]

That's sort of what I implied. However, I've seen people try to write parser generators in object oriented Perl and that's taking it too far, let alone a real piece of software. I remember some problems I had with Perl. I overcame them and then Perl was upgraded...

Re:ah yes, anti-perl tirades are refreshing

[VirginMary]

Physicists don't care about the language design. They are looking for the best tool for the job.

But language design has a huge impact on what the best tool for the job is! Also most programmers, including physicists, spend most of their time writing and debugging and not waiting on their programs to run. So even if FORTRAN is 10% or 20% faster than C++, this is typically irrelevant. What matters is that over the entire lifetime of some code the better language design leads to savings of maybe 50% or much more in the time spent that humans have to write and maintain the code. This is where I had a hard time relating to many other physicists and engineers. Btw., I have a Ph.D. in physics myself. They don't want to learn a proper tool and end up wasting huge amounts of time over the years. I believe thats's called penny-wise and pound-foolish? (English is my 2nd language.) Also you accuse me of thinking in a CS way. Thank you! After all computer scientists spend way more time to think about software development than physicists. I think that therefore it is likely that they know a hell of a lot more about it than your average physicist. I doubt most of them would consider it to be a shortcoming if a computer scientist were trying to solve a physics problem by thinking in a physics way. :)

Re:ah yes, anti-perl tirades are refreshing

[Anonymous Coward]

It's no more optimal than modern C++. The fact is that "old-timers" are unable to keep up with the frantic pace of technology. No other reason. They know it well and don't feel the need to use anything else.

Socially relevent

[dkleinsc]

FTFS: "In her interview, Fran Allen makes an interesting assertion â" programming and computer science need to become more socially relevant."

How do you recognize the extroverted programmer? He's the one staring at *your* shoes.

Same goes for engineers. Name a well-known (outside of engineering) engineer. I'll wait ...

Since programming involves long hours alone staring at a computer screen, it's no surprise it tends to attract people who don't mind or even enjoy being alone, and for whom self-promotion is fairly low on the to-do list.

Re:Socially relevent

[Beardo the Bearded]

Same goes for engineers. Name a well-known ... engineer. I'll wait ...

Rowan Atkinson has a Master's in Electrical Engineering.

Re:Socially relevent

[Anonymous Coward]

Richard Buckminster âoeBuckyâ Fuller

Re:Socially relevent

[Anonymous Coward]

Dolph Lundgren, Master's in Chemical Engineering.

Re:Socially relevent

[rolfwind]

He's not a well-known engineer.

He's a well-known actor/comedian that happens to have studied electrical engineering.

Re:Socially relevent

[SigILL]

Name a well-known (outside of engineering) engineer.

Mahmoud Ahmadinejad (president of Iran), who has a doctorate in civil engineering and traffic transportation planning.

Re:Socially relevent

[timeOday]

Comedians are introverts.

Re:Socially relevent

[Anonymous Coward]

Same goes for engineers. Name a well-known (outside of engineering) engineer. I'll wait ...

Jimmy Carter (nuclear engineer).

Also, Scotty

Re:Socially relevent

[Monkeedude1212]

Same goes for engineers. Name a well-known (outside of engineering) engineer. I'll wait ...

Imhotep - Ancient Egypt.
Leonardo DaVinci - Renaissance
David Fisher - Present (Dynamic rotating tower thing).

Come on now, You can't clump Engineers into the same group as computer scientists, they've been around for ages.

Re:Socially relevent

[Anonymous Coward]

Name a well-known (outside of engineering) engineer.

James Watt.

Re:Socially relevent

[Catullus]

How about Hu Jintao, Paramount Leader of China, not to mention hydraulic engineer? I think there may be a few people in China who have heard of him.

Re:Socially relevent

[Mr Z]

Steve Wozniak? Dean Kamen? Burt Rutan?

Re:Socially relevent

[Anonymous Coward]

Angela Merkel - PhD in physics.

And chancellor [~=president] of Germany, for our american friends...

Re:Socially relevent

[Anonymous Coward]

Since programming involves long hours alone staring at a computer screen, it's no surprise it tends to attract people who don't mind or even enjoy being alone, and for whom self-promotion is fairly low on the to-do list.

Except for Eric Raymond.

Re:Socially relevent

[ph1ll]

Name a well-known (outside of engineering) engineer. I'll wait ...

Neil Armstrong? Alexander Graham Bell? Even Bill Gates, dammit.

Or my favourite, Isambard Kingdom Brunel? He might not be very well known in America but he was voted #2 Greatest Britain in a BBC poll. A lot of his work still exists (he died in 1859) and is pretty damned impressive. The guy was a genius hacker and a great self-publicist.

Re:Socially relevent

[SleazyRidr]

Name a well-known (outside of engineering) engineer.

C.Y. O'Connor is a respected historical figure in Western Australia. He was the engineer who designed the Mundaring-Kalgoorlie water pipeline, and the Fremantle Harbour.

Semantics aside, I agree with your point.

Re:Socially relevent

[Grishnakh]

Sorry, no. Ask any "regular" person who those people are, and they'll have no idea. Yes, they know what Apple Computer is, and they know what they gay-looking Segways are, but they don't associate those names with them. And they certainly don't know who Burt Rutan is unless they are in the aviation field, or read a lot about space topics.

Re:Socially relevent

[Grishnakh]

Not an engineer. Having a degree from decades back doesn't make you an engineer; you have to practice it as well.

That said, I wonder if he'd be any better at designing traffic systems than the idiotic "traffic engineers" we have here in the USA, who insist on setting traffic lights so there's no way to catch all green lights on a main boulevard, and intentionally time them so you have to get caught at every red light.

Re:Socially relevent

[drissel]

>Name a well-known (outside of engineering) engineer. I'll wait ...

Yeah, helluva lot more people know of Ralph Nader than Charles Kettering.

Re:Socially relevent

[Grishnakh]

And what exactly did Jimmy do in the field of nuclear engineering? Seems to me he's known as being a politician, not an engineer.

Re:Socially relevent

[proslack]

Just about every astronaut would qualify as a well-known engineer. They generally aren't introverts.

Re:Socially relevent

[perky]

In fact the majority of the current (fourth) generation of leaders in the PRC have an engineering background.

Re:Socially relevent

[Dragonslicer]

That said, I wonder if he'd be any better at designing traffic systems than the idiotic "traffic engineers" we have here in the USA, who insist on setting traffic lights so there's no way to catch all green lights on a main boulevard, and intentionally time them so you have to get caught at every red light.

Go ahead and time all the lights so that you get all greens. Now drive down the road in the opposite direction.

Re:Socially relevent

[DanTheLewis]

He's not a well-known engineer.

He's a well-known actor/comedian that happens to have studied electrical engineering.

• No true engineer could be famous. Therefore, anyone who is famous is not a true engineer, no matter how much engineering they did.

• So you've heard of this engineer before? You must be one of those engineering types, not "just folks". Anybody who knows about an engineer doesn't count...

It's a clever argument but it doesn't say much.

Re:Socially relevent

[ChatHuant]

Same goes for engineers. Name a well-known (outside of engineering) engineer. I'll wait ...

Sure, here you are, off the top of my head:

  - Leonardo da Vinci

  - Alexander Graham Bell

  - Henry Ford

  - Ray Dolby

  - Gustave Eiffel

  - Neil Armstrong

  - Isambard Brunel

  - Rudolf Diesel

  - Graf von Zeppelin

  - Charles Babbage

  - Alexander Graham Bell

  - Lee DeForest

  - Neil Armstrong

  - Seymour Cray

  - Ray Dolby

  - John Fleming (the inventor of the first vacuum tube, not Alexander, the penicillin guy)

  - Westinghouse

  - Lord Kelvin

  - Tesla

  - Lee Iacocca

  - Robert Fulton

  - of course, Ferdinand Porsche
... and many, many others!

 

Re:Socially relevent

[bjourne]

Yassir Arafat, Mahmoud Ahaminejad, Neil Armstrong, Bill Gates.. there are quite a few celebrities that are engineers. Granted it generally isn't their engineering that made them famous. But your question is like asking for famous astronomers and the only one you can think of is Brain May.

Re:Socially relevent

[Anonymous Coward]

Osama Bin Laden, who is a Civil Engineer.

Re:Socially relevent

[myowntrueself]

And what exactly did Jimmy do in the field of nuclear engineering?

Jimmy Carter?

He was one of Americas first *ever* naval nuclear engineers wasn't he?

Re:Socially relevent

[Anonymous Coward]

How about Buckminster Fuller? He's pretty well known, certainly to anyone who remembers when his designs were all the rave.

Re:Socially relevent

[radurusu]

How about Jimmy Carter, nuclear engineer?

Re:Socially relevent

[jonaskoelker]

Hu?

Re:Socially relevent

[Anonymous Coward]

That said, I wonder if he'd be any better at designing traffic systems than the idiotic "traffic engineers" we have here in the USA, who insist on setting traffic lights so there's no way to catch all green lights on a main boulevard, and intentionally time them so you have to get caught at every red light.

Go ahead and time all the lights so that you get all greens. Now drive down the road in the opposite direction.

That's actually quite feasible, if only there were some small, cheap device that could perform mathematical and logical operations very, very quickly. But of course there isn't, so we must live with a system of fuel-wasting delays.

Re:Socially relevent

[Man Eating Duck]

That said, I wonder if he'd be any better at designing traffic systems than the idiotic "traffic engineers" we have here in the USA, who insist on setting traffic lights so there's no way to catch all green lights on a main boulevard, and intentionally time them so you have to get caught at every red light.

xkcd expressed it better than I can. Besides, you probably remember the irritating delays a lot better than the more frequent times when they're absent.

Re:Socially relevent

[Man Eating Duck]

... and many, many others!

If I hadn't already posted you'd've gotten a +1 Informative, even if many of those just have famous surnames (and you mentioned Neil Armstrong twice) :)

Re:Socially relevent

[Grishnakh]

xkcd is completely wrong.

What I'm talking about is traffic lights that are intentionally timed so that you absolutely cannot miss the red lights along a main boulevard. I drive along one of these every single day on the way home from work. There are NO times when I catch the greens; every time the first light turns green, the next one turns red before anyone can get through it.

They probably do this because they want to slow down traffic in front of the shopping mall at that location, but that's not a good excuse to me.

Re:Socially relevent

[Anonymous Coward]

He neither completed that training nor served in that capacity on an actual nuclear vessel. It's a common misunderstanding.

- T

Biggest Gripe about coding .. shouldn't be coders

[ackthpt]

I'm disguted, repeatedly, at what passes for applications these days. Back when I started we wrote tight, purposeful code and optimised for speed or size. But now I'm constantly encountering untested code, applications which have the most bombastic interfaces, layouts which seem more ad hoc than well planned and a dozen other gripes.

Can't be all the coders faults. Whatever happened to Q/A? Whatever happened to analysts who have a clue? I keep seeing people who have no background in IT making decisions and overruling experince wiht seat of the pants decisions. Even to the point of corrupting data and having no fall-back plan.

I feel I need to retire, but I'm many, many years from that.

I'd like a book which discusses the EPIC FAIL of present day standards and practices of software development.

I Hate All Programming Languages

[Louis Savain]

Perl is an abomination as a language

LOL. From my perspective, all computer programming languages are abominations. They are ancient primitive relics of what I call the Babbage and Lovelace era. They should all be placed in the Smithsonian right next to the buggy whip and the slide rule. I live for the day when a constitutional amendment is passed to ban them all. :-D

Re:I Hate All Programming Languages

[Louis Savain]

Funny. In my opinion, Labview, too, is an abomination. A truly compositional programming environment should be based strictly on a hierarchical tree. That is to say, the program should look like a tree and should be a branch in the universal tree of all software applications.

Re:I Hate All Programming Languages

[gnupun]

A truly compositional programming environment should be based strictly on a hierarchical tree.

How would you handle loops or complicated algorithms with many conditional paths in such a language? Languages are designed to solve practical problems, not to just to look pretty.

Re:I Hate All Programming Languages

[Louis Savain]

It's all done with sensors and effectors.

Re:I Hate All Programming Languages

[Anonymous Coward]

The same way you do loops or conditions in lambda calculus.

Re:Biggest Gripe about coding .. shouldn't be code

[aquatone282]

I'm disguted, repeatedly. . .

Sounds painful. Hope you get over it soon.

Slashdot

[hey]

Do good coders read Slashdot during company time?
(Like me and you)

Programmers at Work (1989)

[plcurechax]

Another similar book that is no longer in print is the semi-classic, Programmers at Work subtitled Interviews With 19 Programmers Who Shaped the Computer Industry, (1986 /1989) by Susan Lammers which includes interviews with well-known or pioneer programmers such as Charles Simonyi (Microsoft), Bill Gates, Gary Kildall (Intergalactic Digital Research), Andy Hertzfield (Macintosh Operating System), John Warnock (Postscript) and C. Wayne Ratcliff (dBASE).

Re:Programmers at Work (1989)

[David Off]

I've read it. To be honest I didn't find Gates contribution to be very inspiring, I think he has far more to say about business. I think Simonyi is way overrated.

This book sounds like an update to that work to some extent.

Re:Programmers at Work (1989)

[vsedach]

Talk about not knowing the history of the field! I haven't read Programmers at Work yet, but it is on my to-read list. I completely forgot about it when writing this review.

Re:Programmers at Work (1989)

[lgw]

Simonyi is to blame for Hungarian notation. Sure, it turned into the opposite of all his recomendations, but he's still the mad scientist who created that monster.

Re:Biggest Gripe about coding .. shouldn't be code

[oatworm]

Ah yes, "They Don't Make Them Like They Used To."

Bugs have been around forever. Q/A has been troublesome since the beginning - heck, many of the problems outlined in the Unix Hater's Handbook were the direct result of poor Q/A throughout the... erm... Unixverse. Bloated code? That's been around as long as there's been code - heck, INTERCAL was explicitly designed to produce it! People with no background in IT making decisions and overruling experience? That's also been happening for ages.

That said, I'll give you credit on one thing - yeah, your code was tight, purposeful and optimized for speed or size, at least as far as the machine was concerned. You didn't have a choice. Instead of focusing on maintainability or ease of understanding, programmers had to bend to the machine's thinking instead of the other way around since there just wasn't enough machine to tolerate human weakness. Eventually, though, computers became powerful enough where programming could stop focusing on getting every last clock cycle's worth by any means necessary and more on solving programming problems quickly and easily. Put another way, the programmer's time finally became more valuable than the machine's time. Once that happened, the rules changed - something which those some of those people with "no background in IT" figured out years ago (I hear it's because they had a background in some dark discipline called "accounting") and which a lot of IT people still can't wrap their minds around.

No offence

[ctid]

But why don't you convince your local library to buy the book? They will thank you for your recommendation.

Re:Biggest Gripe about coding .. shouldn't be code

[Anonymous Coward]

That sounds bad, but it's nothing compared to being digested repeatedly.

Re:Biggest Gripe about coding .. shouldn't be code

[SquirrelCrack]

Are you sure you don't just need a new job?

At my current company we have great analysts and we tend to write purposeful code that has been well optimized for speed and maintainability. Our management even has a clue... Don't assume that your personal experience at your job is indicative of state of an entire industry.

Why Donald Knuth?

[Anonymous Coward]

That guy is a relic of another age, and certainly not a coder; he's purely an academic in theoretical computer science.
He's good at making algorithms, but certainly not at coding.

Re:Why Donald Knuth?

[1729]

That guy is a relic of another age, and certainly not a coder; he's purely an academic in theoretical computer science.
He's good at making algorithms, but certainly not at coding.

You're ignorant. Have you ever used TeX or METAFONT? Knuth wrote them. The CWEB compiler? Knuth again. How about the MMIX simulator and assembler for MMIX architecture that Knuth designed to go along with TAOCP? Yep, Knuth. Want some more? See:

http://www-cs-staff.stanford.edu/~uno/programs.html

Re:Why Donald Knuth?

[wdavies]

Interestingly, I do wonder how Knuth would be rated in these days of massive (have you seen Java recently?) APIs, agile, test-driven development ? One thing that seems in common with all these guys is that they have written code which is of the old-school low-level infrastructural variety. His algorithm code is awesome, but a little spartan on the variable naming conventions. This is coming from someone who has an autographed set of TaoCP (and attended his occasional rare seminars).

Does the book actually have interviews with the front-liner programmers who have to deal with product management and managers in their day to day development work on web apps?

Winton

Re:Why Donald Knuth?

[renoX]

>Have you ever used TeX

Note that TeX is an exemple of good coding ok, but not of 'good design' IMHO: the language is quite awful..

Re:Why Donald Knuth?

[1729]

>Have you ever used TeX

Note that TeX is an exemple of good coding ok, but not of 'good design' IMHO: the language is quite awful..

What would you change? TeX is certainly not easy to use, but it's extremely powerful.

Re:Biggest Gripe about coding .. shouldn't be code

[Anonymous Coward]

Sorry to nitpick, but QA is different from Q/A or Q&A. The first refers to quality assurance, which I'm most assured you're referring to the lack of, and Question and Answer, which undoubtedly you have to do to compensate for the potential hire's lack of QA.

Devaluation of software engineering

[JustNiz]

Is it just me or does anyone else also hate being described as a coder?
It seems to me that this label is just another devisive step in the general undermining of skilled Software Engineering.

Re:Devaluation of software engineering

[Anonymous Coward]

That's funny, I also have issues with the devaluation of the time honored profession of engineering by over liberal use of the term for anything remotely related to technology.

Programming isn't engineering.

Re:Devaluation of software engineering

[lgw]

Real software developers code. Sure, they do other important work as well, but code is the work product. Every single person I've ever worked with who denied this was a crap coder who could write a clear design doc (but great at PowerPoint, or Project, or other busywork).

Re:Devaluation of software engineering

[GeckoAddict]

This sometimes bother me when they are grouped together. There are some people doing actually engineering out there, but the people that claim it are rarely actual engineers. Software Engineering != Coding/Programming

Software Engineering (to me, anyway) incorporates usability studies, doing a proper architecture, managing people, improving software development processes, testing, and a whole lot of other stuff that's NOT coding. To actually 'Engineer' a product/system takes a lot more than a couple of tech school classes on C++. To me it's a lot like architects: they design the building, do the math and weather simulations, considering a number of factors (including usability, cost, maintenance, schedule, materials), while the construction worker is the 'coder' who does some grunt work to put it together as specified. The construction worker would never consider themselves 'architects', so why do a lot of programmers think they are 'engineers'

Re:Devaluation of software engineering

[Anonymous Coward]

You are right; programming, in and of itself, is not engineering. Programming is, however, the method software engineers use to implement designs. Now the terms "coder" and "programmer" seem to be synonyms of "software engineer" in today's world, so these are engineering professions. Just because they can (but arguably, shouldn't) engineer their systems while they're implementing them does not render the profession a skilled trade, as apposed to true engineering. I'm not exactly sure what you meant by your statement, but I sense a "you don't design anything physical, so you're not an engineer" overtone, which is horribly misguided.

Re:Devaluation of software engineering

[ClosedSource]

To the same degree that electronic circuit design isn't engineering.

Re:Devaluation of software engineering

[Anonymous Coward]

Is it just me or does anyone else also hate being described as a coder?
It seems to me that this label is just another devisive step in the general undermining of skilled Software Engineering.

Define software engineering. How many years of rigor does it take to be called an engineer. Does it result in a license that you can lose for screwing up?

I did coding, design and implementation for 35 years. I still get together with my real engineer friends (MEs, EEs, CEs, etc.) and chuckle at the idea of "software engineers". It's considered to be as funny as when garbagemen became "sanitation engineers" and the kid at the gas station who pumped your gas was a "petroleum displacement engineer".

He's right!

[Invisible Now]

If working down on the corporate cube farm has shown me anything - it's that non-technical managers produce atrocious applications. Unbelievably expensive. Too slow to be used in spite of the cost. Rejected by users, because they are seldom part of the development team.

I can predict, fairly accurately, the outcome of a corporate development effort from the answer to these questions:

Is the business sponsor and the user team deeply involved in an Agile/Iterative way throughout the development effort?
Is the actual technical side of the development led by a technical manager with real authority?
Does he or she have their choice of tools and technology without interference from above or corporate IT's "Best Practices"?
Are requirements managed flexibly, with early deliverables of basic functionality followed up be newly discovered needs?

The biggest breakthrough in coding, reflected in the biographies of the coder interviewed, is a return to smaller teams, guided by involved end users. In other words, rediscovering earlier practices and respect for the lessons of the Mythical Man Month.

"Agile" happened.

[Animats]

Whatever happened to Q/A? Whatever happened to analysts who have a clue?

"Agile programming" happened. No need to figure out the requirements up front, they're going to change anyway. No need to architect the system, we'll just use a "framework" and add features.

This works OK for web sites in PHP, but don't try to do hard real time or database internals or secure software that way. Agile programming will give you a set of loosely coupled features, but for many user-facing applications, that's good enough.

Re:"Agile" happened.

[Anonymous Coward]

Wow, someone doesn't know Agile or has worked for a company that didn't use it properly.

Agile Development in the company I work for works very well. Everything is tested/architected/"securified" properly within the constraints of limited scope we are given. Agile allows us to quickly develop pieces of a larger plan and change when the requirements inevitably change. When done properly scope-creep is eliminated, code is tested, and the product is delivered on time.

The real trick is making Agile work is finding BAs, developers, and QA who can all work together and communicate.

Re:"Agile" happened.

[Anonymous Coward]

You might be surprised how well you can do complex, high-performance, high-reliability systems while being agile. And I speak from doing so for decades before the word "agile" was applied to it. First in assembly language, then in C, and more recently in Java. The key is to nail down the critical parts first, to allow flexibility in the core so that the inevitable changes won't wreck the existing core. Hint: clean simple systems are easier to change than baroque bags of tricks. And generally perform better/more reliably.

What happened to Q/A? The "Git 'R Dun!" requirement. Rush it out the door! Yesterday!

Analysts who have a clue? Cost too much. We'll just add another team of cheap offshore developers.

Re:"Agile" happened.

[Anonymous Coward]

No kidding....

Agile is about consistency and communicating to everyone what is going on. I know I can do x # of features in y amount of time. Part of the process isnt everything just 'happens as we go'. You can have iterations where you are building the design. Then the following iterations are filling it in. You can change your design because the process allows for it. Instead of finding out a year and half later when it is in QA and you have dozens of dependencies on a bug.

One thing has been proven over and over is waterfall *rarely* works. Most (even agile) processes fail if you do not use them properly.

If you go into an agile process and just start coding with no idea where you are going you will not end up with a good product. Just a mediocre one. You have to have iterations where you decide, and its not 'nailed down', we need to do these 50 things. Those 50 things may not be totally nailed down yet. Many may just go away. Just like waterfall you need to discover your requirements. Ive had requirements on my 'todo' list for months. But they are not done yet as other things are higher priority.

Done badly I shudder to think what agile would be like...

Re:"Agile" happened.

[VoltageX]

Finally someone said it. Thanks.

Re:"Agile" happened.

[Jack9]

"Agile programming" happened.

Fail.

I guarantee not a single app that is labeled an abomination by the parent was done using Agile. Fact of the matter is that a miniscule number of shops use Agile. The most successful projects I've worked on from Contract work to Adserving to Accounting, were (both) Agile projects. The rest were "we're outta money/time, I guess that's what we've managed to finish".

Re:"Agile" happened.

[Permutation Citizen]

Sure Agile when it's correctly done may give great results.

What I've observed is agile keyword used to rush things, getting rid of requirement management, going from hack to workaround. Quite the opposite of how agile is supposed to be actually.

And Q/A role is mostly to take the blame, as the software is not designed to be testable.

Analyst, who ?

Re:"Agile" happened.

[Anonymous Coward]

I feel compelled to inherit and extend these sentiments. My experience with Agile-produced systems has uncovered repeated half-baked implementations because the engineers don't think through the problem. Yes specs will change - but by focusing exclusively on the current iteration you have doomed yourself to mediocrity. Not only will you wind up with âoeloosely coupled featuresâ but any optimizations that span more than the in-development piece will ultimately wind up ignored.

jwz is a household name?

[Anonymous Coward]

Never heard of him.

I Googled to find out that it refers to someone named Jamie Zawinski. Still never heard of him, and I've been programming for over 20 years.

I also checked around the office. I got blank stares at the mention of jwz and Jamie Zawinski.

Everyone knew Knuth though.

Knuth is a household name, but jwz? Don't think so.

Re:jwz is a household name?

[Anonymous Coward]

You had to be a unix (or linux) user in the mid-to-late 1990's to have heard of him - he probably was one of the most famous programmers at the time. By that time, he had already been one of the originators of XEmacs, which had a markedly more advanced GUI than GNU Emacs. He created XScreensaver, which was installed by most unix users who weren't satisfied with a blank screensaver. And most importantly, he was one of the main developers of Netscape, which was at the forefront of the explosive growth of the web and a top-tier dot-com company.

If you typed about:jwz on the Netscape URL bar, you'd get his home page. Apparently that one does not work on modern Firefox any more, but about:mozilla is still there.

The Well of Uncomfortable Truths

[Tetsujin]

Perl is an abomination as a language

LOL. From my perspective, all computer programming languages are abominations. They are ancient primitive relics of what I call the Babbage and Lovelace era. They should all be placed in the Smithsonian right next to the buggy whip and the slide rule. I live for the day when a constitutional amendment is passed to ban them all. :-D

So your solution is a concurrent language using diagrams in place of syntax?

I'm not about to tell you the COSA approach is a bad idea, and I'd hate to discourage someone who's obviously got a lot of interest in making a system that really is better... But I have my doubts about visual programming languages in general. Mainly because it bypasses the established mechanisms humans have developed for conveying complex ideas (i.e. writing) in favor of visual diagrams - you lose the capability to convey a large volume of information effectively in a reasonably small space - or at least it seems you would. At any rate I can't figure out how those node graphs work...

And your statements about reliability? In what sense can a logic circuit be "guaranteed" free of defects? Did Intel know about this method of quality assurance back when they were designing the Pentium? It seems to me that simple logic circuits can be guaranteed free of defects because the human mind can readily model the whole system and intuitively decide it is correct. When the system is complex, that is no longer true.

I donâ(TM)t want to know about how to implement loops, tree structures, search algorithms and all that other jazz. If I want my program to save an audio recording to a file, I donâ(TM)t want to learn about frequency ranges, formats, fidelity, file library interface, audio library interface and so forth. This stuff really gets in the way.

It seems as though you've just said you want someone else to solve your problems for you.

To a certain extent this is quite reasonable. If you want to save an audio recording, it's reasonable to expect someone else to have come up with a program that will make it easy for you. This is why we have "sound recorder" applications and the like.

But what if you're the first person to write such a program? Or what if, for whatever reason (i.e. licensing issues, etc.) you can't use the work that's already been done? Then it seems to me that there's no way around it: you simply must understand about audio formats and deal with them on their own terms.

Likewise, suppose you want a program that can calculate a route to drive from Baltimore to Chicago. Of course it's been done: you can go ask Google for the route... But what if you want your own program that does this? Like if you wanted to compete with Google and get in the computer-map business? Then you'd need one of those pesky algorithms to turn that big pile of data into a usable route. The problem's not practically solvable unless you approach it with the right kind of strategy, that's exactly what an algorithm is. It's not practical to expect that all the problems in the world have already been solved by whoever created your language toolkit - if it were, then I'd be out of a job.

Re:The Well of Uncomfortable Truths

[Evil-G]

And your statements about reliability? In what sense can a logic circuit be "guaranteed" free of defects? Did Intel know about this method of quality assurance back when they were designing the Pentium? It seems to me that simple logic circuits can be guaranteed free of defects because the human mind can readily model the whole system and intuitively decide it is correct. When the system is complex, that is no longer true.

There is some progress being made towards "guaranteeing" the correctness of circuits, such as:

this. Centaur Technologies (VIA) uses theorem proving tools to guarantee the correctness of parts of the VIA Nano processor. I'm sure with a little digging more references to this sort of thing can be found.

Intel appears to be actively working in the area of formal verification also, e.g. this - although this doesn't directly deal with low level circuits.

So, it is possible to guarantee some correctness, although I suspect it rests on the correctness of the theorem prover you're using also.

Re:The Well of Uncomfortable Truths

[master_p]

I agree with you, but I also agree with the COSA guy a little bit. In my experience, programs that are built in a reactive way (reactions attached to signals) are easier to maintain. I have recently finished a not-to-large application for our customer that did quite a lot of changes in the requirements. I had the provision of separating components and use a signal & slot mechanism for when components needed to do something with other components. The result was that I could easily mix and match components, up to a certain degree of course.

I don't think the visualization medium matters in a significant way. Either diagrams or text does the job. What is significant is to model components based on signals and reactions.

Re:Biggest Gripe about coding .. shouldn't be code

[Dutch Gun]

I hear you. I remember when, back on my Apple II+, I could write new music on my sequencer (with fully sampled orchestral sounds - no external hardware needed), download new mp3s from Amazon.com, and chat in real-time with some friends, all at the same time. I remember how easy it was to stream real-time video wirelessly to my TV. Programming interfaces was a snap as well, with fully-featured APIs available for several different flavors of operating systems.

I remember how just about any information you could want was available on the Internet with just a click of a mouse. I especially loved how I could order just about anything online - no more hectic holiday shopping for me! Also, remember how awesome the videogames used to look and play? Why, those first-person shooters practically looked photo-realistic. It was amazing how well they ran on such old hardware.

Integrating new hardware and devices was far easier as well. We could just pick up a new gizmo and plug it to the Apple II's USB port, and damned if the computer didn't just instantly recognize it and load up some drivers. Best of all, you could pick up a new, reasonably powerful computer for about $1000 or so.

Man, those were the days... Oh, wait. I'm thinking of *today's computers*.

Business Model should change

[424f54]

"programming and computer science need to become more socially relevant"

Top engineers should market themselves using a system like actors or athletes. A lot of the jobs for top level software engineers are project based.
They should get Agents to negotiate contracts for them and market their skills for the top dollar.

Engineers today are treated like resources with experience being looked at as the number one factor in compensation.
Every engineer brings a different set of skills to the table and should be compensated based on their talent not on their experience.

Maybe they also need a reality show to make coding more relevant.

Good Points But...

[Louis Savain]

I see your points but I think you should read Parallel Computing: Why the Future is Compositional... and hierarchical... and non-algorithmic... and deterministic... etc.

And while you're at it, you might as well read How to Solve the Parallel Programming Crisis. Without multithreading, of course, since multithreading is the biggest and most hideous abomination of them all.

Re:Good Points But...

[lgw]

You really find it that hard to program? I feel sorry for you. Good luck with your rainbows and unicorn giggles and "non-algorithmic programming". >

Re:Good Points But...

[Louis Savain]

Compared to how easy it could be if it were done right? Yes. At any rate, since you are so happy with yourself, I won't feel sorry for you when you'll lose your programming job five or ten years from now, just because your services are no longer needed. By anybody.

Re:Good Points But...

[lgw]

Yeah, I've heard that one about every 5 years for 20 years now. There's no escape from clearly structuring your thoughts on how to solve a problem, and thinking through all the corner cases and error conditions. Nevertheless, every 5 years or so, some genius thinks that the language is the hard part and goes off to solve that problem.

But "non algorithmic" is a good laugh. That's "not even wrong".

Re:Good Points But...

[Louis Savain]

As they say, opinions are a dime a dozen.

Re:Good Points But...

[lgw]

Engineers test their opinions against reality. You've made a testable prediction. Check reality in 5 years to see if there's an idiot in this thread. My own prediction: in 5 years you'll be on to some new thing that's going to replace programming, for sure this time, and will have forgotton about this one.

Re:Good Points But...

[Louis Savain]

Opinions, opinions, opinions. See ya.

Re:Good Points But...

[Anonymous Coward]

Some I'm reading this thread, and your incredibly mature final comment, and something in your tone stuck me as familiar ... it reminded me of the dismissive attitude of one of my co-workers - the supposedly devout Christian.

So I wasn't too surprised to find some religious mumbo-jumbo at your blog.

There may actually be some good ideas mixed in the blog as well ... but to paraphrase what you said, ideas are a dime a dozen. But like lqw noted, ideas that have actually been tested and demonstrated are what's really valuable.

Re:Good Points But...

[Tetsujin]

I see your points but I think you should read Parallel Computing: Why the Future is Compositional... and hierarchical... and non-algorithmic... and deterministic... etc.

And while you're at it, you might as well read How to Solve the Parallel Programming Crisis. Without multithreading, of course, since multithreading is the biggest and most hideous abomination of them all.

Parallel programming is a concept I can stand behind - I haven't done anything with it yet but I've learned a bit about Erlang and it seems like a good thing.

One of the things that bugs me about the way you apply parallel programming to your concept is that you appear to apply it to every level of the language design. Even the most trivial operations are parallel by default... That seems like a bad idea to me for any number of reasons. First off, the sequentiality of operations is useful for the programmer to develop a clear idea of what the program does: parallelism doesn't help people understand a program when you're dealing with a small unit of code, and I would even argue that it hinders understanding. Second, on anything remotely similar to today's hardware, execution is more efficient when dealing with either a single sequence of operations, or multiple sequences of operations running in parallel (and not interacting too much). The former is the strength of traditional imperative programming, and the latter is the model being advanced by parallel languages like Erlang: write a fairly self-contained module that does a job, and have it communicate with other modules via a system of message queues.

One point that I didn't really get was how synchronization was supposed to work between those program nodes. If this were a digital electronic circuit one would expect a clock pulse to go to all the nodes to tell them when to update themselves... I'm not entirely sure what your solution was in this thing...

The whole visual programming stuff just seems very, very cryptic. Everywhere you had a mass of nodes and the "equivalent" traditional imperative code, it seemed like the plain old code was both clearer in what it did and more informative about the details... But, then, guess which of the two I spend most of my time dealing with? Perhaps if I took more time to understand the node graphs it it might be less so, I'm not sure. Have you taken a crack at actually writing this thing yet? It's important to remember that all the brainstorming in the world doesn't really get you anywhere... The project doesn't really exist until there's working code of some kind. This is something I'm currently dealing with myself - something I've been brainstorming for a while now but haven't yet coded...

Re:Good Points But...

[Louis Savain]

Doctors should try their own medicine, IMO. I dismiss those who dismiss me. That is all.

I'm just an idea man. If my ideas are good, others will act on them and they do. There are several people working on implementing their own a COSA interpreters and associated user interfaces. Currently, I don't have the time to develop code. Besides, I am really interested in the hardware aspect of the model.

Also, it is not as if I am twisting anybody's arm to read my stuff. My motto is, love it or leave it.

Re:Good Points But...

[tgv]

Visual programming is definitely not the answer to all problems, but it can help build simple variations on a theme. I can imaging that building simple database driven websites could be done with visual programming. Certain simulations can also done by visual programming, if you've got the right environment. Did you ever look into analog computing? That's a great example of visual programming (and totally esoteric!).

Any complex visual programming will introduce bugs. Different bugs than the ones we know, but bugs nonetheless. If you connect 20 modules, each of which a consists of many modules consisting of many operations, chances are that you've overlooked one or two assumptions and your application will loop indefinitely, produce the wrong answer, whatever. Then try to find the error...

Your point about parallelism is not completely correct. In a purely functional language, everything can be parallelized, even addition, since there are no side effects to worry about. That said, even the lowliest operation has to wait until its operands are available, so you still have a proper sequence of execution. This, in combination with lazy evaluation, was very promising... 25 years ago. Still, if you've written a functional application, you can parallelize it at any point, which is cool.

Re:Biggest Gripe about coding .. shouldn't be code

[scamper_22]

I'm surprised you think code quality has gotten worse.
Heck, even look at protocols. What about SMTP... the completely authenticantionLESS mail protocol! You wouldn't find that today.

I think this the 80s television syndrome. We all think TV was better back in the day. Probably because we only remember the good ones and we compare it to all the crap we have today (reality tv...). But we forget the good shows today (Lost, BSG, seinfled... whatever floats your boat).

let's not even get into how much more is expected of a modern applications. It's not simple text fields any more.

I've run the gamut from old control systems code to networking and even some modern web stuff.
All I can say is software has gotten a whole lot better, as has the process.
I'm sure there's all kinds of crappy code out there. and that is largely due to software being used so much more. Not everyone writing software can be an expert in it.

8 Hour days + Programming

[Anonymous Coward]

(Posting AC just in case any co-workers are reading)

Kind of off-topic, but does anyone think that programming for 8 hours a day (with a ~1hr lunch and a few breaks) is incredibly unproductive? I have a feeling that is that an in-house consultant type system may work better. You'd want to stop your programmers from churning out crappy code quickly just to get the payment, so maybe a combination of a salary and per-job pay would work.

I find myself losing focus around the 4th hour, and I'm completely useless after the 6th hour. I literally surf the web for 4 out of 8 hours of my day to keep myself consistently productive in case something needs to be done close to 5:00. Am I just a defunct employee or do others have trouble programming for 8 straight hours? I have a fantastic office full of very friendly people, very little restriction on my creativity, and great pay, yet I'm going to quit asap because I am miserable and exhausted every day. I have to work in C++/MFC (very, very painful... MFC is a joke) and design fairly mundane systems, so maybe that has something to do with it. Opinions?

Re:Biggest Gripe about coding .. shouldn't be code

[lgw]

Yeah, because the test of quality software is shiny graphics and multimedia. You're a non-technical manager, aren't you?

Re:Biggest Gripe about coding .. shouldn't be code

[Anonymous Coward]

This is one of those funny things about software. Software is so valuable, people are willing to use it even when it's buggy. No one wants to go back to the manual way once they are shown the automated way. It is often less work to workaround the defects than to go back to no software.

Combine that value proposition with the fact that software demand way outstrips supply, and you get a lot of marginal software.

Cars were like this once before too. MG owners know what I am talking about. Cars used to be far less reliable than buggy software from a major vendor. No one remembers anymore, cause the Japanese cleaned their clocks, and they are all gone now. (Miata anyone?)

Next time you see an MG, ask the driver how many parts cars he has in his garage to keep that one running. My uncle used to have 2 parts cars for every running MG.

But if I said that 2/3 of your software would basically not run, and you'd have to harvest DLL's from 2 of them to keep the third one running, you'd go nuts. But that's how cars were for a long long time. Just like software is now. /shrug. Move along, nothing to see!

Re:Biggest Gripe about coding .. shouldn't be code

[Anonymous Coward]

Oh, wait. I'm thinking of *today's computers*.

Yeah, see, this part wasn't necessary.

no mentors

[Anonymous Coward]

We don't need no stinkin' mentors, the Chinese ain't got none, and they seem to be doing just fine.

Re:no mentors

[Anonymous Coward]

This guy's an idiot. I'm at HP and all our 'coding standards' about not copying opensource or potentially copy written code into COMMERCIAL APPLICATIONS are of no concern to the bereft-of-the concept-of-intellectual-property Chinese teams we employ. They don't need anyone to teach them anything because they just freely copy anything they see fit to, whether they understand how it works or not.

Re:no mentors

[melun]

The biggest difference between Chinese work culture and western work culture is found in the work ethic. And they have none - unless intellectual property rights MEGA-abuse is under ethics in your dictionary.

"Brilliant Programmers"

[fm6]

I have mixed feelings towards the people cited as "all-time great programmers and computer scientists", at least the ones I know anything about.

Ken Thompson. The one, absolute no-brainer for inclusion, because he's the most influential programmer ever, without exception. His minimalistic approach to OS design and API specification has had a profound effect on how people think software platforms. I started to study programming before Unix became widely used, and the sheer baroqueness of pre-Unix OS's is far beyond what younger programmers can imagine. Even if you've never read anything this guy has written, you've been influenced by his ideas. We all owe him big time.

Donald Knuth. His contributions are pretty major. But the paradigms he uses to talk about programming are thoroughly obsolete. And I do not understand his obsession with finishing an unfinishable book.

Josh Bloch. I've had the pleasure of actually working with him. Brilliant dude, and certainly someone all programmers should listen to. (And he doesn't get enough credit for his contributions to the design of Java.) But calling him a programmer is a bit like calling Frank Lloyd Wright a "builder".

Jamie Zawinski. I don't know that much about the guy, but what I do know makes me unwilling to accept his opinion on anything. I'm informed mainly by the config files for early versions of Netscape Navigator. JWZ's comments in these files were the only documentation I could find for making the browser work with PC keyboards under Linux. These were short of useful information and long on rants about the supposed shortcomings of various hardware vendors. These would have been stupid and unprofessional, even if they hadn't been arrogant and poorly informed. (No Jamie, Alt and Meta are not the same thing.) And isn't his main claim to fame his contribution to the Netscape code base? Most of which was simply abandoned as unmaintainable when NS's projects got taken over by Mozilla and Sun.

With Agile, it's quite simple

[ClosedSource]

When an Agile project fails, it's either because you're not following the rules or you're following the rules too closely.

Re:Biggest Gripe about coding .. shouldn't be code

[Dutch Gun]

Yeah, because the test of quality software is shiny graphics and multimedia. You're a non-technical manager, aren't you?

I program video games for a living, and I compose music on the computer as a hobby. As such, I'm somewhat partial to shiny graphics and multimedia.

Re:Biggest Gripe about coding .. shouldn't be code

[LaissezFaire]

I'm having trouble deciding if you're a troll or not.

You've decided that the coders who don't test their own code against itself or the spec (untested code) aren't at fault. So now it's in the lap of QA (who as often as not works for development), the GUI designers, or the product managers, and maybe marketing.

So since you've 1) Identified the problem (large/slow/buggy code, cruddy GUIs), and 2) Identified the source (clueless people not in development), when are you going to 3) List possible solutions and 4) Implement the solution?

You've labeled the problem as systematic, so to fix the problem you need to be part of the system. Your available choices are to 1) Go into management / decision making and change the brokenness, or 2) Write good code yourself, mentor your cube neighbors, and live in peace by ignoring the rest.

Re:Biggest Gripe about coding .. shouldn't be code

[Anonymous Coward]

Once that happened, the rules changed - something which those some of those people with "no background in IT" figured out years ago (I hear it's because they had a background in some dark discipline called "accounting") and which a lot of IT people still can't wrap their minds around.

The accountant types are just whoring out their programming departments because they can. They've trained users to accept shit which "will be fixed in the next release".

If they tried that with their engineering departments and a building or a bridge failed, there would be consequences. There are fundamentally no consequences for putting out bad programs, unless the programs control radiation dosages for cancer treatment, as we've seen http://en.wikipedia.org/wiki/Therac-25.

Re:Biggest Gripe about coding .. shouldn't be code

[Anonymous Coward]

Whatever happened to Q/A?

I know, Teacher, I know!

I worked for a software house well known in the credit rating business -- not one of the ones we absorbed. The day I was laid off a few years back, it's my understanding that half or more of the QA team was also laid off.

Well, that's at least one answer.

Re:Biggest Gripe about coding .. shouldn't be code

[some-old-geek]

Put another way, the programmer's time finally became more valuable than the machine's time. Once that happened, the rules changed - something which those some of those people with "no background in IT" figured out years ago (I hear it's because they had a background in some dark discipline called "accounting") and which a lot of IT people still can't wrap their minds around.

Unfortunately "those people" appear to have a background in accounting and nothing else. Believe it or not, squeezing the last precious, tasty drop of profit from an endeavor is not the ultimate goal.

Elephants must not like Tom Siebel

[gemtech]

An AP article this morning just came out with: "Software mogul attacked by elephant during safari."
http://www.google.com/hostednews/ap/article/ALeqM5hRZi6dDUIs98KnY1D7uGJy4buIxwD9AFPOQ80/
Maybe it was this book.

Re:Biggest Gripe about coding .. shouldn't be code

[Anonymous Coward]

You Bastard

I could get fired for laughing so much - Thanks to you and INTERCAL.
Why have I never heard of INTERCAL before?

I love the please do syntax, and how the compiler ignores errors and the numbering system - heavens above.
The only thing that seems to be missing is the famous OR ELSE statement.

Re:Biggest Gripe about coding .. shouldn't be code

[lgw]

You're the one! You're the jerk who replaced all the fun games of days gone by with the photorealistic boredom fests of today! Ha, we found you!