|
Mark:
you
are not a nice man ... :)
I
might add, tell them how to use the tools -
1.
code editing,
2.
compiling,
3.
reading a compile listing,
4.
running the debugger,
5. how
to nuke a test job that goes into a loop,
6.
give them a real listing and a change spec and have them find the the right
place to make the change
7.
show them how to look at the contents of a file using DFU, DSPPFM, SQL,
query/400, and query manager. Anything that can be submitted is
most important because then you can avoid the dreaded CFINT.
8. how
to find a spool file? a job log? Which job is mine? What is an
invocation stack? What files are open? Where is my output
queue?
9.
find someone for them to interview, the job is to write a specification - this
can't be objectively graded but it is real
10.
teach something about performance issues
11.
teach something about system architectures - 2-tier, 3-tier, n-tier and the
issues - this avoid the "deer in the headlights" look during vendor
presentations
12.
teach something about change control - most programming is
maintenance
13.
teach something about testing - most programmers are horrible testers.
0.02
Richard Jackson
|
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.