Translation of the article by Bjarn Straustrup “What should we teach new software developers? Why? ”
The January issue of Communications of the ACM published a short article by Uncle Stroustrup about problems in teaching computer science. The article is far from indisputable and, of course, strongly focused on American society, but interesting and quite relevant for us. I offer a translation (somewhat artistic, but close to the original) to your attention and discussion, wishing to improve it - welcome here.
In order for the industry to live better, we need fundamental changes in the teaching of computer science.
')
Informatics should be in the center of software development, otherwise we should rely on individual experience and rules of thumb, getting less productive and reliable systems with prohibitively high development and maintenance costs.
In many places, there is a gap between what industry needs and what university programmers teach. For example:
The famous professor of computer science, proudly: "We do not teach programming, we teach computer science."
The manager from the industry: “They cannot program the most elementary thing!”
In many cases both are right, and not only at first glance. It is not a university business to produce average programmers, but the industry needs not only "high-level thinkers with a broad outlook" and "scientists."
Another professor of computer science: "I never program."
Another manager: “We do not hire graduates of the computer science department. It is easier to teach physics to program than to teach physics to graduates of this department. ”
Both of them are right in some way, but in an ideal world both would be fundamentally wrong. The professor is wrong because it is impossible to teach what you do not practice (and in many cases never practiced), and therefore you do not understand, while the manager is right only when the requirements for software quality are so low that Physicists and other people not trained in computer science can do it. I, of course, do not mean those physicists who spend a lot of effort on computer science - such a set of qualities would be ideal for me.
Computer science professor (about student): “He got a job in industry.”
Another professor of computer science: "It's a pity, because he showed great promise."
This discrepancy underlies many problems, and complicates attempts to fix them.
The industry wants graduates of the computer science department to program, at least at the beginning of their careers. Often, they have to work with the long-established source of some distributed or embedded system with high reliability requirements. Many graduates, however, have practically no knowledge or software development skills, with the exception of some amateur entertainment. In particular, many consider programming as homework with minimal effort and rarely think about deeper things, such as systematic testing, support, documentation, and the use of written code by other programmers. Many are also unable to combine what they learned in one lecture with what was said in another, and we often see students with good grades in algorithms, data structures, and software engineering, which, nevertheless, are in the classroom for operational systems bydlokodyat with absolute disregard for all the same algorithms, data structure and code. As a result, we get brake and poorly maintained porridge.
For many, “programming” has become a strange combination of unprincipled hacking and the use of other people's libraries (with a very vague idea of what is actually happening). The concepts of "support" and "code quality", as a rule, are forgotten or not completely understood. In industry, complaints about the difficulties of finding graduates who understand “systems” and “can design software” are already familiar and reflect reality.
Complaining about software is quite fashionable, but over the past decade, many programs have improved, just as they have improved in previous decades. Unfortunately, we pay a huge price for improvement with human and machine resources. We, in general, have learned to build relatively reliable systems from unreliable parts by adding infinite layers of checks during program execution and mass testing. The structure of the code itself sometimes changed, but not always for the better. Often, multi-layer software and complex dependencies interfere with the programmer, be he at least seven spans in his forehead, to fully understand the system. This does not bode well for us, because we do not understand and cannot even measure the critical aspects of our systems.
Of course, there are engineers who have resisted the desire to build bloated, poorly understood systems. They should be thanked when our computerized airplanes do not fall, when the phones are working and the mail arrives on time. They deserve thanks for their efforts to turn software development into a mature and reliable set of principles, tools and technologies. Unfortunately, their minority and bloated software dominates the sensations and thoughts of many people.
Similarly, there are teachers who struggle with the abyss between theory and industrial practice. And they also deserve support and gratitude. In fact, all educational institutions that I know strive to teach practical knowledge and there are professors who have dedicated their lives to the promotion of some individual programs. However, the larger picture is not at all impressive. A couple of projects or internships is a good start, but not a substitute for a full-fledged approach to a balanced curriculum. The preference for “informatics” of the labels “software engineering” or “information technology” may speak about differences in perspective, but problems have a vile property to manifest themselves in new guises and after a change of scenery.
My images of “industry” and “scientific community” are close to caricature, but I am sure that everyone who has at least a modicum of experience will see a reflection of reality in them. My perception is the perception of an industrial researcher and manager (24 years in the laboratories of AT & T Bell, 7 of them as head of the department), who spent the last 6 years at the university (at the computer science department of the engineering department). I travel a lot and every year I have serious discussions with technical and management people from several dozen companies, mainly from the USA. I consider the discrepancy between what universities produce and what production needs, a threat to both the viability of computer science and the computing industry.
What do we do? Industry would prefer to hire "developers" fully trained on the latest tools and technologies, while the highest ambition of science is the production of the best scientists in large quantities. In order for us to have progress, these ideals need to be better aligned. Graduates entering the industry should have a good understanding of software development and the industry should develop significantly better mechanisms for absorbing new ideas, tools and techniques. It makes no sense to insert a good developer into a culture adapted to protect against the harm done by semi-educated coders, because it will be difficult for a new developer to do something substantially new and better in it.
Let me point out the problem of scaling. Many industrial systems consist of millions of lines of code, while a student can receive a red diploma in computer science without ever writing a program longer than a thousand lines. In all large industrial projects, many people are involved, while many computer science training programs value individual work, essentially hindering group work. Understanding this, many organizations simplify tools, technologies, languages, and operating procedures in order to minimize dependence on developer qualifications. It is simply a waste of human talent and labor, because it reduces each and everyone to the lowest common denominator.
The industry wants to rely on time-tested tools and technologies, but at the same time is prone to dreams of silver bullets, magic bubbles, killer apps, and so on. She wants to be able to work with interchangeable coders with minimal qualifications, headed by "architects", too serious to take care of such trifles as the quality of the code. This leads to excessive conservatism in the choice of basic tools (such as programming languages and operating systems) and to monoculture (to minimize the cost of training and development). In turn, this leads to the emergence of huge proprietary mutually incompatible infrastructures. You need something that goes beyond elementary tools, so that developers can write applications, while platform vendors want to somehow tie developers, despite the common basic tools. Incentive systems reward both grand corporate schemes and short-term results. As a result, both the costs and the number of unsuccessful new projects are staggering.
Faced with industrial realities and other obstacles, science returns to itself and does what it does best: it carefully studies the phenomena with which a small group of similar people can work in isolation, builds solid theoretical foundations and designs perfect designs and techniques for spherical horses in a vacuum. This model does not fit proprietary tools for working with huge amounts of source code written in an archaic style. Like industry, science invents appropriate incentive schemes. All this fits perfectly into the constant improvements of courses in well-defined scientific subjects that fly into the pipe. Thus, scientific advances are suitable for industrial needs as well as a square spigot round hole, and the industry must bear the cost of training, as well as the cost of a specialized infrastructure.
There will always be someone who thinks that if the industry paid programmers decent wages, then there would be no problem. This may make sense, but simply paying more for the same work will do little to help, because the industry actually needs better developers. The idea of developing software like a pipeline, served by low-skilled, interchangeable workers, is fundamentally flawed and unsuitable. It pushes the most competent people out of this sphere and does not encourage students to study such a science. In order to break this vicious circle, more graduates with adequate skills should come out of universities, and the industry should adopt the tools, techniques, and processes that can use these skills.
“Computer science” ( Computer Science, still translated in this text as “computer science” is my note ) is a terrible and misleading term. Basically it is not about computers and basically it is not a science. Rather, we are talking about the use of computers and ways of working and thinking, implying computation ("algorithmic and computational mindset"). It combines some aspects of science, mathematics, and engineering, often with the use of computers. For almost all the people involved in it, computer science is an applied field. "Pure Informatics," apart from applied use, is usually barren.
What is the difference between two people constructing an application, one of whom knows computer science, and the second is a professional in some other field, such as medicine or physics? Must be, the first perfectly knows the fundamental principles, the "core" of computer science. What could it include? Most of the established IT course is algorithms, data structures, computer architectures, programming principles, some mathematics (mainly for logical and numerical thinking) and computer systems (operating systems, for example, or DBMS). To put all this knowledge together and get an idea of how to work with large tasks, each student must participate in several group projects (you can call this elementary software engineering). It is essential that there should be a balance between theory and practice. Informatics is not only principles and theorems and not only stupid coaching.
This core is obviously much more computer-oriented than computational science in general. We, therefore, cannot call anyone a computer scientist without adding specialization (for example, graphics, networks, software architecture, human-machine interaction, security). But this is not enough. Practical informatics is inherently applied and interdisciplinary, so every professional in informatics should have some non-core education in some other field (for example, in physics, medical engineering, history, accounting or French literature).
Experienced teachers can exclaim: “But this is impossible! Which student can learn all this in four years? ” They are right: something must be sacrificed. I propose to make a master's degree first, giving the right to practice as a computer scientist, with a real master's degree, rather than a bachelor's degree, with a final year or two attached. Those who plan to continue to engage in research will, as always, seek to obtain a candidate degree.
Many professors will say: “I don’t have time to program!” I, however, believe that professors teaching students who want to become professional developers should find time to program, and institutions to find the means to reward such professors. The primary task of computer science should be to help produce the best systems. So you would entrust the teaching of surgery to someone who has not seen a single patient for many years? What would you think about a piano teacher who never touched the keyboard? Studying computer science students should go beyond reading the necessary books, towards improving their application in the whole system and towards a sense of aesthetics of the code.
I use the word "professional." He has many meanings and meanings. In industries such as medicine and engineering, it implies licensing. Licensing is a very subtle and emotional topic. But after all, our civilization depends on software. Is it reasonable that anyone can change the critical part of the code based only on their own taste and corporate policy? Even if it is, will it still be reasonable after 50 years? Is it reasonable that software, on which millions of people depend, has no guarantee? In fact, the problem is that licensed professionalism depends on the availability of a large mass of publicly available knowledge, tools and technologies. A licensed engineer can confirm that the building was built using common materials and technology. I do not know how to do the same for software in the absence of a generally accepted competency scheme in computer science. Today, I don’t even know how to select a group of people to develop a licensing exam (or, more realistically, a set of exams for different specializations, similar to the medical board).
What can the industry do to close the gap? Characterizing “industry” and “industrial needs” is much more difficult than talking about science. In the end, scientific institutions have a fairly standard structure and approaches to achieving goals. Industrial enterprises are much more diverse: large and small, commercial and not-so, advanced approaches in building their systems and so-so and so on. I, therefore, cannot even begin prescribing medicine. I, however, have one observation directly related to the gap between science and industry: many organizations that are critically dependent on computing have dropped to a dangerously low technical level.
Industrial manager: “if you want to survive, don't show your technical skills to anyone”
An organization cannot remain successful without a corporate memory and infrastructure for finding and developing new talents. Closer interaction with scientists interested in software development can be productive for both parties. This can play a major role joint research and an emphasis on long-term learning that goes beyond simple training courses.
We have to get better. Until we do this, our infrastructure will squeak, swell and absorb resources, and one day something will break down in the most unpredictable and destructive way (think of routing to the Internet, online banking, electronic voting and grid management). In particular, we must narrow the gap between science and industry, changing both sides. I propose to establish the structure of computer education, based on the core with specializations and application areas, seeking to license software products and at least some of their professional computer scientists. This can go hand in hand with the long-term support of technical experts from science and industry.
What you need to teach young programmers and why.
In order for the industry to live better, we need fundamental changes in the teaching of computer science.
')
Informatics should be in the center of software development, otherwise we should rely on individual experience and rules of thumb, getting less productive and reliable systems with prohibitively high development and maintenance costs.
What is the problem.
In many places, there is a gap between what industry needs and what university programmers teach. For example:
The famous professor of computer science, proudly: "We do not teach programming, we teach computer science."
The manager from the industry: “They cannot program the most elementary thing!”
In many cases both are right, and not only at first glance. It is not a university business to produce average programmers, but the industry needs not only "high-level thinkers with a broad outlook" and "scientists."
Another professor of computer science: "I never program."
Another manager: “We do not hire graduates of the computer science department. It is easier to teach physics to program than to teach physics to graduates of this department. ”
Both of them are right in some way, but in an ideal world both would be fundamentally wrong. The professor is wrong because it is impossible to teach what you do not practice (and in many cases never practiced), and therefore you do not understand, while the manager is right only when the requirements for software quality are so low that Physicists and other people not trained in computer science can do it. I, of course, do not mean those physicists who spend a lot of effort on computer science - such a set of qualities would be ideal for me.
Computer science professor (about student): “He got a job in industry.”
Another professor of computer science: "It's a pity, because he showed great promise."
This discrepancy underlies many problems, and complicates attempts to fix them.
The industry wants graduates of the computer science department to program, at least at the beginning of their careers. Often, they have to work with the long-established source of some distributed or embedded system with high reliability requirements. Many graduates, however, have practically no knowledge or software development skills, with the exception of some amateur entertainment. In particular, many consider programming as homework with minimal effort and rarely think about deeper things, such as systematic testing, support, documentation, and the use of written code by other programmers. Many are also unable to combine what they learned in one lecture with what was said in another, and we often see students with good grades in algorithms, data structures, and software engineering, which, nevertheless, are in the classroom for operational systems bydlokodyat with absolute disregard for all the same algorithms, data structure and code. As a result, we get brake and poorly maintained porridge.
For many, “programming” has become a strange combination of unprincipled hacking and the use of other people's libraries (with a very vague idea of what is actually happening). The concepts of "support" and "code quality", as a rule, are forgotten or not completely understood. In industry, complaints about the difficulties of finding graduates who understand “systems” and “can design software” are already familiar and reflect reality.
But lately, my computer is not hanging something.
Complaining about software is quite fashionable, but over the past decade, many programs have improved, just as they have improved in previous decades. Unfortunately, we pay a huge price for improvement with human and machine resources. We, in general, have learned to build relatively reliable systems from unreliable parts by adding infinite layers of checks during program execution and mass testing. The structure of the code itself sometimes changed, but not always for the better. Often, multi-layer software and complex dependencies interfere with the programmer, be he at least seven spans in his forehead, to fully understand the system. This does not bode well for us, because we do not understand and cannot even measure the critical aspects of our systems.
Of course, there are engineers who have resisted the desire to build bloated, poorly understood systems. They should be thanked when our computerized airplanes do not fall, when the phones are working and the mail arrives on time. They deserve thanks for their efforts to turn software development into a mature and reliable set of principles, tools and technologies. Unfortunately, their minority and bloated software dominates the sensations and thoughts of many people.
Similarly, there are teachers who struggle with the abyss between theory and industrial practice. And they also deserve support and gratitude. In fact, all educational institutions that I know strive to teach practical knowledge and there are professors who have dedicated their lives to the promotion of some individual programs. However, the larger picture is not at all impressive. A couple of projects or internships is a good start, but not a substitute for a full-fledged approach to a balanced curriculum. The preference for “informatics” of the labels “software engineering” or “information technology” may speak about differences in perspective, but problems have a vile property to manifest themselves in new guises and after a change of scenery.
My images of “industry” and “scientific community” are close to caricature, but I am sure that everyone who has at least a modicum of experience will see a reflection of reality in them. My perception is the perception of an industrial researcher and manager (24 years in the laboratories of AT & T Bell, 7 of them as head of the department), who spent the last 6 years at the university (at the computer science department of the engineering department). I travel a lot and every year I have serious discussions with technical and management people from several dozen companies, mainly from the USA. I consider the discrepancy between what universities produce and what production needs, a threat to both the viability of computer science and the computing industry.
The gap between theory and practice
What do we do? Industry would prefer to hire "developers" fully trained on the latest tools and technologies, while the highest ambition of science is the production of the best scientists in large quantities. In order for us to have progress, these ideals need to be better aligned. Graduates entering the industry should have a good understanding of software development and the industry should develop significantly better mechanisms for absorbing new ideas, tools and techniques. It makes no sense to insert a good developer into a culture adapted to protect against the harm done by semi-educated coders, because it will be difficult for a new developer to do something substantially new and better in it.
Let me point out the problem of scaling. Many industrial systems consist of millions of lines of code, while a student can receive a red diploma in computer science without ever writing a program longer than a thousand lines. In all large industrial projects, many people are involved, while many computer science training programs value individual work, essentially hindering group work. Understanding this, many organizations simplify tools, technologies, languages, and operating procedures in order to minimize dependence on developer qualifications. It is simply a waste of human talent and labor, because it reduces each and everyone to the lowest common denominator.
The industry wants to rely on time-tested tools and technologies, but at the same time is prone to dreams of silver bullets, magic bubbles, killer apps, and so on. She wants to be able to work with interchangeable coders with minimal qualifications, headed by "architects", too serious to take care of such trifles as the quality of the code. This leads to excessive conservatism in the choice of basic tools (such as programming languages and operating systems) and to monoculture (to minimize the cost of training and development). In turn, this leads to the emergence of huge proprietary mutually incompatible infrastructures. You need something that goes beyond elementary tools, so that developers can write applications, while platform vendors want to somehow tie developers, despite the common basic tools. Incentive systems reward both grand corporate schemes and short-term results. As a result, both the costs and the number of unsuccessful new projects are staggering.
Faced with industrial realities and other obstacles, science returns to itself and does what it does best: it carefully studies the phenomena with which a small group of similar people can work in isolation, builds solid theoretical foundations and designs perfect designs and techniques for spherical horses in a vacuum. This model does not fit proprietary tools for working with huge amounts of source code written in an archaic style. Like industry, science invents appropriate incentive schemes. All this fits perfectly into the constant improvements of courses in well-defined scientific subjects that fly into the pipe. Thus, scientific advances are suitable for industrial needs as well as a square spigot round hole, and the industry must bear the cost of training, as well as the cost of a specialized infrastructure.
There will always be someone who thinks that if the industry paid programmers decent wages, then there would be no problem. This may make sense, but simply paying more for the same work will do little to help, because the industry actually needs better developers. The idea of developing software like a pipeline, served by low-skilled, interchangeable workers, is fundamentally flawed and unsuitable. It pushes the most competent people out of this sphere and does not encourage students to study such a science. In order to break this vicious circle, more graduates with adequate skills should come out of universities, and the industry should adopt the tools, techniques, and processes that can use these skills.
Dreams of professionalism.
“Computer science” ( Computer Science, still translated in this text as “computer science” is my note ) is a terrible and misleading term. Basically it is not about computers and basically it is not a science. Rather, we are talking about the use of computers and ways of working and thinking, implying computation ("algorithmic and computational mindset"). It combines some aspects of science, mathematics, and engineering, often with the use of computers. For almost all the people involved in it, computer science is an applied field. "Pure Informatics," apart from applied use, is usually barren.
What is the difference between two people constructing an application, one of whom knows computer science, and the second is a professional in some other field, such as medicine or physics? Must be, the first perfectly knows the fundamental principles, the "core" of computer science. What could it include? Most of the established IT course is algorithms, data structures, computer architectures, programming principles, some mathematics (mainly for logical and numerical thinking) and computer systems (operating systems, for example, or DBMS). To put all this knowledge together and get an idea of how to work with large tasks, each student must participate in several group projects (you can call this elementary software engineering). It is essential that there should be a balance between theory and practice. Informatics is not only principles and theorems and not only stupid coaching.
This core is obviously much more computer-oriented than computational science in general. We, therefore, cannot call anyone a computer scientist without adding specialization (for example, graphics, networks, software architecture, human-machine interaction, security). But this is not enough. Practical informatics is inherently applied and interdisciplinary, so every professional in informatics should have some non-core education in some other field (for example, in physics, medical engineering, history, accounting or French literature).
Experienced teachers can exclaim: “But this is impossible! Which student can learn all this in four years? ” They are right: something must be sacrificed. I propose to make a master's degree first, giving the right to practice as a computer scientist, with a real master's degree, rather than a bachelor's degree, with a final year or two attached. Those who plan to continue to engage in research will, as always, seek to obtain a candidate degree.
Many professors will say: “I don’t have time to program!” I, however, believe that professors teaching students who want to become professional developers should find time to program, and institutions to find the means to reward such professors. The primary task of computer science should be to help produce the best systems. So you would entrust the teaching of surgery to someone who has not seen a single patient for many years? What would you think about a piano teacher who never touched the keyboard? Studying computer science students should go beyond reading the necessary books, towards improving their application in the whole system and towards a sense of aesthetics of the code.
I use the word "professional." He has many meanings and meanings. In industries such as medicine and engineering, it implies licensing. Licensing is a very subtle and emotional topic. But after all, our civilization depends on software. Is it reasonable that anyone can change the critical part of the code based only on their own taste and corporate policy? Even if it is, will it still be reasonable after 50 years? Is it reasonable that software, on which millions of people depend, has no guarantee? In fact, the problem is that licensed professionalism depends on the availability of a large mass of publicly available knowledge, tools and technologies. A licensed engineer can confirm that the building was built using common materials and technology. I do not know how to do the same for software in the absence of a generally accepted competency scheme in computer science. Today, I don’t even know how to select a group of people to develop a licensing exam (or, more realistically, a set of exams for different specializations, similar to the medical board).
What can the industry do to close the gap? Characterizing “industry” and “industrial needs” is much more difficult than talking about science. In the end, scientific institutions have a fairly standard structure and approaches to achieving goals. Industrial enterprises are much more diverse: large and small, commercial and not-so, advanced approaches in building their systems and so-so and so on. I, therefore, cannot even begin prescribing medicine. I, however, have one observation directly related to the gap between science and industry: many organizations that are critically dependent on computing have dropped to a dangerously low technical level.
Industrial manager: “if you want to survive, don't show your technical skills to anyone”
An organization cannot remain successful without a corporate memory and infrastructure for finding and developing new talents. Closer interaction with scientists interested in software development can be productive for both parties. This can play a major role joint research and an emphasis on long-term learning that goes beyond simple training courses.
Conclusion
We have to get better. Until we do this, our infrastructure will squeak, swell and absorb resources, and one day something will break down in the most unpredictable and destructive way (think of routing to the Internet, online banking, electronic voting and grid management). In particular, we must narrow the gap between science and industry, changing both sides. I propose to establish the structure of computer education, based on the core with specializations and application areas, seeking to license software products and at least some of their professional computer scientists. This can go hand in hand with the long-term support of technical experts from science and industry.
Source: https://habr.com/ru/post/80623/
All Articles