| Knowing the features of your language can expand your horizons. I had already been a programmer for years when JavaScript entered a new era, and I thought I knew a thing or two about computing. With time, I understood that what I had was a lot of memorised knowledge about specific systems. The layout of a Master Boot Record. The numbers to BIOS interrupt calls. Memory addresses. The transition from Pascal to C that I made at age 12 had only opened my eyes a little. I learned that there is no true distinction between a function and a procedure (subroutine), that statements and expressions are really two sides of the same coin, that a for() loop doesn’t have to enumerate anything, and that pointers, direct memory access and direct access to system calls are a very powerful tool. For the past 10 years, I found myself repeatedly involved in web development projects. I had minimal interest in JavaScript at first, viewing it as a toy language for simple automations, and I did most of the heavy lifting in PHP and Java Servlets. Gradually, as people began doing more and more “weird” stuff in it, I became more curious. That’s when I fell into the rabbit hole. Functional programming, map-reduce, lambda notation, closures, asynchronous code, generators, observables, applying argument lists to functions at runtime, destructuring assignments, spread notation, treating functions as behaviours you can pass around... Basically, stuff that modern JavaScript has borrowed from languages such as Lisp. It made me aware that there’s a distinction between computing as a Platonic ideal and computing as a practical discipline. Computing is a set of ideas about information and the logic of manipulating it. Computer science is a branch of mathematics and information theory. Computer programs are living equations, written in a notation rigid enough that a machine can read them and perform computations with them. I didn’t have that kind of perspective 10 years ago. My skill as a programmer has taken a very solid step up. Unfortunately, this has also made me overqualified, and I’m often in a situation where I’m doing work that just about any developer with a couple of years’ experience could pull off, and would learn much more from than me because they’ve never done it before. I’ve come to the conclusion that the jobs that require you to actually appreciate the nuances of computing and programming on this level are virtually non-existent. Most customers don’t care if the application software is a rotting carcass under the hood. They want it cheaply and quickly, and if it breaks, “That’s what computer programs do, isn’t it?” and then they pay someone to fix it. In most cases, the practical craft of programming is very far removed from that Platonic ideal I mentioned. I would argue that the craft of programming is in fact almost entirely unrelated to the field of computer science. Here is an analogy: Building elaborate cuckoo clocks involves a great deal of classical mechanics, but it doesn't teach you anything fundamental about physics. A watchmaker is not a theoretical physicist, even if his practical knowledge of the mechanical movement of small parts suspended in a mixture of oxygen and nitrogen in a narrow temperature range under the influence of the gravitational field of a particular planet may be quite excellent. |
Our current use of titles is loose and very imprecise, and serve as marketing more than anything else. I would like to see a formal distinction between the different roles.
Douglas Engelbart, Dennis Ritchie, Richard Stallman and Linus Torvalds are not "developers" or "programmers".
Engelbart was a "computer scientist" in the true sense of the word. His systems saw little practical application, but they enhanced our understanding of what computing machines could do.
Ritchie, Stallman and Torvalds are engineers. If they were in the car industry, they would be renowned engine and drive train engineers.
Your typical programming job, on the other hand, is equivalent to the title of "mechanic", "construction worker" or "craftsman".
Many people who enter the field don't actually want to be craftsmen, but since we are so poor at making the distinction, we get misunderstandings. There are retired programmers who worked in the business for 30 years who never quite understood why the job turned out to be so different from what they had imagined.
One consequence of making this distinction is that a hierarchy of exclusivity inevitably emerges from this. There are far more car mechanics than drivetrain engineers. Only so many people have the privilege of doing that.
I don't know if the supply of computer engineers and computer scientists is smaller or greater than the demand, but what I do know is that these jobs aren't the kind you find on a job site. They are found through networking, which requires you to have the right kind of network, which isn't possible for everyone who would be a good fit for the position.