Firstly, html/css are not programming languages though they are languages.
And as your link indicates there are other areas to get into
- Mobile apps (Android/IOS)
- Crypto and Blockchain
- Dozens other areas which are hot; that is to say where the jobs are
But where the jobs are and what gets you a job, especially a well-paid one, are far from being the same thing. That latter is usually called CS or principles of programming or software engineering… and other names (with nuanced distinctions).
I’ll stick to Programming-focused CS
- Causality Oriented
- Value Neutral
The last can be expanded again to Math, Engineering/technology and Language (linguistics).
Let me elaborate on each of these:
For a programmer, causality oriented thinking is a very basic requirement.
Its a bit easier if we start with the debugging process. You’ve done something. Its not working as desired. How do you go about correcting the fault. For that you’ve to follow a causal chain backwards: Z was unsatisfactory, Y causes/preceded Z. Is Y ok? If not from Y to … All the way back to the start C,B,A (the start if necessary)
So clearly debugging is about following backward causality. But even designing and programming is about causality. E.W. Dijkstra showed that it is backward causality driven backward leading to seeming forward flow. See
The very first COBOL program I wrote — about a 100 lines — gave me 300 errors! I was quite shaken. I fortunately discovered that I had forgotten an important mantra called
PROCEDURE DIVISION. Many of my classmates were less fortunate. I remember one that was particularly scarred by the editor
vi, the only available editor then. He exemplified what one wag has said about
vi, that it’s a program that either beeps or corrupts the file. For one who understands
vi this is a joke but for the noob it can be traumatic!
If he had understood a single word that defines
vi — modal — and spent half an hour understanding how modality defines
vi‘s behavior, his trauma would have vanished. Instead he chose to (try to) learn it by rote — i.e. non-causally — and found it traumatic.
This comes to the next point:
When you are given an error by a mechanical system do you get upset? Offended? Terrorized?
It’s amusing when it’s someone else in a movie. It’s not when it’s you. And its a choice.
Machines don’t think, they don’t choose, they don’t intend. We do these things — or at least should!
When you are a computer scientist, you don’t stop being a human being. So you of course have your thoughts, values, intentions. But you must keep them to yourself, and not impose them on inanimate objects! Easier said than done since we all know of being in the position of the man in the video above!
One of the challenges I face as a programming teacher is to convince students to Read the error message! For example in Python when you get an error you’ll usually get
(a) the error (exception name)
(b) the file/line where it occurred
(c) a trace of the preceding events — the causal chain — that led to that “event”.
If you read these details you can start following the causal chain backwards and locate and correct the problem. But if you are freaked out by the error as though someone scolded you, you’ll never get there. To not get freaked out you need to be neutral. And curious/interested.
Personal (controversial?) opinion
I believe you need to have an autistic streak to be a good programmer. Of course literally this is not true … there are obviously many good programmers who are not autistic. But I conjecture that they are good because they’re bimodal — i.e. they work in autist-mode when dealing with machines and human/empathic mode when dealing with human (and other) beings.
You don’t have to become Dr. Spock and use nothing but rationality everywhere.
What is non-negotiable is that you use pure rationality when dealing with machines.
Dijkstra, an idiosyncratic but great CS-ist and CS teacher, punchily made the case that CS should be approached and taught as though it’s a branch of pure formal math. See CACM for his view and the subsequent heated discussion.
While this is not exactly my opinion, I do believe that math is more central to CS than most practitioners/teachers believe.
My own view is more nuanced:
Classic accounts of (theoretical) CS are often based around the 3 pillars of CS:
(a) Automata (machines)
These 3 areas have 3 characteristic and quite contrasting modes of approach. CS-ists need to be fine with all three.
- Computation is math and is essentially about the infinite.
- Machines are finite and is where the engineering/technology considerations lie.
- Languages link the above two and is, for any programmer, the center-point where the action happens.
A programmer needs to be fine with all these modes of thinking.
Leave an answer