The Commentator
August 2, 2005 7:05 AM Subscribe
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.
Heh, aperantly it actualy parses the code and can come up with at least somewhat relevant comments (at least summing over for loops).
posted by delmoi at 7:18 AM on August 2, 2005
posted by delmoi at 7:18 AM on August 2, 2005
Sadly, if this were real, I'm sure programmers all over would actually use it.
posted by cmonkey at 7:25 AM on August 2, 2005
posted by cmonkey at 7:25 AM on August 2, 2005
Not funny, and I am a programmer.
Just. For. One. Second. I thought someone had saved the world.
cockfosters
posted by NinjaPirate at 7:40 AM on August 2, 2005
Just. For. One. Second. I thought someone had saved the world.
cockfosters
posted by NinjaPirate at 7:40 AM on August 2, 2005
some of the comments that thing apparently puts in are more relevant /useful than actual commenting I've seen real programmers use.
posted by darsh at 7:49 AM on August 2, 2005
posted by darsh at 7:49 AM on August 2, 2005
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.
posted by rocketpup at 7:55 AM on August 2, 2005
And the PairOn... um, I'm not sure I'd want to get that close to my pair. It might... uh... ruin my objectivity.
posted by rocketpup at 7:55 AM on August 2, 2005
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?
posted by grahamwell at 9:10 AM on August 2, 2005
posted by grahamwell at 9:10 AM on August 2, 2005
The chair or the concept? Yes and I don't know, respectively.
posted by yerfatma at 9:55 AM on August 2, 2005
posted by yerfatma at 9:55 AM on August 2, 2005
The concept of pair programming is real, though I've only seen it used in very isolated cases.
posted by mosch at 10:06 AM on August 2, 2005
posted by mosch at 10:06 AM on August 2, 2005
Great as long as it adds realistic comments like
// giant kludge or
// hah try to sort this one out
posted by nervousfritz at 10:07 AM on August 2, 2005
// giant kludge or
// hah try to sort this one out
posted by nervousfritz at 10:07 AM on August 2, 2005
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.
posted by gurple at 10:11 AM on August 2, 2005
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.
posted by gurple at 10:11 AM on August 2, 2005
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.
posted by nofundy at 10:26 AM on August 2, 2005
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.
posted by nofundy at 10:26 AM on August 2, 2005
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.
posted by hackwolf at 10:53 AM on August 2, 2005
Yay. {this is good}
posted by If I Had An Anus at 11:10 AM on August 2, 2005
posted by If I Had An Anus at 11:10 AM on August 2, 2005
...... 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.
*/
posted by countzen at 11:15 AM on August 2, 2005
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.
*/
posted by countzen at 11:15 AM on August 2, 2005
...... 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.
*/
posted by countzen at 11:19 AM on August 2, 2005
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.
*/
posted by countzen at 11:19 AM on August 2, 2005
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.
posted by Lectrick at 11:23 AM on August 2, 2005
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.
posted by Lectrick at 11:23 AM on August 2, 2005
Sorry, Letrick, I misunderstood that (and was trying to be helpful.)
posted by nofundy at 11:28 AM on August 2, 2005
posted by nofundy at 11:28 AM on August 2, 2005
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.
posted by 3.2.3 at 11:48 AM on August 2, 2005
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.
posted by 3.2.3 at 11:48 AM on August 2, 2005
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.
posted by hackwolf at 12:24 PM on August 2, 2005
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.
posted by hackwolf at 12:24 PM on August 2, 2005
i recently interviewed at a place that practices XP, so I got a kick out of the dual-chair. commentator rang true too :D
posted by jcruelty at 9:46 PM on August 2, 2005
posted by jcruelty at 9:46 PM on August 2, 2005
« Older Socrates is there, Socrates heads it in! Socrates... | Phillip Adams Newer »
This thread has been archived and is closed to new comments
posted by fungible at 7:15 AM on August 2, 2005