| 
 | 
| 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-2025 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.