Comments on: The Commentator

The Commentator

Lectrick — Tue, 02 Aug 2005 07:05:03 -0800

Time commenting could be time coding. Day in, day out, you pull off star moves: gnarly algorithms, wicked refactorings, stunning optimizations. Why should you stop and explain? Yes, you've got plodders on your team, but hey — youAreAStar and yourTimeIsExpensive. Time spent explaining, documenting, commenting — dude! — that's time you could be using to crank out yet more mind-altering code. Welcome The Commentator.

By: fungible

fungible — Tue, 02 Aug 2005 07:15:49 -0800

Funny, and I'm not even a programmer.

By: delmoi

delmoi — Tue, 02 Aug 2005 07:18:59 -0800

Heh, aperantly it actualy parses the code and can come up with at least somewhat relevant comments (at least summing over for loops).

By: cmonkey

cmonkey — Tue, 02 Aug 2005 07:25:35 -0800

Sadly, if this were real, I'm sure programmers all over would actually use it.

By: NinjaPirate

NinjaPirate — Tue, 02 Aug 2005 07:40:15 -0800

Not funny, and I am a programmer. Just. For. One. Second. I thought someone had saved the world. cockfosters

By: darsh

darsh — Tue, 02 Aug 2005 07:49:02 -0800

some of the comments that thing apparently puts in are more relevant /useful than actual commenting I've seen real programmers use.

By: rocketpup

rocketpup — Tue, 02 Aug 2005 07:55:11 -0800

I did desperately want to download it. Too bad it's April Fools Day-ware. And the PairOn... um, I'm not sure I'd want to get that close to my pair. It might... uh... ruin my objectivity.

By: ook

ook — Tue, 02 Aug 2005 07:57:05 -0800

I like the pair programming chair too.

By: grahamwell

grahamwell — Tue, 02 Aug 2005 09:10:05 -0800

What a nicely put together post. I laughed and learned something. Yes, there really is an Obfuscated PERL competition (any idea what the program does?). But pair programming, is this for real?

By: yerfatma

yerfatma — Tue, 02 Aug 2005 09:55:30 -0800

The chair or the concept? Yes and I don't know, respectively.

By: mosch

mosch — Tue, 02 Aug 2005 10:06:40 -0800

The concept of pair programming is real, though I've only seen it used in very isolated cases.

By: nervousfritz

nervousfritz — Tue, 02 Aug 2005 10:07:16 -0800

Great as long as it adds realistic comments like // giant kludge or // hah try to sort this one out

By: gurple

gurple — Tue, 02 Aug 2005 10:11:25 -0800

I'm with NinjaPirate... if only. Oh, if only. And if you could just get it to write up some long-winded technical docs based on the code... hot damn. I could take W-F off.

By: nofundy

nofundy — Tue, 02 Aug 2005 10:26:55 -0800

there really is an Obfuscated PERL competition (any idea what the program does?) Obsfucated PERL is not a program but (yet) another way of writing PERL code that is not read friendly. Other methods of writing PERL are more easily understandable (for all the VB script kiddies) but less compact. There is an Obsfucated PERL competition every year to see who can write the best program using the fewest characters. Automated commenting? :-) I wish.

By: hackwolf

hackwolf — Tue, 02 Aug 2005 10:53:25 -0800

The concept of pair programming is real, though I've only seen it used in very isolated cases. Count yourself lucky then. There's nothing quite as fun as being on a dev team that's having the whole XP package (including 100% pair programming) shoved down their throats by upper management. The Pairon should come with built-in electrodes for the therapy that both developers will need when the project is complete.

By: If I Had An Anus

If I Had An Anus — Tue, 02 Aug 2005 11:10:49 -0800

Yay. {this is good}

By: countzen

countzen — Tue, 02 Aug 2005 11:15:29 -0800

...... So sad... so sad... only if this were real... only if... And used UML too would be awesome.. /* *@description: someone wanted to tempt coders with this danged thingy.. *@usage: dude, read theread the comments it's not real. :( *@note: 'thingy' is the best way to describe all objects and created instances. */

By: countzen

countzen — Tue, 02 Aug 2005 11:19:41 -0800

By: Lectrick

Lectrick — Tue, 02 Aug 2005 11:23:25 -0800

