Linked by Jesse Smith on Wed 14th Apr 2010 21:00 UTC
General Development Ms. Z. Arsenault is an IT consultant working in the depths of a large North American energy company. She's one of those brave souls who works away in the background, keeping the servers running, making sure all the pieces fall properly into place so when the employees wander in each morning their applications run as expected. It's often a busy job just keeping things on a steady path. But Ms. Arsenault and her team aren't just maintaining the status quo, they're also trying to improve performance and cut costs while maintaining a stable environment for the end user. This week I had the opportunity to talk with Ms. Arsenault about what's she's been up to in the depths of corporate IT.
Thread beginning with comment 419200
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: I will risk it
by StephenBeDoper on Thu 15th Apr 2010 19:47 UTC in reply to "RE[2]: I will risk it"
Member since:

I got bolloxed at work for "wasting time" writing Javadocs today ... I kid you not.

A programmer I've worked with used to say "everyone wants documentation, no one wants to pay for it."

Reply Parent Score: 3

RE[4]: I will risk it
by renhoek on Fri 16th Apr 2010 16:25 in reply to "RE[3]: I will risk it"
renhoek Member since:

I'll pick properly coupled code with good descriptive variable names over the average javadocced code anyday.

Javadoc describes your attributes, which is a good thing if you are coding an api. But to use it to make somebody understand your code it's useless. it does not describe the structure and logic behind your classes.

I've seen too many getFoo() functions with the the javadoc comment "gets foo". Try to pick you variable, class and method names so they don't need any javadoc.

Reply Parent Score: 2

RE[5]: I will risk it
by lucas_maximus on Sat 17th Apr 2010 13:14 in reply to "RE[4]: I will risk it"
lucas_maximus Member since:

I agree; our coding standard requires us to do what you have described, but I always try to use descriptive names...

... however I like to describe what the method does before even writing it, helps me think through the logic before I even start coding. Sometimes I write some pseudocode or draw a diagram, depends on what I am doing ultimately.

Reply Parent Score: 1