Having taught some introductory CS courses a few years ago, the amount of struggling with basic things like file naming, directory hierarchies, and even simple hardware use was a constant distraction.
On one memorable occasion, I had to help a student by turning on the monitor: he would sit down at a workstation, move the mouse and tap the keyboard, and seeing nothing show up on the monitor after a moment, go to another unoccupied one. I watched, without intervention, him try this with all the unoccupied workstations in the lab until he finally came to me and said, in an exasperated tone, "all the computers left are broken!" I lead him over to one, and upon pressing the power button on the monitor, the expression he made was quite unforgettable...
In the bad old days computers weren't wide spread but just by virtue of having one you would learn programming / tech skills. Today computers are everywhere but owning one doesn't teach you anything as fundamental functionality is hidden/locked away from the user in the name of being "consumer friendly".
I wonder if those born between 1988 and 2002 will be the last of the so-called naturally computer literate.
Makes you wonder what does computing mean to people nowadays.
The perception of what makes a viable CS major needs to evolve past what those born during the “Personal Computer” era think it should be.
looks like there is some truth in that ad
It sounds bizarre - because they were using an iPad/iPhone instead of a computer.
I do, but that's mainly because of working with older and/or more professional devices which don't (want to?) consume power even when technically off. But for the rest, yup, doesn't really happen that often.
there are no intuitive interfaces, only familiar ones
Most screens in the office, when 'off', look like a matte black box with a single clearly visible button with a dim light. You can claim it's familiar because nearly every techincal appliance has a power button, but on the other hand: I am quite sure if you'd give this thing to a homo sapiens or similar, arguably not familiar with a button, it would not take too long befoer that button would get pressed.
Or to put it the other way: users (future would-be programmers) are being distanced[sic] from how the machines work. Even at the most rudimentary level.
Frankly, I'm not surprised. Interfaces are systematically being dumbed down in the name of usability. Users may be buying powerful computers, but they are using appliances. Pieces of shiny machinery that, to all intents and purposes, work with magic. [Queue A.C. Clarke quote here.]
The immediate downside is that when the interface is dumbed down to the level of non-confusion for the large masses, the features that power users would find appealing are being stripped off.
Curiosity may have killed the cat, but what happens when curiosity itself is being killed?
But nowhere in that process did I know anything about IBM 360s, or how to program or run them. I more-or-less understood the mathematics involved in the data processing. And I could somewhat parse the Fortran. But I had no concept of anything like a directory hierarchy.
With an IBM XT 286, on the other hand, it was all in my face.
Now there's an interesting observation. I'm not quite sure whether you're right, but quite possibly.
Looking around my local libraries and bookstores, most of the books that deal with using personal computers do seem to be from the 90s/early 2000s era. The question is whether the decline in these books indicate that they are not needed any more, or that they are not wanted anymore (due to "hidden complexity")?
Earlier in the pre-PC age, for the hobbyists you had similar experiences with home computers like Tandy RadioShack, ZX spectrum, Commodore Vic-20 or 64, not to mention the Amigas and Ataris (and all the others I’m old enough to have forgotten).
Early Macs also let you mess around (and mess up) your system too.
It was an exciting time in computing indeed, but it did in no way start with the PC.
It was quite eye-opening to see that.
I replied "over the socket"
To which they replied, "Using REST over HTTP"
¯\_(ツ)_/¯
The issue is when they don’t provide context and expect you to list off some random framework or something.
Nope - sorry, looks like you're not a mythical unicorn!
"Why is a pothole round?" is a more objective question.
My theory: They're heavy, so making it a circle at least eliminates the need to "align" it when putting it back. You can basically just drag it using a hook and it'll slot itself into place.
The point here is more that a circle has the same diameter regardless of orientation. There's no way to rotate it to make it fit through a hole it couldn't before, like you can do with a rectangle.
The height of an equilateral triangle is about 87% of the length of one of its sides.
In particular from https://en.wikipedia.org/wiki/Prince_Rupert%27s_cube
> In geometry, Prince Rupert's cube (named after Prince Rupert of the Rhine) is the largest cube that can pass through a hole cut through a unit cube, i.e. through a cube whose sides have length 1, without splitting the cube into two pieces. Its side length is approximately 6% larger than that of the unit cube through which it passes. The problem of finding the largest square that lies entirely within a unit cube is closely related, and has the same solution.
That 6% larger is the key.
The only real constraint operating on manholes is that they fit the opening. Unless you can produce a design document specifying the requirements for the manhole you're looking at, there isn't really a "why".
https://www.youtube.com/watch?v=rFQgwwXOfR4
note: Watch the witch scene later in the film - there's a coconut and swallow at the start of it.
It took me 5 years of screwing around with Java, Python, and C++ "I want to help humanity" projects before I found that I really should just write small game clones in P5.js for fun. I'm a new stepdad, and if I want to be motivated to work on side projects in my tiny amount of free time, it's going to have to be a game.
Project: 80's game clone. Library: P5.js. Toolset: Notepad++, Python SimpleHTTPServer.
I cut my teeth on c++ on lab computers. I was crap at it. The compilation and debug cycle was slow and frustrating. I couldn't Google for answers on anything.
It's easier than ever to start programming, without any question, and so many batteries are included everything else is easier too.
People in some ways do expect more from their software now, and to help deliver all that there are tons of open source libraries available that can feel overwhelming at times, but that's moving the goalposts. Somebody learning to code doesn't need all that just to get something basic and interesting working. If you're tasked with making a functionally equivalent piece of software now versus 20 years ago, it's better and easier in every single way.
How long does it take to actually understand what all of that does? I can claim to understand it, sure--but I'm also thirty years old and I've been getting paid for this stuff for the last fifteen. (Not, like, random POKEs into memory to make syscalls, for sure, but I understood why stuff like SCREEN 13 worked, along with the general constructs of the language.) On the other hand, I pretty much fully understood how QBasic worked and its interactions with DOS at age 5. I was able to parlay that into C and C++ and into understanding how the thin virtual machine there, simultaneously into PHP and Java and how those actually worked by relating them back to lower-level concepts I'd picked up...
Cargo-cult monkeying about doesn't adequately, to me, replace understanding and insight--and "just make a Rails app and push it to Heroku" is fundamentally cargo-culting. If you don't understand how your tools work, you don't understand what you're doing. (I've written everything from CPU emulators to Rack frameworks to prove that I do understand what I'm doing.) I started doing that literally from the jump as a kid, and the systems were built so that it was something you could easily do.
There is nothing stopping anybody from digging into lower level languages now, in fact that is also easier than ever with open source IDEs, free compilers, fast processors, ubiquitous documentation, and helpful communities too. The mere existence of a totally open source operating system like Linux and its ability to function on commodity PCs and embedded devices is huge.
You can argue (and I believe this is the point of the article) that people don't bother going deeper because for most computing purposes interacting with very high level abstractions of really complex systems is sufficient (and indeed becoming the norm), which leaves users at a loss when asked to grok lower levels of abstractions. It's also true that there is now more complexity and there are simply more possible things to learn, making it less likely that any individual has the time to develop deep knowledge of all of the systems they use.
Those assertions may well be true, but I'd argue they are not the same thing as it being harder to learn anything in particular. It's daunting, maybe, because of the sheer possibility space, but all of the knowledge is out there and the tools are better than ever.
at some level, you're always going to be assuming the layer before reasonably works the way somebody gave it to you.
Its not cargo culting if you know where the actual dependence is, and both rails and heroku make it fairly clear what kinds of things they are doing. Even if you don't know how they're doing it, you know that without running the heroku part, you cant load the page in the browser, and without the rails part, you don't get any files you can change.
Same here, and I was a kid who a) had no idea what he was doing b) couldn't afford to buy Inside Macintosh c) really had no idea what he was doing. But honestly, I achieved more with C and some cargo-culted System 7 (6?) Pascal calls than I have with Go, with respect to UIs. I achieved more with HyperTalk than I have with Common Lisp, with respect to full-fledged application environments. Honestly, HyperTalk was by far the single most productive system I've ever used in my life.
Life was pretty great back then. I can only imagine how much better it could have been with highspeed Internet in my home. Or maybe we'd just be on the dozenth round of Macintosh Toolbox wrappers written by sleep-deprived college students by now.
Maybe, ironically, one of the advantages we had is that these difficulties forced us into a much better learning environment, when the answers weren't all immediately available through Google? Being the one who can self-learn extremely well gives us a big advantage when given a new problem or technology stack.
Now of course you don't need that to do hello world, but a beginner doesn't know that!
Ah, that brings me back to memories of boot floppies in order to change the memory settings of the system.
Recently I had this surface, some RT kernel extension we use would display possible conflicts. Despite programming a lot these days, my background is electronic engineering, so I still have a rough idea of what an IRQ is and does even on the lowest level. However had no luck trying to explain that to a 'pure' programmer.
Interrupt requests are easy to explain to even a novice computer user if you frame them in the context of something they're familiar with.
For example, when you press a key on your keyboard an interrupt request will be created to make sure the computer knows you've pressed the key. So in simplified terms, you could say when you press the "A" key on your keyboard, there is a part of the computer that says "pause what other things you're doing, respond to the "A" key press, then continue with what you were doing before".
I mean, it pokes the keyboard controller in order allow the processor to control an additional bus line to the memory controller. Then, thanks to 8086’s overlappping segmentation architecture, you can access 65519 additional bytes that were never intended to be there in the first place.
There’s Cthulhu mythos that is more acc si le than that.
Now, we have a proliferation of computing environments, and it's hard to give people generic advice about how to install and use a tool that would apply equally across all those various environments. Browser standards seem to be the one thing that's relatively common across platforms, so a lot of that stuff moves online.
That said, my background as a Sysadmin/Ops person also landed me in my own silo. I don't have much programming experience, and running production systems means NO, the environment does NOT give you access to wide-open CPAN, RPM, pip, whatever downloads. It's a regimented release process where someone upstream has to provide the relevant dependancies and you don't just go around installing stuff, running services, etc.
As a result of my background and not being a developer, on HN I hear of new languages/frameworks/libraries/methodologies on a daily basis. Things that, clearly, a large number of readers hear must already be familiar with, even though many of them will be out of fashion in 6 months.
And then the process to install a lot of these things is "oh, just pipe a wget of this script into bash, RPM install this, pip install that, don't worry, it's all quite safe for your system..."
In many ways, it feels like worlds are diverging.
We are specializing.
Enterprise shops have always wanted stability, and so they develop ever more elaborate build processes to control exactly what versions go into production. Embedded systems have always wanted to run only what needed to run, and so we have developed ever-improving systems to pick out only exactly what needed to be run. Developers, in the meantime, have always wanted the newest and shiniest, and so have gotten 10,000 ways to install newer and shinier toys.
Edit: typo
The funny thing is the C64 and VIC-20 were self contained, for the most part. You didn't have to add cards and swap out processors and all that. All you really had to do is know how to put wad of aluminum foil where your fuse should go when your fuse goes out. :)
When the dot boom came around, I had to learn how to not only write web sites, but I had to learn how to host a website out of my house, which includes everything you would need to host a website, which involves a lot. DNS server, mail server, database server, server admin, TCP/IP, security, and more. I still host out of my house today.
Learned lots in those hours and hours
You're admittedly obsessed with computers, which presumably means you spend a lot of your free timing tinkering and learning. You've picked up a lot of very useful knowledge, but surely there's room in a profession for those who are not obsessed with their field? The programmer who doesn't know anything about a BIOS perhaps spends their free time bike riding.
It's not like architecture or cooking.
Everything sucks. Most stuff breaks, are buggy, badly documented and poorly explained. Things gets obsolete fast.
If you are "just a programmer", you will be half productive and very dependent on others.
Computers, on the other hand, I despise. Every piece of knowledge I have to learn about how a specific computer works, not in the sense of ALUs and registers and whatnot, but in the sense of 'if Windows gets a BSOD it's probably the boot usb you've left plugged in', I hate - and only let into my brain with a great deal of teeth-grinding and swearing.
Fundamentally, computers are interesting devices. Using them, however, is generally horrible. So I can see why people get into programming without really taking an interest on the devices we normally use to program on. I think programming would be an interesting activity if you were just doing it with pen and paper. For me, it's really a shame that the best device we have available for it is some kind of crazy-house compendium of horrors and bizarre compromises.
Another day, I went to the local of the university's CS student association. I was excited about what I did the previous day so I told after entering: "yesterday I installed FreeBSD in a virtual machine and did XX". One people replied by what is a virtual machine, and another by what is FreeBSD. I explain to them briefly then left wondering where the people actually interested by the field were. It turns out I met some of them a few months/years later. Both mostly self learners, one with formal training in theology and the other a musicology.
I do agree though, I find when I'm teaching my juniors I sometimes have to give a little history lesson as part of it (things like why 8.3 filenames).
Why is that, exactly? I grew up in that era, I remember when floppies were actually floppy, and I've been well into computers ever since, but I don't believe I could tell you why. If I had to guess, I'd guess that FAT used a fixed number of bytes for each filename.
The (decimal) 40 characters were A-Z, 0-9, and four punctuation characters -- I don't remember which. Three characters could be stored in a 16 bit word, so a 6.3 filename required 3 words or 6 bytes. The '.' separator was not stored, of course.
The implementers of CP/M or one of those early PC OSes copied the idea but not the encoding and picked 8.3 as a slightly more usable size. Floppy drives were relatively capacious (!) so bigger filenames were reasonable.
The only reason I know this PDP-11 trivia is that end users could recompile the RT-11 kernel to save space, and DEC distributed the OS sources to enable that. The distributed version was written in assembler and had had comments stripped, so it wasn't quite like reading the Lions book, but you could read it if you really wanted to.
I don't think starting early or on your own is a requirement. Like in any field, intrinsic motivation is what counts (IMO).
I started programming in university at... um... 19? As a part of a physics degree. And fell totally in love with it. 20 years later I'm doing it for living and the love really hasn't faded.
Computer graphics is a demanding mistress, you really need to understand why programs and computers work.
Based on my experiences I would consider myself a pretty OK programmer.
As for whether such legacy program exist anymore it is a mystery.
This is the one thing I don't agree with. A better placement for these skills is a generic course required for any degree, or an optional course that anyone could take to shore up these skills (and you could recommend it for your CS major). Importantly though, this isn't part of the field of computer science, and so it doesn't really belong in that curriculum.
Now, if we had more of a "software development" or "software engineering" major, or even trade school, I think that would be a perfect area to cover practical aspects of tooling that are required to work in the field. There's a large gap between what you need to learn to become a reasonably competent programmer at most organizations and what you learn in a computer science major, and it really shows if you've ever interviewed a lot of fresh graduates. Great algorithm and theory skills, but no idea how to set up a build system. There's definitely room for a more practical education that transitions more directly into industry.
Basic computer administration falls into that huge category of useful skills that are not worth teaching to a general population who have completely viable alternatives.
Specialization is extremely valuable for society and having more competent doctors etc is worth doctors having a more narrow focus.
Computers in hospitals are a chore and a drain on doctors. They should be empowering, instead doctors spend the majority of their time typing reports. Reports of things that are already registered in other parts of the system. (You're already thinking of a solution right? That proves my point)
Hearing about how hospitals handle technology from my SO (neurologist) makes me want to rip my hair out. Specialization is a great thing but we need generalists to bridge the gap to help specialists empower each other.
For a doctor: 1. 4-5 years Bachelors degree 2. A Masters Degree (at least 2 years) 3. Residency (at least 2 years? And this is working weird shift at hospitals and whatnot)
For a SE: Degrees are optional. Perhaps a Bachelors.
So if you require the same amount of rigor from SE's, that's probably gonna scare off many who don't want to spend the better part of their youth buried in books.
And since there is such a huge demand for SE's who don't need to know OS fundamentals, there is no push for having more rigor in the curriculum.
Maybe I'm being too pessimistic. I would certainly like there to be more generalists. But that would require the same kind of attention to credentials that doctors are put through. And I think a vast majority of current engineers are opposed to more formal education.
Programming on the other hand would take a significant commitment to be useful. Sure having say ~1% of doctors go down that path might be useful but for the other ~95% it would be a horrible waste of time and cost literally hundreds of billions of dollars over time.
Most specialized software systems, e.g. those that are used in hospitals or selling you train tickets, are developed by people who don't have a faintest idea how the software is used daily. This ends up being an expensive disaster more often than not.
This is why I think everyone should have basic computer literacy and programming skills. Which is not the same as everyone should be a professional quality software engineer.
Worse, Doctors are often not part of these decisions in the first place. Further there are plenty of doctors with these skills however they don't work for cheap and most of this software is build by people that are paid as little as possible. Remember their workflow is not actually complicated, it's just not helpful when selling this software.
Really, this software is not terrible because it's hard to make, it's terrible because of how it's sold and maintained.
That is the dream: https://en.wikipedia.org/wiki/Biomedical_engineering
I wouldn't say it's a scientific observation but I've definitely gotten the impression that it's taking people longer to outgrow the cycle of immediately searching for a copy-paste answer and moving on without developing a better understanding of the issue for the next time something similar shows up.
I wonder if that's a phenomenon on the same spectrum as HN-Driven Development, where whatever one has last seen posted on HN is clearly the New Best Thing Evar. It's a bit like a voluntary outsourcing of one's own agency.
Just something to think about aswell. When things were simpler and there was less choice there was also more concentrated documentation. It wasn't a bad investment to by a book about a language.
Now my other colleagues are mostly doing back-end and embedded C++/Python stuff, and are in general a lot more interested in the technical side. I think it's more or less the other way around, 1 out of 4 is not really tinkering with tech at home - but even they are more interested in tech outside of their field. I show them stuff like docker, kubernetes, time-series databases and metrics collection stuff, ansible/tower and what we can do with those things, and how they could make changes in the way they design their software to make things more reliable or easier to deploy/monitor - and their reaction is "oh cool!". Our front-end team? Completely the opposite attitude and completely averse to changing the way they work. I hear "we'll do this manually" or "why? this works too"...
Most of the front-end dev roles seem to attract people who're not really into tech, but can code a bit. I think because of the immediate visual feedback? They end up hiding behind their frameworks with a lack of even basic understanding of HTTP or networking. Me as an embedded developer rolled into sysadmin role then has to tell them what the hell HTTP2 is, catch their screw-ups when they serve mixed http/https content on their site, ... Now they're not all like that, there are some pretty good guys there - but the majority can write basic code, and that's where it ends. Sadly it's no surprise their team-leads all fall in the wrong category. On the other side, I have the last say when stuff is deployed in production, so they are forced to adapt to certain things - but they'll always complain.
Like I remember in middle school, we had an elective option between woodshop and CAD. The 'CAD' class was really more about performing simple automation in programs like MS Word/Excel, but that sort of thing is still useful in just about any job these days - not just programming.
I really like the idea of starting to call 'CS' something like 'Informatica' so people might stop looking at the field as just a valuable career skill. Google tells me that there is now a startup called 'Informatica', but that is also what the field is called or translates to in some other countries like the Netherlands; I think https://www.cwi.nl/ could probably claim prior use.
Speaking of, it seems odd to try to use an existing commonplace phrase as a trademark in the industry that the phrase was born from - it seems like it'd be impossible to argue that anyone was infringing - but I guess I'm not a corporate lawyer.
1. Treat Computer Science (CS) as a specific field, and don't dilute the curriculum with related items. 2. Introduce a course that covers these broader, non-CS items, and actually push it out beyond the audience of CS?
Did I get that right?
I think you might have meant the term "informatics" (https://en.wikipedia.org/wiki/Informatics). Depending on your position CS is either subordinate, equal, or above informatics. I have a degree from a UK university and there is a much wider spectrum degree types in this field than exist here in the US where I now live.
I'm conflicted on the original post that elicited your response. I have that background where I inherited a broken PC, a bunch of floppy disks, and some manuals. In some ways this gives me an advantage, especially given that I'm comfortable being dropped into a messy project or some problem that is debugged. I've seen lots of folks who can't handle this, but can churn out code on to need more support around the edges.
I now see more and more folks attempting things like devops and at least being able to learn some of these skills later on. I think where it stands me in better stead is problem avoidance, but even that is subjective.
I mean, I've been getting paid for this for going on fifteen years now and I'm not an engineer. I try to build resilient, reliable systems, I try to test heavily and comprehensively...but I'm not an engineer, and most of the time I'm worried when somebody calls themselves one.
What "software engineering" is, in the context of a web app or a point of sale system, rather hard to define. Worth taking a crack at. But we shouldn't put the cart before the horse.
Responsible engineers (i.e., those that I aspire to emulate) seem to spend non-trivial amounts of time predicting and avoiding potential-negative outcomes. They also seem to have a near-total understanding of the processes that impact these outcomes.
If only I could figure out how they _know so darned much_ about everything ...
As someone with a degree in Mechanical Engineering, I'd say that your observation is mostly due to (1) several hundred years' worth of head start (2) the field not shifting under them (much) over their careers (3) intuition from interacting with the real world being applicable and (4) you're also unaware of the crazy amount of accumulated computer knowledge you have. Now, due to the changing nature of software development, a lot of that accumulated knowledge is useless, but it wouldn't be useless in a more mature field. Imagine if all of the random arcania I've had to pick up from AppleSoft BASIC, Pascal, Perl 5, Tcl, ANSI C , etc. were directly applicable in my day job using C++, Scala, and Java.
Sure, there's some overlap, particularly from ANSI C to C++, but with Mechanical Engineering the basic tool kit changes much more slowly. I learned about common steel and Aluminum alloys, polyethylene, ABS... advantages and disadvantages of each, things to watch out for.
If a Mechanical Engineer really gets to know 1040 vs 1045 vs. 4130 steel alloys, that's knowledge that's going to pay dividends for the rest of her career. It's not like 10 years ago or 10 years in the future there was/will be a massive shift away from Aluminum and steel and the majority of engineers had/have to throw out most of what they knew/know about metals and learn how to design for Nickel and Titanium alloys. 3D printing brings something new, and heat treatment and machining techniques have improved, but even 3D printed metal parts aren't fundamentally different from the powdered metallurgy that my dad's cousin was researching in the 1940s.
You're also accumulating a ton of arcane knowledge, it's just that most of it has a relatively short useful life.
There's also survivor bias. The engineers that were promoted and kept through economic downturns tended to be the ones that were really interested in their field and readily soaked it in.
I just transferred into it from computer science, because I spend all my free time making games anyway, and the informatics program lets me take an elective track to get credit for that. I do think CS is probably a better fit for what I see as my long term plan, but I think this program has a lot of potential for people who wouldn't otherwise call themselves engineers.
I agree it would be a better name but I think the battle is lost, informatics now refers to an applied discipline (closely related to library science) involving building up big systems to store and organize data.
I would ditch that and concentrate only on computer related issues. Database would be a big one that is usually missing. Networking as well. Computer architecture (like building a computer and the Von-Neumann model) should also be included. Basic project management would be helpful too. That's 4-6 courses you could suppliant with Physics 1-3 and Calc 1-3.
It just seems silly to force CS kids to learn Physics and Calc when it is seldom used in the real world. I would much rather have a grad know the ins and outs of networking and how a computer actually works than Calc and Physics.
However, the explanation behind such a program is probably the distinction between vocational training and academic training. At least, here in the Netherlands, academic CS taught in academic institutions lies on the theoretical side. In such an academic CS program there are some practical courses. Stuff on databases, networking and computer architecture. But those are high level, and quite theoretical. Were they not, there would be a lot of push-back because they are almost considered demeaning.
Meanwhile, with the vocational instituion, things are very practical as far as I know. Much of those courses are actually building practical software. In large projects aimed at real uses. Meanwhile, in the academic institutions, you'll have multiple projects that boil down to 'implement gradient descent in MATLAB'.
I've heard it said that even though the academic institution is much harder and prestigious, when it comes to making practical software you are better of taking someone from the vocational instituion. Or at the very least, if you take someone from the academic institution you'll need to invest more time into training.
There is a bit of tension here where 'really smart people' who want to just become really good at a job are still expected to go to the academic institution for the prestige. Then, those people get less practical knowledge than they want because they are at an academic institution.
That was not what I wanted and I'm quite happy at the uni of applied sciences now, and since most of our profs have an industry background (and a Dr.) we learn a lot of practical things.
E.g. Git, build management, agile development, a module about usability and user experience, networks, applied algorithms and data structures, some math (proofs where a side note though) etc
On the other hand, some of my fellow students ... Well, one task last semester was to program some really easy program with java, connect to a database with jdbc, do something with the data and write it back. We didn't know about jdbc until then. After a module is finished we have the opportunity to fill out a questionnaire about it and at least half of the class wrote that it was not ok to demand something like this. It boggles the mind.
This is sadly considered as plain easier than university. It probably is as well, but that leaves a gap for professional training at a higher level. It sounds like the 'Technische universitat' in Germany nicely fills that gap, or is that still considered as easier than normal university?
That's just what the Universities which focus more on STEM as opposed to Literature/Law/Psychology call themselves.
Not sure I agree with whole-scale removal of it though. I have to use calculus every once in a while in my job. While I never integrate by hand, I certainly need to know what integrals and derivatives are and how/when they are applied.
My wife got her CIS degree a few years ago and they seem to have improved a bit. She had multiple programming courses in several languages along with more advanced CS courses and database courses.
The problem is that most calculus courses were devised before the widespread availability of Wolfram Alpha and focus too much on hand computation rather than understanding of the subject.
I had a few jobs once out of college (phone support, QA (before automation was much of a thing), sysadmin, back to phone support) before I got a programming job. That was a good two years out of learning the other parts of a computer. It was because I knew perl that I was able to do the sysadmin - web programmer transition.
That wasn't too unusual of a path back in the mid-late 90s.
A good chunk the developers over in the engineering department and nearly everyone in the programing wings of IT and customer support had done tech support or system administration. It was just part of the "working your way up" within the career path.
Many of my classmates in college went to a "the computer guy" job which did all of the computer stuff for a small company (hardware, software, helping with excel, writing programs to serve dynamic text to the web server). Being a computer person back then was a much more generalized skill set.
As an aside, recently I was tapped on my team (Java developers) to do work on an older website. LAMP. I had to brush up on Linux from the past decade (I was another decade out of date with some of the package management)... but being able to do that sysadmin, read perl (I know of one other perl coder in the department, but he doesn't have any sysadmin background) and get it running was a skillset that didn't exist much of anywhere else.
In some ways computers are too usable these days. In other ways the experienced programmers are too sloppy and put in too many barriers to get their tools to work flawlessly in the modern world. We don't live in the tinker world any more.
But ultimately to be a good dev you must learn to debug.
Hard problem to solve.
The first skill listed in the first section is "Learn to Debug" ( https://github.com/braydie/HowToBeAProgrammer/blob/master/en... )
> Debugging is the cornerstone of being a programmer. The first meaning of the verb "debug" is to remove errors, but the meaning that really matters is to see into the execution of a program by examining it. A programmer that cannot debug effectively is blind.
I don't think its a coincidence that that's the very first bit. It is indeed the most essential of skills.
That sort of hobby teaches you to keep ramming your head against the wall until the bricks start to crumble, which is helpful when you're trying to learn a language but the package you want fails to install on Ubuntu, or your program won't run despite you having checked the syntax a thousand times, or a concept doesn't click until you've re-read it every day for a week. You learn to see computers and software as a mess that you will necessarily have to untangle and rearrange for things to work properly, instead of thinking of things that don't yet work as "broken". And you learn to Google until your eyes start to melt.
I recognize this. My 'younger' colleagues can't install a computer from scratch, a get completely stuck on the slightest network issue. But I don't thin it is related to education. The 'older' programmer had to squire these skills by necessity as it was completely impossible to use a computer otherwise. For us getting a new release of Windows or VS usually meant wiping everything clean and install from scratch a we all knew how dodgy 'upgrading' was. My 'younger' colleagues wouldn't know where to begin when they can't hit update and everything works. They have to wait and rely on a system manager to re-image their machine for them.
It may be the result of the competitiveness of the education system. Everything is more competitive. As I understand things, CS is the hottest undergraduate major right now. You can't just sign up because you learned to program in high school and think it's cool. You have to be a top student just to get admitted. So it may be that the kids who want to be computer scientists just aren't able to have hobbies at all, or their hobbies are chosen to look good on their college applications.
One of the things I've noticed between then and now, is that when I was in high school, I learned programming because I had a lot of spare time to kill. My kids have no spare time.
>>> Teaching these skills in CS curriculum would probably be a good idea.
Granted, I didn't study CS, but instead math & physics, decades ago. But I think that some things don't belong in a college curriculum, especially given the price tag. I didn't take college courses to learn soldering, or even programming.
But also, not all CS majors are destined to become hackers, and there has to be room for a student who might be all thumbs but really has a deep interest in the subject matter of the field. In physics, we called them "theoreticians."
A deeper question is why someone is studying theoretical computer science for 4 years in order to become a coder. Programming is getting harder, but that much harder? When my mom taught programming in the early 80s, her students were getting jobs after one year of coursework.
Hardly. Looking at the Swedish admissions statistics[1] from this year (because that's what I'm familiar with):
- Of the top 5 programmes, 3 were for physicians (doctors), with the required GPA ranging 22.09-22.29
- The hardest engineering programme to get into was no. 8, technical physics, requiring 21.98
- The hardest computer-related programme to get into was no. 56, software engineering, requiring 20.73
That said, it was above 20.0 (straight As), so the requirements do seem to have increased in the last few years
[1]: https://statistik.uhr.se/uhr.html, to see applications to programmes based on high school GPAs you'll want to pick "Bara program", "Urval 1", and then set "Visa urvalsgrupp" to "BI". You'll want to sort by "Antagningspoäng".
10-20 years ago, it was a requirement to learn the layers support your own hardware, network, security, hosting.... all for the opportunity to try to build a piece of software. You could spend a few years improving at each and it was perfectly normal. Now there seems to be a rush to get through it all to become awesome by skimming the surface.
As a result of learning multiple layers (because there was little other choice), one picked up a lot of transferable skills. You can sometimes literally traverse debugging an issue between all of these layers.
In school computers were taught, first from how a computer physically worked, booted up, etc.
Then, you learned some basic operating system, applications, and how they interacted with the computer.
Once that was completed, you started some amount of creation, whether it was visual design, games, programming, etc. Not to create a programmer, but as a form of creation with the computer.
You can't just google "The internet won't work" or "blue screen help" or "I can't see files".
Web search is a super powerful tool but it requires some fundamental knowledge before it can help.
The newer stuff will come up with unhelpful messages or just an eternally spinning pointer, and yet they are supposedly bringing Linux to the desktop. F that.
And i wonder how many times now i have fed a Windows error code into a search term and found a bunch of people asking all manner of channels (both Microsoft and otherwise) for help and get nothing (W10 don't like the card reader on a tablet i have, and all i can find is that maybe, just maybe, MS screwed up the driver. But Intel seems to no longer provide any usable chipset bundle...).
I used to be a teaching assistant for a programming class at a top university, and it was astounding how often my students' issues could be solved by simply copy/pasting the error message into Google.
It seemed like most of my students were often so intimidated by the scary red error text that they didn't even try to solve it themselves, they just gave up and assumed it was unfixable. About halfway through my semester I reached a breaking point and spent an entire lecture where I had a list of previous emails from students asking for help, copy/pasted their questions verbatim into Google search, and showed how often the solution was found within the first few search results.
I think this is a side effect of teaching programming as a career skill.
In all those situations, the underlying problem was that the person in question didn't have a firm grasp of the programming language they were using, but seemed to program in terms of "patterns" -- they knew how a for loop has to look like, but as soon as there was a slightly more nuanced problem (say a parsing expression in Boost.Spirit), they weren't able to see how the underlying syntax was treated by the respective language.
While I get that it's almost impossible (and certainly impractical) to learn every edge case in most modern programming languages, I couldn't help but think of cargo cults.
Edit: On second thought: OTOH, it seems to me that it isn't helpful to view what a software engineer does merely as "programming" in this regard. I don't see a problem if, say, an electrical engineer is missing said "computing" skills, but they are in their way to complete a program. Many modern professions benefit greatly if the respective person is able to program (maybe only in a specific language, e.g. Matlab or LabView), but that doesn't mean they have to know their working machines inside out.
I assume it's because I was a power user before I became a developer and so had that foundational knowledge and interacted with OS APIs to build on it... now people just go right into mashing JS code at web browsers which seem to be hacked into everything.
That said, the specific point you raised is interesting because I was having the same problem at work. Except it was caused by automation. We have automated pipeline for everything, zero downtime deployment, containers, ... all of that is working very well - so well that there is just no enough big stuff to do so that newcomer on the project can build enough experience with the pipeline to master it. The best people achieve is some sort of very rudimentary debugging capability, earned from the monthly minor tweak the system require. Basically either you build similar pipeline on another project, something that is extremely unfrequent, or you missed the train.
It was included in my college CS curriculum, using the most obvious text (Debugging, by Agans) almost 10 years ago -- though I had a head start, since I read a copy of it from my public library about 4~5 years before that.
If other schools haven't followed suit, I have to ask "What on earth is taking them so long?"
Some German Universities (TUM, KIT) pride themselves on that last point so much, they actually pass off the CS degree as an Informatics degree on the English version of their diploma transcripts.
Don't get me wrong; I don't think there's any point in making new programmers jump through arbitrary hoops because "programming should be hard". But I think that today, programming is necessarily intertwined with computing and problem-solving in general, and all the Dockers and specialised positions in the world don't change that. To be a good developer, you need to have some idea about the systems your code will be running on. A program doesn't just exist in a bubble. (This is more true for some kinds of applications, less for others, of course.)
In the older generation, CS was a relatively obscure and difficult skill with little to no easy-guides that it filtered the set of students to only those who were insatiably curious and were fuelled by learning new things.
In contrast, CS has become so ubiquitous that nearly everything has a "how do it" guide that eases the entry of nearly anyone, with little or not interest or whose motivation might be less than ideal. Thereby, possibly leaving room for more anecdotal evidence for this perceives shift in skill.
I think the issue is more about experience and need: when we were learning to program, we HAD to do those things. For the younger generation, it is totally possible to get by without because the ecosystems are so much easier, coupled with a lot of online knowledge that they can access quickly, which was mostly missing in our age.
On the other hand, those young programmers that are faced with a complex ecosystem will usually learn how to deal with it. Heck, with the web and its many step backwards in programming environments (e.g. try debugging in Chrome!), many things are actually harder for them and they acquire skills that I didn't need!
We are taking half a decade until my cadre is unfamiliar to me. That's insane.
Still, I learned to manage/hate computers by the Win '95 era and grow to love them again by the time Linux became tolerable about 10 years later.
My introductions to object-oriented and functional programming came much later in life, and I can't help but wonder how many bad coding habits I had to "unlearn" as a result of my Commodore foundation.
If your standard library makes pervasive use of higher order functions, and you haven't yet wrapped your head around elementary algebra, you're going to have a bad time.
I'm having a hard time thinking of an existing functional or logic programming language that requires a minimum of abstract thinking. You can use many languages in a functional style, but if e.g. you're using Python with a low level of abstraction, then you're likely using it as an imperative language.
That could be an upside if you wanted to learn assembly since BASIC really wasn't that far removed from it in terms of what you could do and how you did it.
Learning to program is getting harder because the programs are far, far more complicated than they were 10 years ago.
I always thought it was account based! At least thats what my coworker and IT guy explained it to me as.
Younger programmers seem to commonly have zero knowledge in this area. If they run into some problem with their environment, they are completely stuck. Oh, they're asked to install a VPN client but it doesn't work and they have to debug it? They're completely blocked. They have no idea how to continue.
For me, I learned these basic computer skills first (because I was obsessed with computers as a child). Then I learned to program.
I think this is a side effect of teaching programming as a career skill. You have people that want to be programmers but don't include "computing" as one of their hobbies. So of course they don't know anything about how to debug computer problems. This is totally expected.
Teaching these skills in CS curriculum would probably be a good idea.