I once was the technical lead at a place where a CompSci degree (advanced preferred) was the norm. The project staff became divided into two groups, one which was the in-house staff with CompSci dgrees and those without (the division ocurred because in-house staff where administratively untouchable, resulting in that group being assigned their own code chunk to program anyway they preferred).
The CompSci degree'd inhouse(Insiders) staff advocated what they had worked with and championed techniques that their educations had given them. The outside (Outsiders) consulting staff were hired primarily because they had needed to learn programming on their own to get specific tasks done. The outsiders were goal oriented, the insiders were means oriented. None of the Outsiders had degrees in computer science, some had partially completed college degrees. Outsider degrees areas were electrical engineers, linguistics, sociology, and business real estate.
The Outsiders developed extremely robust debugging/optimization techniques which resulted in error-free code generation rates of about 150 statements per working day of productivity and had a debugging system built-in to a macro pre-processor that allowed anyone to quickly find and eliminate bugs. The macro pre-processor had debugging modes from trust nothing (testing new code) to minimal checking (for production executables).
The Insiders had very low code productivity where everyone did their own thing. Only the Insider who wrote some code could effectively develop it, resulting in major problems when Outsider code depended on Insider code. One memorable bug in Insider code took three weeks of intensive effort by the Outsiders to find where in the Insider code an error actually was.
The Outsiders controlled all of the interfaces, so they could permanently have code that never trusted any Insider code which resulted eventually in all Insider errors being detected as data structures and their contents were always checked coming and going between Insider and Outsider coding.
The net result was a 250,000 statement program (about half of which as comments) which ran for five years without a progamming error being encountered by end-users and which performed at near assembler-code performance levels (the system was developed pre-C era in Fortran) by taking advantage of compiler optimization techniques and replacement of most subroutine calls with in-line code.
Experience since then has indicated that programmers advocate what they have been educated in (e.g, inve$ted in), what they have used, or what is currently being paid most attention to by the trade press or coporate decision makers. The best programmers have turned out to be persons who learned programming to get something else done; the worst programmers where those who were defending the validity of their resume/C.V.
That experience has lead to the conlusion that most programming systems and languages do not place a design priority on maintainability by someone other than the developers. Also that most developers have minimal knowledge of cost-benefit trade-offs and related business matters.
Another major cause of problems is that top-level management being sold on operating system/development system/language/etc. combinations by very capable sales forces and hiring persons with experience in that combination whether or not it is doable.
The result of this is a very bad completed as initially budgeted and featured as initially promised record.
It is always worth your while to research the law before going to court and finding the precedents regarding your type of traffic stop. It is also worth your while to show up for an educational court session (the one before yours is scheduled) and see what the D.A. offers offenders in pre-court discussions and to see how the judges treat offenders and their stories.
Offering the judge a suspended plea (a.k.a. a plea bargin) that you would like to do an off-the-record supervised probation period of many months (where you keep your nose very clean) is well worth your while. Judges will cut short the "probationary" supervision period (their staff has enough to do) to something manageable like six months. If you think ahead, do your research and make this offer to the D.A. in writing, you are well ahead with the judge if a pre-arranged "probation" is presented to the judge by the D.A. (the judge hears enough stories every day). Make it clear in your offer that you want NO POINTS against your record (the insurance companies will be notified if there are points -- and they will NOT be amused).
This works very well unless you try to do this when your infraction interval is measured in weeks or months.
Copyright has becomes an indefinite license by holders, instead of expiring in set amount of time. If copyrights never expire, they will not get much respect.
Slashdot Mirror
I once was the technical lead at a place where a CompSci degree (advanced preferred) was the norm. The project staff became divided into two groups, one which was the in-house staff with CompSci dgrees and those without (the division ocurred because in-house staff where administratively untouchable, resulting in that group being assigned their own code chunk to program anyway they preferred).
The CompSci degree'd inhouse(Insiders) staff advocated what they had worked with and championed techniques that their educations had given them. The outside (Outsiders) consulting staff were hired primarily because they had needed to learn programming on their own to get specific tasks done. The outsiders were goal oriented, the insiders were means oriented. None of the Outsiders had degrees in computer science, some had partially completed college degrees. Outsider degrees areas were electrical engineers, linguistics, sociology, and business real estate.
The Outsiders developed extremely robust debugging/optimization techniques which resulted in error-free code generation rates of about 150 statements per working day of productivity and had a debugging system built-in to a macro pre-processor that allowed anyone to quickly find and eliminate bugs. The macro pre-processor had debugging modes from trust nothing (testing new code) to minimal checking (for production executables).
The Insiders had very low code productivity where everyone did their own thing. Only the Insider who wrote some code could effectively develop it, resulting in major problems when Outsider code depended on Insider code. One memorable bug in Insider code took three weeks of intensive effort by the Outsiders to find where in the Insider code an error actually was.
The Outsiders controlled all of the interfaces, so they could permanently have code that never trusted any Insider code which resulted eventually in all Insider errors being detected as data structures and their contents were always checked coming and going between Insider and Outsider coding.
The net result was a 250,000 statement program (about half of which as comments) which ran for five years without a progamming error being encountered by end-users and which performed at near assembler-code performance levels (the system was developed pre-C era in Fortran) by taking advantage of compiler optimization techniques and replacement of most subroutine calls with in-line code.
Experience since then has indicated that programmers advocate what they have been educated in (e.g, inve$ted in), what they have used, or what is currently being paid most attention to by the trade press or coporate decision makers. The best programmers have turned out to be persons who learned programming to get something else done; the worst programmers where those who were defending the validity of their resume/C.V.
That experience has lead to the conlusion that most programming systems and languages do not place a design priority on maintainability by someone other than the developers. Also that most developers have minimal knowledge of cost-benefit trade-offs and related business matters.
Another major cause of problems is that top-level management being sold on operating system/development system/language/etc. combinations by very capable sales forces and hiring persons with experience in that combination whether or not it is doable.
The result of this is a very bad completed as initially budgeted and featured as initially promised record.
It is always worth your while to research the law before going to court and finding the precedents regarding your type of traffic stop. It is also worth your while to show up for an educational court session (the one before yours is scheduled) and see what the D.A. offers offenders in pre-court discussions and to see how the judges treat offenders and their stories.
Offering the judge a suspended plea (a.k.a. a plea bargin) that you would like to do an off-the-record supervised probation period of many months (where you keep your nose very clean) is well worth your while. Judges will cut short the "probationary" supervision period (their staff has enough to do) to something manageable like six months. If you think ahead, do your research and make this offer to the D.A. in writing, you are well ahead with the judge if a pre-arranged "probation" is presented to the judge by the D.A. (the judge hears enough stories every day). Make it clear in your offer that you want NO POINTS against your record (the insurance companies will be notified if there are points -- and they will NOT be amused).
This works very well unless you try to do this when your infraction interval is measured in weeks or months.
Copyright has becomes an indefinite license by holders, instead of expiring in set amount of time. If copyrights never expire, they will not get much respect.