And guess what? It’s not the same as doing math either!
I guess someone finally noticed skills in language and math don’t correlate will with reading code. The article focuses on reading code, but does hint at the obvious, the same skills will be required to create code as well.
Turns out to reading code depends on something called the ‘multiple demand network’, not as much with language and math processing. I’d guess it’s largely what we call ‘problem solving’, since reading code is about understanding someone else’s solution to a problem.
As a life-long programmer, programming doesn’t really feel like language. It feels a little bit like math. It feels a whole lot like problem solving. It feels kind of the same if I’m writing a program or fixing the car, which I guess uses that same “multiple demand network”. Whatever computer language I’m using is just the set of tools I have in my toolbox to fix the problem I’m working on.
I wonder if this kind of research can be used to figure out who would make a good candidate for job retraining to be a programmer. I often think it’s a waste of money when some program tries to retrain unemployed factory workers or miners to be programmers because I feel it takes a certain kind of thinking to be a good programmer. Just teaching someone a computer language doesn’t make a good programmer any more than teaching someone to write a sentence makes them a novelist. But if these programs could pre-select those unemployed people based on who have good activation in this brain center, then these programs could be more successful and be a better use of the money.
We’ve had some pressure lately, in higher ed, to allow students to use courses in programming (usually called “coding” these days) to count as satisfying their foreign language requirements.
Even setting aside the obvious objection that “speaking” Python does little to make you an informed and capable traveler, researcher or global citizen, I’ve always argued that learning a foreign language is an important intellectual and brain-development exercise, and helps you understand your own language, in ways that programming just doesn’t do. (Nothing against programming. It’s still important! It’s just not the same as foreign language).
With the caveat, of course, that some miners and factory workers do have the right sorts of talents to be good programmers (or other white-collar professionals), but never before got the opportunity to develop those talents. I’m thinking, for instance, of my grandfather, who made his career as a steelworker, and left school after 8th grade, but who sometimes said that he would have liked to have been an engineer, and probably would have made a pretty good one.
On another point, I’m not sure that reading computer code and writing it are particularly related tasks, either. After all, computers are capable of meaningfully reading computer code (that’s the whole point of it, after all), but they can’t write it (queue arguments about what counts as “understanding” something, and whether computers do whatever it is).
My recollection of the history of computer programming (as well as my gut opinion from exposure to both) is that programming languages draw their heritage from mathematical notations. So I think yours is a valid observation.
When I read, I read for meaning. Spelling and logic errors are mostly invisible to me. Computer languages don’t work like that.
For the first couple of years, I tried to understand the programs I was reading and writing. Then I learned to just read the words, and ignore the context. I asked other programmers about this, and they told me that they had never tried to hold the whole program in their head
Joel Spolsky thought that ‘exceptions’ were a code smell, because exceptions offer an alternative hidden path for code logic. As do GOTO’s (kids: the probem isn’t the GOTO, it’s the ‘where from?’). They’re both things that mean that you have to be aware of the larger context, not just the words, sentence, paragraph and page. Same for operator overloading, and nested objects.
The whole of Comp. Sci. is a battle between the human part, where we try to adhere to conventions to allow ‘literate programming’, and the computer part, which is constantly providing us with opportunities to write things too complex for understanding.
I have always been fairly good at low level machine programming because I have the ability to, for lack of a better way of expressing the concept, “think like a machine”. A lot of programmers don’t. And in fact this ability works against me for certain other types of programming, especially object oriented programming.
There is also top-down type programming where you start with big concepts and then fill in the details as you go down, as well as bottom-up type programming which is more like laying bricks until you eventually come up with something that looks like a house. Both ways work, and both have their advantages and disadvantages.
The point is, there are a lot of different ways to program. Some programming languages and methodologies are designed to fit in with how humans think. Some are the exact opposite of that.
I am not at all surprised by the MIT study. I never thought programming and language were all that closely related. I know plenty of coders who aren’t that good at math, and I know plenty of coders (cough cough most engineers cough) who don’t have the greatest language skills. To me it has always been more like puzzle solving.
I happen to be good at math, and I think that math skills are important for certain types of programming. You need to understand formal logic to be able to do PLC ladder logic programming, for example, and a good understanding boolean of logic is a necessity for assembly code (IMHO). Object oriented programming requires more abstract thought and concept manipulation, which is going to activate different parts of the brain.
The fact that some folks are really good at some types of programming and completely suck at other types is a pretty good clue that there isn’t just one way to think about programming. This is why programmers gravitate towards the type of coding that fits their way of thinking.
Back in 1979 one of my students in my honors CS 101 class was a PhD student in English, who told me that her department allowed one of the three languages they were required to learn to be a computer language. That’s probably more useful than the computer language replacing the only language required, since it makes people think in a different way.
Very little of the massive amounts of code I’ve written has had any traditional math content, and when it did coding that math content was the easiest part of the code. I’m not including things like graph theory as math here - I did a lot more of that kind of thing.
I’ve read that many programmers are also good at music and visual things. Not me. The visual side of my brain is atrophied, the verbal side however is pretty well developed. I’ve never seen data structures graphically, I’ve always seen them as chunks of code. When I wrote code in my head (or rather when my subconscious did) I could basically just dump the code from my brain to the keyboard.
I would love to see a correlation with logical and critical thinking. I’d guess that would be more related than either math or natural languages.
One thing I found while working with some rather good engineers was that they seldom looked at all the cases, while I was a programmer was used to having to do this. I’d often ask what they wanted to have happen when one weird corner case or another came up. They seldom had thought of that. That’s where critical thinking comes in.
I almost became a musician (I play the guitar, keyboard, bass, drums, trombone, and other instruments) and quite a few of my co-workers are also musicians. There are plenty of folks in our office that aren’t musically talented, but musical ability does seem to be much more common than you’d expect.
I was fortunate enough to learn very early on that making something work was only half the job (or possibly a lot less than half). First you make it work. Then you make it idiot-proof. Then the world comes along and makes a better idiot, so it’s always a race.
The engineers I work with are always looking at all of the weird corner cases, but then we do industrial control where things tend to make an Earth-Shattering KA-BOOM if you don’t handle every possible case.
Code is not at all like language. Reading code is reading patterns in the code, and programming is often finding a pattern that’s been done before and adapting it to a new task. If you’re making some entirely new architecture, you’re creating that pattern for others to follow. I’d almost equate it with dressmaking - find a pattern that fits and use it, or more creatively make a new pattern.
I wouldn’t say that code skills are entirely unlike language skills. It’s more like language than, say, 3D design (another of my hobbies).
But yeah, it makes no sense to allow a programming language to substitute for a foreign language requirement, because whatever it is that you’re hoping to get out of that foreign language, code ain’t giving it.
On the other hand, I’ve seen someone on this board suggest, and I agree, that lawyers should be required to take a few programming courses, because legalese is a lot like programming languages: It doesn’t need to be easy, but it does need to be clear.
I would go even further, and say that the use of the word “language” to describe a particular programming notation is rather a misleading euphemism. While computers can certainly be enabled to execute complex tasks using English or other natural languages, formal general-purpose programming “languages” bear virtually no relationship to natural language of any kind. They are formal notations for directly or indirectly specifying the execution of machine instructions. They are specifications of a series of logical steps that, taken together, perform a particular task.
The other thing I might add is that in terms of the skill set involved in software development, there are different kinds of skills and a large software project will require all of them, embodied in different individuals, of which coding is only one part. For example, the skill set of a software architect is vastly different from the skill set of a coder. The architect may not necessarily be a good coder – or even have specific knowledge of the (possibly multiple) programming languages being used in the project. What he will have is a strong sense of abstraction, the ability to decompose the problem into well-structured modules or layers that constitute logical abstractions of subdomains of the problem space, which can be implemented and tested independently and which interact only through well-defined interfaces. The module development is then delegated to coding teams, consisting of people skilled in particular programming languages.
There will be other individuals whose skills lie, for example, entirely in testing methodologies. There will also be a project manager who, if he or she is any good, will possess both administrative and technical skills to guide the project to a successful conclusion on time and on budget. (I do not subscribe to the ridiculous notion that a project manager is purely an administrative function, and I’ve seen more than one disaster caused by a Dilbertian pointy-haired nitwit making decisions with no understanding of their technical implications). This is maybe getting a bit away from the main topic, but the point is that software development on any reasonably large scale is much, much more than just coding.
There’s interesting tidbits I gleaned reading these posts.
–Firstly, yes, I did excel at math problems. In fact, I vastly preferred “word problems” to conventional math problems, finding them generally easier.
–I conceptualize code at the design stage from a top-down sort of way. I also teach Java primarily these days, with an emphasis on high levels of design.
–Typos leap out at me. In my bouts of public speaking, I would have to make an effort to read misspelled words as-meant as opposed to as-written. I could entertain folks by reading whatever mangled text presented to me, exactly as it was written. Complexity did not matter.
Conversely, I tried to write a novel, and I got lost in the weeds of the plot.
I agree: computer ‘language’ is really instrucftions, while natural language is about communication and not commands.
I’m old enough to have started programming in assembler (besides Basic) and I believe that most computer languages are essentially only fancy forms of assembler.(1) The words of many computer languages ultimately translate to sets of assembler instructions in a fairly determinate manner.(2) The resemblance to natural language is only to make it easier on the programmer (the ‘speaker’). The computer would have a far easier time if you would use assembler (or even better, machine code). Computer languages are like putting pants on a robot.
In contrast, natural languages are aimed at the recipient, to make him understand the communication.
In both cases you do need to think about how the addressee is going to interpret what you are writing. But in the case of computers you need to understand how computers take instructions, which is different from how human beings think. As stated above, ‘think like a computer’ is indeed the most important part of good programming.
For lawyers drafting a contract the skill is to think like how the court would interpret the contract, as well as how the contract would behave in many different circumstances. I find that the latter part is indeed similar to programming, where you also often need to think about code to deal with a variety of circumstances.
(1) Prolog and Lisp etc. are exceptions.
(2) I know about the complicated optimization that takes place in modern compilers and interpreters, but for the sake of simplicity don’t go into that here.
It drives me crazy when I hear people say things they are going to take a class so they can “learn to code” as if programming is just a matter of writing down some code. Coding is the easiest and most fun part of programming (IMHO). The hard work is in the requirements and design.
