I remember one of the first realizations I made as an undergrad was that CS != code. I think this book does a good job of removing the two from the beginning, and it would have been useful for me to have instruction like this when I started learning.
Later on I realized that most jobs that ask for a CS degree don't actually have you doing any computer science. More often you are glueing together tools or writing a bunch of boring business logic for some specific application at best. At worst you are maintaining an old monolith trying to figure out someones logic from 15 years ago.
Having a CS background in most software jobs is useful in the same way having a chemistry background is useful to someone working as a nurse. Sure there will be situations where that knowledge might help you make a connection more quickly, but you're sure as hell not a chemist.
Like your chemistry example. There's chemistry, and then there's chemical engineering. Chemists worry about the properties of atoms and molecules, and reactions that move from one state to another, and about the energy differences in reactions. Chemical engineers worry about how to efficiently make the stuff in multi-ton quantities without blowing up the city. It's related, but it's really a different set of concerns.
In the same way, CS worries about the efficiency of algorithms, and about what things particular language features make easier or harder to express. Software engineering worries about how to efficiently construct and maintain larger programs that adequately do what is needed. [1][2]
The thing is, almost everyone who graduates with a CS degree is going to be employed as a software engineer, not as a computer scientist. I fear that their education is mostly preparing them for the wrong thing.
-----
[1] Or perhaps, "construct less inefficiently" - there's inefficiency no matter how well you do it, but you have to control the amount of that, or it will destroy you.
[2] Note that I said that they "adequately do what is needed", rather than bug-free. Larger programs are never bug free.[3]
[3] Well, almost never. You can get there with formal verification, if you have a bug-free specification, and if the formal verification covers every relevant category of bug. But that's really difficult to do, and we're back at the "less inefficiently" issue.
They are preparing us for the wrong thing indeed, but boy is it nice to have some knowledge that will stand the test of time. If I could go back I'd remove all the courses that aged like milk and left would only be theoretical CS.
I have the hunch that software engineering is easier to learn than computer science though (when you studied CS first). Struggling with your nth segfault and having no clue where it comes from teaches a person a lot of grit to stick with a problem. When software engineering comes along, the person who learned computer science has matured into how to stick tough situations out. The extra practice in being detail oriented doesn't hurt either.
In that sense I feel like learning CS is getting a huge IQ boost into everything that is related to CS.
But I'm still relatively new to software engineering. So far, picking up about SOLID, design patterns, testing patterns, and what not feels a lot easier than writing a compiler or writing an operating system or performing attacks like Meltdown/Spectre/<insert any research from VUSec>.
Don't get me wrong: I should still respect it and work hard, but when I wrote a compiler I didn't even believe I was smart enough to build one from start to finish. I've had this multiple times over my CS student career. Now that I graduated, I still can feel like that but I have experienced it so many times, I simply know it's false. Now I know that I just need to put in hard work, and I'll be guaranteed to understand it.
Are there more optimal ways to learn software engineering? Yes. However, the value of CS in relation to software engineering stands: learning software engineering is now easier. Moreover, universities usually don't teach more optimal ways and we're stuck with the toxic narrative that university sets us up for life.
But creating HOC React components is relatively easy to understand, provided you focus, if you have a background in CS. It's also relatively easy to understand if you've been programming for a while (I suppose).
CS != Guarantee that you'll get a job you'll like as a programmer, or even a job as a programmer.
CS != Guarantee that you will be able to fix systemic problems in systems, understanding, culture or process in corporations or other organizations, by fixing code.
CS != Guarantee that you'll launch a successful website, or start a successful startup.
CS != Guarantee that you'll be able to raise venture capital, or be able to sell enough to gain your first customers to become "ramen profitable".
CS != Guarantee of success, or that you'll get what you want in life...
I am 99.44% self-taught -- my opinion is that CS degrees are overvalued and overpriced, but that being said, they're not wrong for everybody...
On the contrary. I feel that having a formal CS education (VS and MsC) in CS, made me a much better software engineer and a better coder.
Most of the stuff I use (languages, tools, frameworks) I've learned myself. But CS courses have taught me a lot, I have a deeper understanding of how things work and I can solve hard problems, I know instinctively where to look to solve an issue, and what I need to research to make things work as they should.
Based on my experience, employers tend to prefer people with CS education over people without, if that is the only difference.
Also, talking with my peers, I have the sense that people with formal CS education managed to negotiate better salaries.
Also, I my country, programmers with degrees in CS have lower income taxes.
For me it payed big time to spend that time learning, even if in the first two years when the courses seemed boring I did have the opinion that I was wasting time.
Some of my colleagues dropped out to work in the industry, some were working and studying in parallel. Those who dropped out have a harder time now. They have a harder time finding a good workplace and they have lower wages.
Would you agree to undergo surgery by a self taught physician or you would trust more one with formal education?
Did I not say "they're not wrong for everybody", in what I wrote?
?
Look, more power to you if you have a CS degree.
Sure, they can open doors, I agree. If I were an employer, and I had only two job applicants to choose from, and the choice was between someone with a CS degree and without one, and there were no other differences, nothing different in the way that they thought, no difference in what books they read, no difference in their general level of intellectual achievement, no difference in their goals and aspirations (perhaps one strongly desires to learn technical things without having a degree, and perhaps one does not...).
Well, without any of those other differences, if one has a degree and the other doesn't, then yes, I'd choose the one that has the degree over the one that doesn't.
But that's assuming that I'm a standard employer... and that I don't know the first thing about CS myself...
If I'm a smart employer, I might test both individuals' ability to cognitively reason about problems.
For example, I might have both candidates add the numbers from 1 to 100, and see what they do.
This was a challenge that was historically put forth to Carl Friedrich Gauss when he was a student (I should point out, he didn't know the first thing about computers or programming, as they didn't have computers, programming, or CS degrees back then).
All of the other children attempted to add the numbers from 1 to 100 one at a time, for example, 1+2 (3), 3+3 (6), 6+4 (10), etc.
This took them a very long time.
You see, the teacher had expected that this would take a long time for most students, that it would keep them occupied. That was the teacher's goal.
The teacher was very surprised when after a few minutes when Carl Friedrich Gauss' hand shot up.
He had solved it!
He had solved it not by adding all of the numbers one at a time, but solved it by realizing that if you added the first term and the last term (1+100, 2+99, etc.), it resulted in 101 every time, now all you needed to do was multiply 101 by half of 100, which is 50.
Which is much, much faster!
We call that an algorithm.
A CS degree is < 10% code, and > 90% algorithms.
You see, the teacher could have used that simple test to see that Carl Friedrich Gauss -- was going to go places in life.
He was going to go to great places, and do great things... and he did!
Even without a CS degree... which they didn't have back then...
If I gave this test, or others like it, other tests involving mathematical / logical reasoning to people with CS degrees and without, and if the people without a CS degree answered these questions correctly, reasoned correctly, it would show that they have the talent, they have the capacity for computer science, with a CS degree -- or without...
"Would you agree to undergo surgery by a self taught physician or you would trust more one with formal education?"
It will always be the person that persuades me that their knowledge/experience relative to the goal I'm seeking is the highest among all candidates. If that's someone university educated, then that's someone university educated. But show me a faster/better way to do things, and prove to me that you're knowledgeable and it works, and I'm all in...
What do you believe that you do not know? Focus on learning that thing first; it will lead to other areas of things you don't know, which will lead to others...
Socrates said it best, "The true knowledge consists of knowing that one knows nothing".
But that being said, there are a ton of interesting areas with respect to computers and programming. Pick one or pick several, keep an open mind, try to learn from whatever source you can (Books, classes, articles on the web, self-experimentation, etc.).
It doesn't matter where you start... just start! <g>
Also, if one book/class/teacher/article is too difficult -- find a simpler one, or one that simplifies the topic, and learn from that one first!
Then, Lather, Rinse, Repeat, and eventually you'll have 12 PhD.'s, like most normal people who are computer/programming enthusiasts(!), ...or you'll become a reclusive crackpot like myself! <g>
(Shakespeare: "Much learning doth make thee mad!"... well, that's what happened to me! <g>)
Well.. some software engineers are writing OSs & compilers, it's not like you hire a scientist for that and an engineer for anything else.
IMO CS is the right core thing to learn; software tooling & frameworks are easily picked up interning, in on the job training, and are more professional development than core knowledge.
If you compared an education in building a state of the art webapp vs. CS theory today, in.. idk, even just ten years, the webapp tech would be obsolete and the CS theory would likely be as solid a grounding then as it was twenty years prior.
> At worst you are maintaining an old monolith trying to figure out someones logic from 15 years ago.
Can you imagine what it will be like 15 years from now, when we're trying to maintain someone's microservices with their logic smeared out across dozens of distributed API calls, storage backends, and code bases?
I'm already maintaining an application written 15 years ago which is almost like this. It's in C++ but it's like they thought they were writing Erlang (without the tools or language support). Every task from the most trivial to the most complex is a separate thread using Windows messages to communicate. It's impossible to follow the plot to understand what is going on because the thread of execution disappears with ever message post to be picked up by a message receive somewhere else. The messages are globally sent/received so there's not even a channel receiver to look for everyone is a sender and receiver peeing in the same pool.
I had somewhat similar experience with event-driven systems. I figured microservices would flame out a lot faster as they ran into the same class of problems.
We do have some slightly better for managing the logistics though. Small force multipliers can add up to quite a lot in aggregate.
That in itself will not be a terrible problem. If it's well-documented at the macro an micro level, and if those micro-services are coded according to the "principle of least astonishment" - it will likely be easier than some million-line code silo.
B-U-T... All those if's probably don't hold. Good luck, future code monkeys!
If million-line code silo is well-documented at the macro an micro level and coded according to the "principle of least astonishment", it will be easy to maintain too.
With micro-services and a lot of use of (FOSS) infrastructure, there is hopefully a lot less code that's actually part of your own project/app/framework.
I don’t get this mindset. Even when writing a trivial app, basic CS knowledge is relevant all the time when it comes to modeling your data, manipulating it; oftentimes knowing a bit of mathematical formalisms lets you express things in much more direct ways. Similarly, computer architecture basics let you quickly estimate the plausibility of various features, etc.
If you’re a programmer who doesn’t know any CS at all, you probably have a lot of room to improve.
Kind of like a chef who only uses frozen foods and then doesn’t understand why things taste weird.
If you're a programmer who doesn't know any CS, you are likely unaware of what you don't know. Googling for what you don't know is remarkably unuseful.
> More often you are glueing together tools or writing a bunch of boring business logic for some specific application at best.
That explains their mindset. They are not doing much of anything that would require CS (or maybe they picked up enough and don't want to label it as CS for whatever reason).
I agree with you, this mindset is not good for our industry. It's fine that there are jobs out there that require a programmer who doesn't have much theory/background, but the mindset that CS is somehow not needed for our industry is just wrong. If only there was more focus on theory and building a good foundation for us then maybe we wouldn't have all the problems that we have now (who knows though).
I can presume many of the problems are due to coders rushing to write complex software without having a solid foundation and sufficient grasp of what they are doing.
I had a non traditional education and worked with a lot of CS grads. I think their education helped them all tremendously and I'm pretty jealous that they got that opportunity, and we had a lot of conversations like:
CS Guy: Yeah well TCP windowing should work like <insert something here>, so why does this not work?
Me: Yeah I think I know what you're saying but when you put everything all together ... TCP doesn't work that way. Here, I'll show you how you fix this problem, why you never use this configuration again, and ... you explain to me some of those fancy words you used ...
This is highly dependent on the institution. At many universities Computer Science is mostly coding, save for specific algorithms or theory courses. Sure, these classes often have you coding a compiler, operating system, or software router - things you'll rarely if ever do in a job - but it's also about getting a good amount of coding experience under your belt.
Yeah I wish this distinction was better communicated. I wouldn't have wasted four years and thousands of dollars on a CS degree if I'd known it wouldn't make me a better programmer. Going to college is one of the biggest regrets I have in my life.
If it's any reassurance, I believe CS degrees do make us better programmers than those without them. At the least, we picked up concepts that "just programmers" would have had to learn on the side.
As for the whole school cost, that's a different story, but we landed in a lucrative field where we can pay off the debt, compared to a ton of others that have no hope to without a career pivot.
> I believe CS degrees do make us better programmers than those without them
Maybe, but I can't really think of much that I learned in college that I have ever used since then. Everything a typical programmer does can be learned with just a textbook and/or the Internet. Beyond that, it's just years of practice and continual improvement, which you won't get in school.
All the CS classes I took (DFAs, state machines, Turing machines, programming language theory) were a complete waste of time for a programmer, and the actual useful stuff (programming courses, systems architecture, networking) I picked up in my free time in middle/high school. I'm sure it's all great stuff if you want to be a computer scientist, but I didn't and don't.
I think the only classes I took in school that I consider useful and that would have been challenging to pick up on my own were the coding theory[1] and intro to crypto classes. That's pretty poor showing for four years and a ton of cash.
> Everything a typical programmer does can be learned with just a textbook and/or the Internet.
You are absolutely right. Literally every single thing a programmer does, every bit of information they use, and every other thing they might use or need to know can be found beyond the ivory tower. It's all there. In fact, often the problem is less getting information and more figuring out what information is relevant.
Is it possible that some people may find value in a structured educational process? One that has already organized and worked out how to teach the fundamentals? I suspect that many people, pointed at the internet in general, may experience some difficulty in figuring out what to study and in what order.
As for material, I've personally found DFAs, FSMs, algorithmic analysis, and an understanding of computer architecture to be valuable to my career. I found a lot of basic theory useless, until I encountered cryptography that required me to understand a lot of theory to grasp fully. Obviously, personal mileage can, does, and will vary greatly.
I think we largely agree. Perhaps what's needed is for employers to stop requesting CS degrees for programming jobs, and instead have some kind of programming certification process, and accompanying courses to prep one for that certification. Then we can dispense with the theory that is useless for 90% of programmers, and stop making CS lecturers teach C++.
What specific skills do you think should be tested for in this certification process that you imagine?
It's been my experience that a CS degree is used as a certification for a broad array of fundamental skills. A lot of theory is, as you say, useless most of the time. But sometimes it can be important to have a grasp of how hash algorithms work under the hood. Though how well this degree-as-certification idea actually works is open to debate. I've definitely seen it fail.
It's been my experience that it's rarely obvious to people operating in ignorance when a grasp of theory would make a big difference. This can make it challenging to fall back on the model of looking up information as needed.
It's an interesting question and I'm definitely not qualified to answer it in a few minutes! But some ideas...
For a course, I'd start with how a computer works, something simple like a 6502 CPU with a memory mapping; how assembly represents those operations; how higher level languages abstract that; how computers represent different types of data; then move into some overview of languages in common use today; algorithms and complexity analysis; good code hygiene and development practices; common tools in the Unix and Windows worlds. Once you've got all those basics you can move into focuses like graphics, security, web apps, data storage, operating systems.
Most of what you've described was the core material in my undergraduate program. It's certainly enough to cover several years of study. This is enough to make me wonder if my undergrad experience was, in essence, the certification process you're thinking about.
For much of the 20th century programming was believed to be what they called back then women's work. Academy didn't feel comfortable teaching it since they knew things like yearly JS fads would happen and probably wasn't until Knuth that folks believed courses could be taught that would offer students lifelong benefit.
I personally think the most relevant courses I took were an OS course (I don't write operating systems, but knowing how they work can be very important) and algorithms come up rarely, but still sometimes. I also had a networking course that I definitely benefited from. Generally, I am quite pleased with my education.
If your CS degree didn't make you a better programmer you should specifically be mad at your university more than about the distinction between CS and software engineering. A well-rounded CS degree will absolutely make you a better programmer, but it won't make you a good programmer. The only thing that can do that is doing actual programming.
Yeah totally possible my university sucked (University of Minnesota in the late 2000s). One of my professors thought 0x1 stood for "0 and then a bunch of stuff that doesn't matter and then 1". I stopped attending his classes.
>More often you are glueing together tools or writing a bunch of boring business logic for some specific application at best. At worst you are maintaining an old monolith trying to figure out someones logic from 15 years ago.
I did that. But I also started many new software projects. And CS education helped.
If you don't want to get stuck in maintaining old crap, you don't have to. You can change jobs. You can change type of projects you work on. I did.
I did game programming for lots of years and grew bored and tired of it and now I am doing web apps which I enjoy doing for the time being.
One of my hypotheses is that it's incredibly difficult (and relatively rare) to be able to turn non-programmers into Computer Scientists. It's much easier to turn programmers into Computer Scientists. The conventional model of trying to turn non-programmers into programmers at the same time as you turn them into Computer Scientists is not very effective.
> it's incredibly difficult (and relatively rare) to be able to turn non-programmers into Computer Scientists
Yet the premise is the vast majority of jobs don't need a computer scientist. They need a programmer who can understand a complex code base and explain why is it taking so long to display user's birthday on the settings page [1]
This is pretty standard in every field out there. If you want to learn how to do a specific job you go to trade school, do an apprenticeship or really just get a foot in and learn on the job. University education is for theory and research.
> University education is for theory and research.
There are two immediate counter-arguments to this. First, you don't go to the university to learn how to do something which you're going to do at a job, but you go there to get education, and that's quite useful for both professors and practitioners alike. Getting education is a wider idea; it's a mind training to deal with variety of problems, including lack of education, in any area. Second, sometimes you're reminded that there is nothing more practical than a good theory. Ken Thompson's regex matching engine is one of illustrations of the concept; but in general, many things you learn at a workplace are specific and temporary (adjusted to current conditions) while many things you learn in university are permanent and general, even though they can look differently in different applications.
University education is pretty much what you put into it. If you sit and wait for knowledge to be spoonfed you will get theory and research, because that's the only thing that can be learned that way. If you take a more active part in your education you will absolutely get a lot more than theory and research.
For example I teach databases and one of my first year tutees comes to my office hours and asks me for advice implementing the database part of a website he is working on. He is the only one who bothers coming so I spend an hour every week whiteboarding database design and optimisation with him, and explaining how to design the architecture of his app. Another one comes to me on a regular basis and seeks my advice on machine learning (my field of research), and I give him guided readings and advice on adding some light ML in a game he is working on. Both of them will get a lot more of their education than theory and research, because they understand that what they are paying for isn't a weekly one man show of some dude standing on a podium and talking for a couple of hours, it's access to expertise.
I'm just a hobbyist programmer, and the only class I ever actually took in CS in university actually taught Scheme/Lisp. Homework and exams were all pencil-on-paper, which I thought was very strange, but at the end of the semester made me feel very comfortable with the quality of the code I was writing
> Homework and exams were all pencil-on-paper, which I thought was very strange
FWIW, I graduated college in 2016 in the US, and probably around 1/3 of my computer science homework (as well as 100% of the exams) were pencil on paper (or in the case of some homework, typed in either something like Latex or a word processor, but still not writing code).
> Homework and exams were all pencil-on-paper, which I thought was very strange
Sounds like what I've heard of CS education in a lot of developing countries. When students can't commonly afford computers, computer science courses turn to pen and paper.
Tim Bell, one of the creators of CS Unplugged, was one of the biggest influences on me discovering my love of computer science and learning how to program in high school. I wouldn't be where I am and doing what I do if it wasn't for him.
I wasn't originally planning on becoming a software developer as a career, I started studying Mechanical Engineering. However, I failed first year (due to undiagnosed ADHD and a lack of interest). Luckily Tim was a lecturer at my university (University of Canterbury), and let me jump straight into second year computer science.
He was definitely one of the best lecturers I had, alongside Richard Lobb. It's not often that you meet an academic who's more interested in teaching than research, but they were, and it showed.
> The easy and fun activities in this book, designed for studentren of all ages, introduce you to some of the building blocks of how computers work — without using a computer at all!
> The studentren are actively involved in communication, problem solving, creativity, and thinking skills in a meaningful context.
It seems as if they wrote "children" and then replaced s/child/student/g in some sections :)
Growing up in a former eastern block country, this bring memories.
I went to high school in '90s and was assign in an intensive CS class. At the beginning, most of learning were done using pen and paper, writing pseudocode and also Pascal and C. Me and most of my peers were poor enough to not have a computer home, and the school only had ZX Spectrum clones running Basic. However, the school got some used 386 and 486 next years, so we got to use "the real deal". In my last year, my parents also got enough money to buy me an used 486 SLC - which got intense use since I also had Borland C++ compiler and a C++ for dummies book. I did my final project for CS in Borland C++ on that PC. It was a DOS based MS Paint clone.
Before that, I owned a ZX Spectrum clone when I was in secondary school, and while I did some programming, most of it was written on paper first and typed on Spectrum later. I compiled and debugged "in the brain" because I couldn't save programs and if a program halted, I had to reboot the thing wasting all I have written. A guy my father knew hacked a cassette player to help me load programs and games, but sadly it didn't work to save anything.
Even now, I sometimes like to draw diagrams, sketch code flow and write bits of pseudocode on paper before I start coding something, if I feel I need to clarify the idea.
It’s fun bringing the computers in to play as well, because I pitch to all my classes that we are in the age of information and the primary usefulness of algorithms is productivity.
A whimsical classroom example: programming a robot that can type for you, with an instruction set that consists of capital letters. Q returns to that key. LRDU are left a key, right, down, and up a key, and P means “press the key you are over”.
Step one: create robot code to type HELLO. Answer: QRRRRRDPLLLUPRRRRRRDPPUP.
Step two: create code to turn a robot code into a string: similate the robot essentially.
...which is about it for the coding, but then we make a robot print instructions for a second robot to print instructions for a third robot to print HELLO. We end up with something super weird looking but tractable because all the components were built from the ground up.
Computation is that wonderful meeting place between theory and leverage — the kind of leverage you get when you can do “2+2=4” 3 billion times a second.
"I'd like to welcome you to this course on Computer Science. Actually thats a terrible way to start. Computer science is a terrible name for this business. First of all, its not a science. It might be engineering or it might be art. Well actually see that computer so-called science actually has a lot in common with magic. We will see that in this course. So its not a science. Its also not really very much about computers. And its not about computers in the same sense that physics is not really about particle accelerators. And biology is not really about microscopes and petri dishes. And its not about computers in the same sense that geometry is not really about using a surveying instruments."
This loos like a nice thing to try and do with my kids while we are confined. Does anybody have any experience with it? Do you know of other comparable (or better) resources to introduce kids to CS?
I spent 20 years as a public school teacher and am still active in the Advanced Placement Computer Science teacher community.
This is good stuff, and very well-regarded by my colleagues.
Depending on the age of your kids, https://automatetheboringstuff.com/ or another of Al's books are quite good to start with and free to read.
For younger kids, Code.org's "Hour of Code" stuff uses Scratch, which is a nice block-based visual programming language that's still a real enough language under the hood; I had co-workers who used Scratch to have their AP CS students sorting lists of numbers and other "real" algorithmic tasks.
And I'd be remiss if I didn't mention the book I wrote, which is linked in my bio.
Former middle- and high-school CS teacher here. I also have used this with my students before. Most of the activities are definitely great and it's generally a well-regarded resource in the CS teaching community.
Not this program specifically, but in high school I was taught Pascal without touching the computer for the first couple of months. All of our programs had to be written by hand. And included traces of the code ... all the values of the variables throughout the lifetime of the program. I was disappointed at the time, but looking back, it was a great way to write code. It was more about the meaning of the code, not fighting compiler errors.
Edit: this would have been 1993, when I was in 9th grade.
I think that depends on your kid. I learned to code when I was 13 and I would have hated the computerless approach. I specifically remember being ~15 and someone pointing this out to me in an IRC room --- I thought that they were being pedantic. Older me now finds the stuff you do without a computer the most fun.
One suggestion I might have is, depending on their age, doing combinatorial game theory with them. That sounds really hard and fancy, but it's not (at least at the introductory level). There's a lot of games that are really simple to describe (e.g. counting games, simple board games) and your goal is to figure out the smartest move and / or if the player who starts the game can win.
My daughter's 10th grade programming teacher (<3 you, Mister Serota) had a pretty brilliant mechanic for teaching functions to kids in his class that he relayed to me, and which I will attempt to relay to you.
Effectively, he simply assigned some of the children in class to be 'a function.' Whatever input he gave them, they would have a predetermined routine to execute and give him output. E.g., "Billy, your function adds 2 to whatever input is given. Barbara, your function is to divide everything by 2. Samantha, your function is to determine whether or not dividing something by 2 will leave a remainder (modulo)."
Then he would work complex computations through the room with scripts he'd devised, showing the power of chaining functions together. Similarly, if you give Billy the "+2" function, and then give him an input value of "A", well, he might come back with "C" as the output, or he might come back with puzzlement, and you can teach error handling. Similarly, you can assign multiple kids the same functions (and show asynchrony, or hand them different bad values to show the possibility of inconsistent code).
TLDR: You "program" the children to be functions, feed them data, and then play around with how to best illustrate the concepts by manipulating the inputs and how you string them together.
Reminds me of my time in school in the early '90s. I was working for the university's Unix Admin group and as the only student in the group, I got sent on all the "broken workstation" house calls. The professors who almost uniformly had no idea how to use their computers were the ones in the computer science department.
They weren't stupid people, I had CS classes with many of them and they were brilliant. They just didn't care one bit about using computers. They were 100% into theory.
There is this anecdote about C.A.R. Hoare:
He never implemented quicksort. He also was never logged into the systems at the university where he resided.
[They also wanted to name a building after him (The Hoare-house) but for an unknown reason changed opinion. ;) But that's another story]
If we took computers away from software developers, maybe we'd get much more well thought out solutions. Probably much simpler, too, if they have to write out everything by hand :)
It seems to me most businesses don't care about quality but about productivity and the time to market.
For most LOB apps the only thing that matters is using framework X, applying some flavor of the day principles like SOLID and DDD, using some software patterns, gluing different libraries with some code, copy-pasting from Stack Overflow and writing tests. A productive, well oiled machine which churns out software.
As someone whose been programming for years, but weak on CS, would this have any advantages over following some other CS program thats closer to a traditional program?
It's mostly like that in some/many traditional CS programs anyway. A good number of my Professors really didn't know their way around a computer (that wasn't made up of an infinite paper tape and a read/write head...)
irrelevant but i remember a week ago someone on here said that books nowadays are written with the assumption that you would be in front of a computer to try the examples out. but decades ago, you read books in the evening and then come morning, you get to try out the code at the lab. authors today crammed so much in book than necessary.
i wonder if cs unplugged is better than godot gaming for teaching 8-10 year olds how to think and code.
Later on I realized that most jobs that ask for a CS degree don't actually have you doing any computer science. More often you are glueing together tools or writing a bunch of boring business logic for some specific application at best. At worst you are maintaining an old monolith trying to figure out someones logic from 15 years ago.
Having a CS background in most software jobs is useful in the same way having a chemistry background is useful to someone working as a nurse. Sure there will be situations where that knowledge might help you make a connection more quickly, but you're sure as hell not a chemist.