Can some of you professionals say a few words about the range of duties a 
programmer's job includes, and what sorts of positions/responsibilities 
exist?  I know the software development cycle looks something like

  analysis
  planning
  coding
  testing
  maintenance

Assuming that's a good enough classification, are those steps well 
separated?  E.g. code monkeys writing to spec for people that already did 
the analysis and planning.

Just trying to get a feel for some typical "typical day on the job"s, the 
range of qualifications, the role of the CSCI versus the two-year tech, 
etc.  Most programming-related job descriptions I've seen wanted the CSCI 
or sometimes e.g. an EE-- does anyone hire the two-year tech?

-- 
"I'm giving you the chance to look fate in those pretty eyes of hers
and say, 'Step off, bitch. This is my party and you're not invited.'"
   -- Chris Shugart, _Testosterone Magazine_

"Gregory L. Hansen" wrote:
> 
.... snip ...
> 
> Just trying to get a feel for some typical "typical day on the
> job"s, the range of qualifications, the role of the CSCI versus the
> two-year tech, etc.  Most programming-related job descriptions I've
> seen wanted the CSCI or sometimes e.g. an EE-- does anyone hire the
> two-year tech?

Arrive.  Discuss last nights game.
Go to coffee pot.  Wait for it to brew.  Get cuppa.
Turn on monitor.  Scratch rump.
Bring up code area in question.  Move cursor into it.
Take break.  More coffee.  Discuss tonights game.
Make change.  Save.  Compile.
Fix induced error.  Really should have put the semi in.
Save.  Compile.
So far so good.  Go to lunch.
Consider running it.  Nah - need more coffee first.
Run it.  It bombs.  Scratch rump.
Take out change.  Save.  Compile.
Run it.  Doesn't bomb, but still has the fault.  Scratch rump.
More coffee.  Discuss wimmen.
Stare vacuuosly at monitor.  Put in print statements.
Save.  Compile. 
Go home, bragging that you are getting close to the problem.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

Gregory L. Hansen wrote:

> Can some of you professionals say a few words about the range of duties a
> programmer's job includes, and what sorts of positions/responsibilities
> exist?  I know the software development cycle looks something like
>
>   analysis
>   planning
>   coding
>   testing
>   maintenance
>
> Assuming that's a good enough classification, are those steps well
> separated?  E.g. code monkeys writing to spec for people that already did
> the analysis and planning.

Many textbooks specify those activities, using terms that lead folks to
separate them in time or space. This is an unfortunate misconception.

Each of those activities is very hard, and requires the best input data.
However, if you separate duties, then you must somehow arrange to
communicate their inputs. When a titular Analyst writes specifications and
pass them to a Designer, the Analyst must not make mistakes. Then, the
Designer must feed back to the Analyst the results of their analysis.

If that were the only problem, it would be soluable. Write lots of memos.
The problem happens because each of those activities must feed information
into every other one.

Then, some shops appoint their Analysts with the authority to dispense
design goals. This adds even more trouble when it splits authority from
responsibility. If the coders have the responsibility to implement code, but
no authority to change the design based on feedback from their code, then
the cycle that feeds information back into the analysis breaks.

The fix is to perform those activities in tiny bits, all mixed together.

> Just trying to get a feel for some typical "typical day on the job"s, the
> range of qualifications, the role of the CSCI versus the two-year tech,
> etc.  Most programming-related job descriptions I've seen wanted the CSCI
> or sometimes e.g. an EE-- does anyone hire the two-year tech?

Sometimes they hire the dropouts. Don't bet on that, though...

My typical week starts by asking the people who use my program what feature
they need to see next. This is "requirements analysis". But I don't say
"please tell me all the features you are going to need next month". I ask
them, "If you could have only ONE feature out of me, what would it be? Which
feature will provide the most value?"

That is analysis, but I don't do it to /all/ the features, only the highest
priority ones.

Then I convert the requirement into a set of goals. That way, if by
Wednesday I have half of the goal finished, I can claim to be half-done the
feature.

Then I write a list of technical tasks. These may include aspects of
designing and coding, and they _always_ represent things that can be tested.

Then, for each task, I write an automated test and check that it fails. When
it fails for the correct reason, I change the code to make it pass. This
effort generates information that applies variously to analysis, planning,
designing, more testing, and maintenance. And I never add behaviors to the
code without a failing test.

I might push more technical tasks onto my list. Some I will never get around
to. They are not the goals.

During the week, I frequently demonstrate the features to my users, to make
certain we agree on what they will get. By the end of the week, I have
approached the goals, and I can always provide a new version of the program
that is more useful than it was before.

Then I release this program to my (in house) users, right there, at the end
of the week. The best "analysis" is giving users a productivity boost and
collecting its rewards. They will now have a _much_ better idea what feature
to request next. (And the program has a very, very low defect rate, due to
all the automated tests, written at the same time as design.)

Because my product is always in use, while I upgrade it, my product is
always in maintenance. I never need to guess how to deploy it, or guess what
form it will arrive on my users desktops. I _started_ the product by
building this supply chain, and I grow the supply chain _with_ the program.
I don't grow the program for a long time and defer learning how to deploy
it.

Many non-in-house projects follow essentially this scheme, of weekly
iterations. Those that cannot deliver to live users, weekly, will at least
deliver to proxy users.

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

