The thing my teachers hammered since day one of signing up for comp-sci was that programmers needed to know math. Math was of the utmost importance!
You can pretty much figure how well I did, coming from a background of philology and foreign languages.
Nonetheless, this opinion was shared by most of my colleagues as well, but in different forms. Some would stress the importance of math and remembering formulas. Others would scoff at disciplines such as literature or grammar or at the need for programmers to speak in actual words, for lack of a better term.
As a side note, I had my best time while we actually studied programming language grammar and I saw them choking on their words. Some just couldn’t understand why they’re supposed to study linguists such as Noam Chomsky, in computer science…
But, there’s more communication going on, even for programmers and more often than not, it is completely missed. This leads me to the first thing uni failed to teach me.
You see, one of the implicit ways we communicate with our peers is through the code we write.
The codebase is the best place for people to go and learn what something is or does. And this can be gleaned from looking directly at the source but very often, the first contact people have with someone else’s code is through the place where it is integrated.
It means that the first thing they sees the API —the names of functions, methods, REST endpoints.
Unfortunately school is pretty focused on theory and math. Everything is explained through math.
In math, naming is simple: s is a sum, x is an unknown variable, i is an increment/iteration step, and let’s just not talk about Greek alphabet notation.
Ultimately, this results in people joining the workforce who are incapable of communicating meaning. Literally impaired.
Then there’s debugging.
For me, other than hearing the words “call stack” and “stack trace” which, believe me, don’t translate well to Romanian, I was clueless about what they actually were. The only moment I actually looked at errors and exceptions with the purpose of understanding them was in my 2nd year in uni, when we studied Java and got to Exceptions. That was for a total of 4 hours spread over 2-3 weeks.
Unfortunately, I see errors for the better part of every workday. It could be just me, or the job, but most of the time I spend it making “red stuff” go away from the console.
So an understanding of application flow(s), breakpoints, tools that one might use and maybe a couple of examples, would’ve served me a great deal getting started.
Testing is another important aspect left to chance by formal education. I mean, yeah, we test when we compile the code and it passes. We test again when we pass input and get the correct output. But that’s not testing for the internal correctness of the code.
I believe that minimal exposure to methodologies such as automated testing, TDD, BDD and an explanation of the advantages would suffice. Paired with a couple of small workshops for testing, in 2-3 languages and frameworks, it would work wonders.
The last piece is collaboration tools. Code versioning.
You can pretty much figure how well I did, coming from a background of philology and foreign languages.
Nonetheless, this opinion was shared by most of my colleagues as well, but in different forms. Some would stress the importance of math and remembering formulas. Others would scoff at disciplines such as literature or grammar or at the need for programmers to speak in actual words, for lack of a better term.
As a side note, I had my best time while we actually studied programming language grammar and I saw them choking on their words. Some just couldn’t understand why they’re supposed to study linguists such as Noam Chomsky, in computer science…
But, there’s more communication going on, even for programmers and more often than not, it is completely missed. This leads me to the first thing uni failed to teach me.
You see, one of the implicit ways we communicate with our peers is through the code we write.
The codebase is the best place for people to go and learn what something is or does. And this can be gleaned from looking directly at the source but very often, the first contact people have with someone else’s code is through the place where it is integrated.
It means that the first thing they sees the API —the names of functions, methods, REST endpoints.
Unfortunately school is pretty focused on theory and math. Everything is explained through math.
In math, naming is simple: s is a sum, x is an unknown variable, i is an increment/iteration step, and let’s just not talk about Greek alphabet notation.
Ultimately, this results in people joining the workforce who are incapable of communicating meaning. Literally impaired.
Then there’s debugging.
For me, other than hearing the words “call stack” and “stack trace” which, believe me, don’t translate well to Romanian, I was clueless about what they actually were. The only moment I actually looked at errors and exceptions with the purpose of understanding them was in my 2nd year in uni, when we studied Java and got to Exceptions. That was for a total of 4 hours spread over 2-3 weeks.
Unfortunately, I see errors for the better part of every workday. It could be just me, or the job, but most of the time I spend it making “red stuff” go away from the console.
So an understanding of application flow(s), breakpoints, tools that one might use and maybe a couple of examples, would’ve served me a great deal getting started.
Testing is another important aspect left to chance by formal education. I mean, yeah, we test when we compile the code and it passes. We test again when we pass input and get the correct output. But that’s not testing for the internal correctness of the code.
I believe that minimal exposure to methodologies such as automated testing, TDD, BDD and an explanation of the advantages would suffice. Paired with a couple of small workshops for testing, in 2-3 languages and frameworks, it would work wonders.
The last piece is collaboration tools. Code versioning.