The application of the principles of Human factors engineering to the design of systems reduces human errors, increases productivity, and enhances safety, health and comfort when interacting with these systems. For a programming language, taking human factors into account appropriately means that the target group of language users (i.e. programmers) is sufficiently capable of performing their tasks in all phases of a program's life cycle, e.g., they are not cognitively overwhelmed, and the likelihood of misunderstandings or mistakes is reduced. However, they should neither be unnecessarily restricted or hindered in their work, because also this creates unnecessary extraneous cognitive load that exhausts the programmer's limited working memory capacity. Human working memory can hold only 3-5 "chunks" of information simultaneously. This is a well-documented, hard biological constraint; when programming languages impose excessive formalism, they force programmers to juggle more mental "chunks" than working memory can handle. Self-explanatory code (which includes avoiding incomprehensible abbreviations or confusing syntax) reduces the cognitive load on the programmer. Ada's explicit human factors principle states: "Code is read more than written"; over a program's lifetime, especially in large, long-lived systems, code is read orders of magnitude more often than it's written; Ada's formalism optimizes for the more frequent activity (reading and maintenance) at the expense of the less frequent activity (initial writing). As a language designer, you therefore have to find the right balance, which of course is a function of your target audience, and the primary activities they will perform with the language.