"Gregory L. Hansen" wrote:
> 
> Can some of you professionals say a few words about the range of duties a
> programmer's job includes, and what sorts of positions/responsibilities
> exist?  I know the software development cycle looks something like
> 
>   analysis

Ook.

>   planning

Oook.

>   coding

Ook.

>   testing

Ook-ook.

>   maintenance

Ook.

> 
> Assuming that's a good enough classification, are those steps well
> separated?  E.g. code monkeys

EEEK!

CBFalconer wrote:

> Save.  Compile.
> So far so good.  Go to lunch.
> Consider running it.  Nah - need more coffee first.
> Run it.  It bombs.  Scratch rump.
> Take out change.  Save.  Compile.
> Run it.  Doesn't bomb, but still has the fault.  Scratch rump.
> More coffee.  Discuss wimmen.

You forgot "grumble about life obliquely on USENET". (-;

> Stare vacuuosly at monitor.  Put in print statements.
> Save.  Compile.
> Go home, bragging that you are getting close to the problem.

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

infobahn wrote:

> > Assuming that's a good enough classification, are those steps well
> > separated?  E.g. code monkeys
>
> EEEK!

Ee. Ee. Ee. Ook. Eek EEEK EEEK EEEEEEK!

Ook ook.

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

In article <420D7ADD.9A6A2001@yahoo.com>,
CBFalconer  <cbfalconer@worldnet.att.net> wrote:
>"Gregory L. Hansen" wrote:
>> 
>... snip ...
>> 
>> Just trying to get a feel for some typical "typical day on the
>> job"s, the range of qualifications, the role of the CSCI versus the
>> two-year tech, etc.  Most programming-related job descriptions I've
>> seen wanted the CSCI or sometimes e.g. an EE-- does anyone hire the
>> two-year tech?
>
>Arrive.  Discuss last nights game.
>Go to coffee pot.  Wait for it to brew.  Get cuppa.
>Turn on monitor.  Scratch rump.
>Bring up code area in question.  Move cursor into it.
>Take break.  More coffee.  Discuss tonights game.
>Make change.  Save.  Compile.
>Fix induced error.  Really should have put the semi in.
>Save.  Compile.
>So far so good.  Go to lunch.
>Consider running it.  Nah - need more coffee first.
>Run it.  It bombs.  Scratch rump.
>Take out change.  Save.  Compile.
>Run it.  Doesn't bomb, but still has the fault.  Scratch rump.
>More coffee.  Discuss wimmen.
>Stare vacuuosly at monitor.  Put in print statements.
>Save.  Compile. 
>Go home, bragging that you are getting close to the problem.

Well that doesn't seem like a bad life.


-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of 
mind-boggling amounts of excrement when you least expect it. "
  -- Gene Spafford, 1992

Thats what they might do in a traditional office type environment.
Here is how my day is spent...

- Fight for 20 minutes over who gets to use the only G5 and then the
rest of us use the G4s

- Lead Devloper walks in late and gives his one of his famous speeches.
 Usually his "Responsiblity" speech or the one about "Deadlines"

- Code for 5 minutes

- Stop and tell computer stories

- Make fun of the Macs

- Code for 5 minutes

- Ram our wheely chairs into each other

- Code for 5 minutes

- Complain to the editors about placing the text files in the proper
folder

- Put an ice bag over your black eye after the fight with the editors
while they continue their speech on how they work so hard and how they
never have time to mess with the file location

- Watch in sheer irony how the editors go back to wasting time doing
stuff like playing computer games or watching movie trailers

- Repeat the last two steps with the yearbook staff because we leech
off their budget

- Code for 5 minutes

- Listen to yet another famous speech from your lead developer about
how his responsibilies are more important than our own and if he screws
up its because he is too busy but if we screw up, we need to manage our
time better

- Have the editors threaten to kill us if we don't fix the printer or
tell them how to scan pictures

The End!  Its an "interesting" life.

In article <1108260980.302240.305970@z14g2000cwz.googlegroups.com>, 
darkhack@gmail.com says...
> Thats what they might do in a traditional office type environment.
> Here is how my day is spent...
> 
> - Fight for 20 minutes over who gets to use the only G5 and then the
> rest of us use the G4s
> 
> - Lead Devloper walks in late and gives his one of his famous speeches.
>  Usually his "Responsiblity" speech or the one about "Deadlines"
> 
> - Code for 5 minutes
> 
> - Stop and tell computer stories
> 
> - Make fun of the Macs
> 
> - Code for 5 minutes
> 
> - Ram our wheely chairs into each other
> 
> - Code for 5 minutes
> 
> - Complain to the editors about placing the text files in the proper
> folder
> 
> - Put an ice bag over your black eye after the fight with the editors
> while they continue their speech on how they work so hard and how they
> never have time to mess with the file location
> 
> - Watch in sheer irony how the editors go back to wasting time doing
> stuff like playing computer games or watching movie trailers
> 
> - Repeat the last two steps with the yearbook staff because we leech
> off their budget
> 
> - Code for 5 minutes
> 
> - Listen to yet another famous speech from your lead developer about
> how his responsibilies are more important than our own and if he screws
> up its because he is too busy but if we screw up, we need to manage our
> time better
> 
> - Have the editors threaten to kill us if we don't fix the printer or
> tell them how to scan pictures

I think I understand why so much work is being outsourced now.

-- 
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
 to do smart ones too." -- Andrew Koenig