First, thanks for the positive feedback, this is actually my first MeFi post. I couldn't help but note the usually high standards of posting present here and merely strove to meet it. Regarding the Commentator- I thought it was hilarious with lots of in-jokes, but then again, without geek cred, I am nothing ;) hackwolf: I think the XP method (or parts of it) have definite merit. Writing your unit test first is just a good idea long-term, as is keeping your client around (if economically feasible) in order to keep you focused on the actual problem (remember- clients want the hole in the wall, they don't care about the drill... but people building the drill tend to obsess over it), and I did pair programming on a couple of smallish projects that demanded 100% code accuracy and it was highly successful and very productive... but I could see it becoming a drag after a while if it was full-time, what with interpersonal differences, "space" expectations, strange smells, etc. I would modify it to say there should be at least a 10 min. break every hour where you are doing your own thing. I won't even talk about the "8 hours a day, that's it" work philosophy which is of course backed by productivity studies ("working long hours does not make you more productive"), yet which no corporations expect their staff to adhere to. Part of the reason pair programming may produce more, better code faster than 2 people working separately (other than sanity checks on each others' code) is this concept from psychology called "mere presence", which basically notes that many creatures (not just humans... even ants!) are more productive at a task merely by being in the presence of others of their kind (with some caveats... see linky). It also makes it more difficult to randomly websurf, check email, and basically get distracted from the task at hand, if someone is there working with you. This is especially effective with people with adult ADD/ADHD tendencies (probably a good portion of coders...) nofundy: Obsfucated PERL is not a program I think he was referring to the code in the obfuscated perl link that I linked to in the post.

By: nofundy

nofundy — Tue, 02 Aug 2005 11:28:27 -0800

Sorry, Letrick, I misunderstood that (and was trying to be helpful.)

By: 3.2.3

3.2.3 — Tue, 02 Aug 2005 11:48:56 -0800

There's nothing quite as fun as being on a dev team that's having the whole XP package (including 100% pair programming) shoved down their throats by upper management. what upper mgmt is this and are they hiring? i've never heard pf xp being embraced by mgmt. it's just what programmers have always done under the covers to deal with the heavyweight horseshit methodologies shoved down their throats by upper mgmt. pair programming works and works well. it will simply never be embraced by bean counters.

By: hackwolf

hackwolf — Tue, 02 Aug 2005 12:24:48 -0800

Lectric: Good post, thanks! I do not dispute that some, nay, many of the parts of the XP methodology have merit. I practice compulsive unit testing myself, and test-first coding and highly iterative development wherever possible, and pair programming where appropriate. However, if you listen to (or work with) XP zealots, you can find yourself using a process that is not appropriate to the project or your business model. This is bullshit, in my opinion - a successful dev team has a good flexible base process, good people who know that process and each other, and adjusts that process to suit the nature and needs of a particular customer. 3.2.3: My management did embrace it until the two biggest failures in the history of the organization happened on the projects where XP was being tried. Part of that was due to full-on XP being inappropriate to the type of project. In this case, XP was sold to management by one dev team, and management decided that it should be used with another dev team (the one I was on) because we were an extension to that first project, regardless of what we thought of the idea. XP fails, like any other dev process (waterfall or iterative) when used inappropriately, or as a panacea for other problems within the organization. In our case, pair programming was used when it wasn't needed, and the idea of continuous refactoring was used as an excuse to give my team a product for which the API was constantly changing. Also, I've heard a hell of a lot more resistance to the idea of enforced pair programming from programmers themselves than I have ever heard from management. As a programmer, I want the freedom to pair up when I feel it is appropriate, and work alone when I feel it is not. Any process that takes that freedom away from me is going to be met with intense resistance. It's not "the Man" keeping you down here - blame us developers too.

By: Galvatron

Galvatron — Tue, 02 Aug 2005 13:25:44 -0800

Heh. A well-crafted post, Lectrick.

By: UbuRoivas

UbuRoivas — Tue, 02 Aug 2005 21:04:03 -0800

Great post! Thanks! :D

By: jcruelty

jcruelty — Tue, 02 Aug 2005 21:46:07 -0800

i recently interviewed at a place that practices XP, so I got a kick out of the dual-chair. commentator rang true too :D