Conversions on the net: the professionalism issue
ACM SIGCSE Bulletin
A field study of the software design process for large systems
Communications of the ACM
Communications of the ACM
Accountability and computer decision systems
Communications of the ACM
ACM SIGCAS Computers and Society
The 'Question of Professionalism' in the Computer Fields
IEEE Annals of the History of Computing
Should software engineers be licensed?
Communications of the ACM
Programming is a part time job
SIGUCCS '75 Proceedings of the 3rd annual ACM SIGUCCS conference on User services
The impact of professionalization efforts on the computer manager (Panel)
ACM '71 Proceedings of the 1971 26th annual conference
Trust in Electronic Commerce: Definition and Theoretical Considerations
HICSS '98 Proceedings of the Thirty-First Annual Hawaii International Conference on System Sciences-Volume 4 - Volume 4
Focusing software education on engineering
ACM SIGSOFT Software Engineering Notes
Offshoring: finally facts vs. folklore
Communications of the ACM - Next-generation cyber forensics
Digital Rights Management, Spyware, and Security
IEEE Security and Privacy
A rational theory of system-making systems
ACM SIGSOFT Software Engineering Notes
The acquisition of expertise in software engineering education
FIE '98 Proceedings of the 28th Annual Frontiers in Education - Volume 03
The Grand Theory of Everything: what man-made systems are, and why they fail
ACM SIGSOFT Software Engineering Notes
Debugging debugged, a metaphysical manifesto of systems integration
ACM SIGSOFT Software Engineering Notes
Software maturity: design as dark art
ACM SIGSOFT Software Engineering Notes
An analysis of the common body of knowledge of software assurance
Proceedings of the 2010 ACM conference on Information technology education
Software assurance in academia
Proceedings of the 2010 ACM conference on Information technology education
The limits of systems-making organizations
ACM SIGSOFT Software Engineering Notes
| Hi-index | 0.00 |
The phrase "critical programmer" in this article's title is meant to be thought of as the programmer who carefully, respectfully, questions conventional wisdom. The particular conventional wisdom under consideration here (held mainly by those who do not write programs, as part of a team, for pay) to be critically thought about is the accountability of the software programmer, whether the programmer should alone be held strictly accountable for software faults, that if the programmer were provided a more rigorous education, if the programmer were to conduct him or herself in a more professional manner and held to a greater professional standard, that fewer software faults would result. The critical question is, is the premise valid? Should the programmer be the one solely held accountable for software faults? Would greater education and professionalism solve all software faults or only some, and if only some, then which ones? The critical analysis that follows investigates these as well as other radical questions, (radical as in "root", not as in "revolutionary"), such as: What is accountability? What is trust? What is professionalism? Where do software faults come from, and What can be done?