In the early 2000's, I entered a university at the EXACT trough between the Dotcom Crash and the Web 2.0 Moment. In fact, I transferred from a lower-tier uni to a top-tier CS uni. At the time, they had still retained their "weed out" approach to intro CS (in Lisp) from the late 90's, hoping to keep kids from taking CS while thinking "I'll make a website and money will rain from the skies!"
My new uni completely rejected my previous uni's Intro CS curriculum. They forced me to retake their version: A Lisp-then-Java cycle that was a theoretical whiplash, which initially I resented. Who wants to re-take a class for topics they "already" learned?
By my second year, I saw the light. I understood the approach.
While my highschool friends at other unis had courses to learn {{topic}} and separate courses to learn {{language}}, the uni I was at had a policy of "languages are incidental" for most courses. Professors had a list of the languages that they would accept for projects. "Anything but Perl" was common, although "systems" courses required C. For every class with a required language, it was not taught during class. There would be an optional lab that you could attend to learn at least one of the languages allowed for the course. The expectation was that you could learn enough in two or three weeks before the first project kicked off, and the TAs really were there to help you figure it out (most courses had 20-30 students for 2-3 TAs).
The "bookend" intro courses that taught extreme FP and extreme OOP served as a forcing function that made me realize "Oh, languages really don't matter. Just pick up the details for the paradigm, and get on with the work."
As much as I resented having to "redo" an intro course cycle at first, I am forever grateful for the fearlessness that the overall experienced instilled in me.
For every class with a required language, it was not taught during class.
This.
We did have the oblig "learn language X" course. Which used to be C and had just switched to Java at our uni. But it was just to learn a language.
The Operating System class used Minix in a VM to teach concepts. You were expected to just use a Minix vi (that was fun!) or somehow figure out yourself how to best use something outside while still having a fast enough feedback loop. Nobody taught us C (since we were already a Java language year. You were just expected to figure it out. Quite a bunch of people couldn't and literally quit CS entirely over that course. I loved it!). We had to add a memory compactification algorithm to Minix to pass the course. That was a fun learning experience! And made me appreciate modern (well, I guess this was like 25 years ago now lol!) operating systems.
Scripting languages course: Pick one and do a project and turn it in. That was it. (I turned in something I had written in Perl as a side-job for hire and got an A without doing any course work at all (except for the two initial attendance checked classes)
> languages really don't matter. Just pick up the details for the paradigm
True. The best programming books also reflect this ethos. Some people think Introduction to Functional Programming (1989) by Bird & Wadler is the best programming book ever.
The language-specific details (Miranda) are limited to a three-page appendix! The rest of the book is language agnostic, provided that your target language is functional.
I won't oversell myself. I am now in management, and have many close friends who are better programmers than I am, both generalist and specialized!
Because of the era, I was able to be the lead engineer (as a freelance consultant) at a number of startup companies which tragically no longer exist (for reasons of product-market-fit or product-channel-fit). Eventually I started my own, which is a B2B2C marketplace, a blend of ecommerce and event bookings. So the largest project is "a whole darn company that has survived a decade", including a near-death experience from COVID. From a technical perspective, it is not a very interesting project ;) People at Shopify or Eventbrite have seen more technical complexity in both spaces than I have.
While we use AI for many internal processes, we aren't doing anything particularly cutting-edge in the product itself. It's mostly about brand strategy, market alignment, and customer experience. My day-to-day is sometimes technical, but mostly management. And that's the trap, yeah? You get good at something you enjoy, and then you find out that there's more money in doing something different, helping other people do the thing you used to enjoy.
I apologize if that is not a satisfying answer. I am grateful for the very unique university experience I lucked into, but I am no savant.
My University in Eastern Europe was like this. They didn't have courses to learn languages but you had to use C for systems programming and Javascript for web frontends.
> Reading code, mostly. Tracing data through five layers of someone else's design choices. Forming a hypothesis about why the bug is happening, then testing the hypothesis, then narrowing. Recognising that the function in front of you is too big and asking what part of it has its own reason to exist. Recognising that the schema in front of you encodes a decision someone made in 2019 and that the decision is now load-bearing for things they did not anticipate. Knowing which of the five tempting cleanups in the file is going to bite you in production and which is safe.
It always struck me as strange that universities never had a course that would teach open source code. As in: grab a repo of a popular open source project, read part of it and do your best to create a contribution in it.
The lectures should be about different open source projects and their design choices.
In the CS bachelor degree I'm responsible of, we have exactly that in the third and last year (it's in France, so as in ~all Europe the licence lasts three years and then students continue their studies doing a master in two years).
I've been teaching this course for ten years now, and it's been fantastic. A lot of open source contributions, mostly trivial, but some more significant than others too, have been made, to a lot of different projects. It teaches students to actually work on a real code base, using a real workflow (fork, clone, branch, commits, PR, review, commits, review, … hopefully merge), talking (in English) with maintainers, having to update tests and documentation not just code, and having to respect a lot of conventions that are not always explicitly listed anywhere (a first work that I always ask them to do is to present the project they have chosen, its tools, platforms, and languages, and to list all the programming conventions (indentation, naming, etc.) they can identify). At the end of it, it also make them realize what they can do, because at the beginning of the semester most of them think they will never be able to actually make a contribution to a real project.
This year only there were contributions to NewPipe, Cartes.app, Immich, Fossify apps, PyGameEngine, Jax, Shortcut, Wikimedia Commons App, Godot, …
Some years ago I even had students contributing to ls (yes, in the GNU core-utils).
CS degrees are about computer science, not software engineering. The fact that the best available degree for a software developer is generally a CS degree is a historical accident, but regardless universities unfortunately don't tend to cater towards what CS students are actually getting their degree for
That would just result in projects being flooded with low quality submissions by students who don’t care but are forced to do it. And who get angry when you don’t merge it since they need you to for their course.
We have such a class at our university. We used to have students issue PRs to real projects but then stopped for that very reason. Now we have our own big OSS project that they work on quarter-to-quarter. Seems like a decent compromise.
Oh, since you're here, I want to say thank you for all your guides! I learned from them yeaaars ago, and still recommend them to my own students to this day, especially your network programming guide which is linked from all of the network lab session sheets of my systems and networks course. Thanks!
The solution would seem obvious: the lecturer should fork the repo, students submit PR to the fork and if they are deemed worthy they're pushed further upstream.
I teach such a course, and we don't have that. First, students must work on an existing issue of the project they choose and are only allowed (for my course) to submit an issue or a PR non related to an existing issue if they have already finished a first contribution that have been merged by the maintainers into to same project. The course grade is based on multiple factor and the code of the contribution itself is far from being the most important. The most important aspects are communication with the developers (and being respectful and polite certainly is significant) and the ability to identify and then respect the (often implicit) conventions of the project, as well as the proper use of the forge workflow for submitting a PR (fork, clone, branch, PR, discuss, etc.). Getting the contribution actually merged into the project is a neat bonus on the grade but is not required to pass the course.
Also, I totally ban using LLM, and unmotivated students often choose to work on very simple issues like easy refactoring or cosmetic aspects of web projects. It's okay with me for two reasons: first because it filters out unmotivated students from working of important issues and giving useless review work to open source maintainers, but also because we have all the other courses to do complex projects, here the point is to teach them by practice the workflow of contributing to an actual project, discussing with actual people, etc.
For some students it's already a good thing to have been able to get a copy of the latest development version of a given project, to install all of its development dependencies and tools, to compile it, and to reproduce the bug they chose to work on. It's not enough to pass the course, but it's a necessary first step to contribute to any project and it's quite a different experience from what they're used to with small school projects that are designed for teaching or that they entirely wrote themselves.
Yet precisely that is happening with LLMs generating code for a lot of people who don't really understand what they are submitting chasing clout for competing in the labor market.
You'd be (half-jokingly) amazed at how many people are entirely incapable of understanding and debugging an existing code base.
Like, literally: "Error message has string 'abdc-1234-something-whatever'". They can barely figure out to maybe search the code base for that error message. Unfortunately they can't find the full string. Now they're stuck and can't think of anything else to try.
So, effing, amazing. How do these people ever get through (coding) life? Ever heard of substring search coz error messages frequently have parts that are concatenated/variables inserted? Search for parts of it until you find something. It's not that hard dude, yes the 1234 probably is some dynamic id, so search for just something-whatever and you'll instantly find the relevant code and you can debug further.
But no, this "Senior" can't think of anything when not finding the full string anywhere in the codebase and would rather throw up their hands and let others figure it out.
Either a really dumb "Senior" that somehow got through so far at previous companies or they're silent quitting during probation period already.
I see it mentioned often, but it's a completely foreign stance to me. I'll take contributing to existing project over writing one from scratch any day, even if it's shitty enough to require general renovation. It's so much easier to jump onto work when there's an existing skeleton already than do all this boring grunt work to set things up and decide on layout that maybe was exciting when I was still only starting to learn how to program, but hasn't been for decades anymore.
I could see LLMs affecting that though. Their ability to output shitty and yet somewhat functional skeletons to work on manually further is just spot on.
Having taught at a university I'll say that the general reason is because there's already too much to teach, so you do your best. It's extra hard since there's a million people saying "why don't they teach X?" and you have to accommodate them.
There's problems like do you teach Python or C? It sounds silly but the difference is not about languages but how much you teach about systems. Teaching Python you get people going and they can produce faster, which does help students get less discouraged. But teaching C forces learning about the computer system and enables students to dive deeper to teach themselves many different subtopics that no 4 year program can.
What I think is generally missing and would be good to implement is code review and teaching how to understand a large existing codebase (all that grep, find, profilers, traces, tags, and all that jazz). This often gets taught in parallel (e.g. have students review each others code) but it's hit or miss, a lot of extra work, and not everyone does it.
Here's the shitty part: I was often told by peers and people higher up "don't look at student's code, just look at output and run tests." I always ignored, because that advice is why we're failing so many students. But I also understand it because professors are overburdened. There's too much work to do and teaching isn't even half the job. Then every new administrator or "office assistant" they hire, the more work you have (seriously, it'll take days to book a flight because you have to use some code but it takes 2 days for someone to tell you the code and 5 more to tell you that it was the wrong code and it's clearly your fault because you clicked on "book flight" and not trips > booking > flights > schedules > trips > access code > flights > search available flights. Honestly, I think all this llm agent stuff would sound silly if people actually just knew how to design things...)
I'm responsible for a CS bachelor degree in France (licence informatique). In our curriculum, we teach how to learn programming and then programming paradigms, not languages, and we use a lot of different programming languages for that from the first semester. At the end of the first year, our students have already approached 4 programming paradigms using ~10 different programming languages, during the second year this is reinforced by the introduction of a new paradigm (OOP) and some more advanced course using different languages (for example the introduction to functional programming in the first year mostly uses Racket, but our second functional programming course in the second year uses OCaml).
Grew up with this guy. We both did community college courses on programming before we were out out high school. I'm impressed with the library he's built up and CCs tend to be more pragmatic than UCs in California.
This isn't a plug/whatever - just good content from an old friend.
To be fair, to learn to think, you have to learn the language first.
Learning to program without knowing the language is useless and counter-productive.
Of course, this doesn't mean you have to learn 10+ languages first... but you have to learn a real programming language (not a toy one) before you can learn to program.
> To be fair, to learn to think, you have to learn the language first.
Which language is the language? A competent programmer can think about programming and reason about programs written in most languages without having to know that particular language intimately (with some exceptions that push outside the normal algorithmic language notation of the Fortran, C, Java, JS, Common Lisp, Rust, Go, etc. family of languages; but those are minority languages and a competent programmer shouldn't need more than a short period of time to become literate, if not expressive, in it).
> A competent programmer can think about programming and reason about programs written in most languages without having to know that particular language intimately
That's because the programmer already learned how to program.
But when they started, they definitely didn't write only pseudocode that wasn't runnable (to see the results) for months/years.
> they definitely didn't write only pseudocode that wasn't runnable (to see the results) for months/years.
GT started students that way and it worked well for years. A full semester (number varied, but was the CS 101 course, 1301/1311/1501 or something like that), taught with only pseudocode. They got rid of it because of appearances, trying to be like every other school out there. Eventually settling on Python, I think, after a brief stint with Scheme (which ended after a major cheating scandal).
This, we learn natural language like English first before we can use it to express ideas, argue for or against those ideas with evidence. The problem is not teaching a programming language, the problem is stopping there and not teaching how to use it to solve real problems.
In The Art Of Computer Programming, one of the most influential and comprehensive series of books on the subject, Knuth uses a fictional assembly language called MIX in the examples. The reader does "just run the program in their head."
In Software Tools Brian Kernighan and P.J. Plauger describe a pseudo-language called RATFOR (Rational Fortran), and then throughout the book implement RATFOR in itself.
Getting feedback while learning to program has a lot of value, but so does learning to think through code in your head. People old enough to remember when you had to wait a day to run your program and get results back (very slow turnaround) know the value of that skill, we used to call it "desk checking" -- reading through your code and running it in your head and on paper.
This is itself a skill people need to learn, that I'm not sure is possible with pseudocode and no prior experience. Too easy to gloss over details without actually running it to learn where your blind spots are.
I did this workshop a decade or so ago where I learned my co-workers don't do this, and never did learn how they understand code otherwise. One of them mentioned he didn't even realize this was a thing.
> never did learn how they understand code otherwise.
This particular statement interested me.
In code review, I always am a stickler that "if I need to run the code in my head to prove something about it for me, I want to see that in a unit test - I shouldn't have questions about the code that aren't already answered by the tests"
When I took an introductory programming class at Sacramento City College in fall 2004 during my senior year of high school, we spent the first half of the semester designing our programs using flowcharts and pseudocode. We were encouraged to check the logic of our flowcharts and pseudocode. In the second half of the semester, we implemented those programs in C++.
I haven’t seen this pedagogical practice in any other introductory course I’ve seen since. I believe it’s a holdover from the early days of computing, when programmers didn’t have access to personal computers or even interactive computing, which meant that programmers needed to spend more up-front time on design. Think of the punchcard era, for example.
I teach introductory programming in C++ at Ohlone College in Fremont, and I have my students write C++ on Day 1, starting with “Hello World” and going from there without flowcharts.
I think it's for all intents and purposes impossible to program like this in this century. Like imagine just writing x + y in C++. Are you seriously going to enumerate every declaration of operator+ in the translation unit in your head to see if it's eligible (don't forget ADL)? And then every single possible implicit conversion or promotion that could make other ones eligible? And then go through all the overload resolution rules that practically no humans have memorized (with any template instantiations that may come into play) to figure out if the declaration you wanted is actually the best match? That's before you even look at its definition...
In one of my classes they had to explicitly ban people from using Python in their psuedocode submissions lol. (Generally this meant things like "no list comprehensions" and similar Python syntax details).
Not at all. It's called learning computer science. Just like you can do calculus without simulation, you can understand the semantics of a computer program without running it. It might make it harder, but running it is only a didactic tool - as Knuth did, you should be able to prove it correct without ever running it.
It's funny, I learned a pile of languages in my undergrad and some UML nonsense. None of it covered properly how to write code that was meant to be read, which IMHO is one of the most basic things.
Just "hey nobody can understand why that line is the way it is, what should we do about that" is probably one of the basic building-block skills of developing on a team, and you teach it wholly by abusing prima donna cowboys until they write something legible or quit.
Sorry I am pasting my old comment here, but the intention is same Before learning programming one should know what is computing in general? It sets good mental model, after that you can easily pickup and start writing program yourself .
Data, data, data :)))
Some basic notions to know: Input → Computation → Output
Information is omnipresent (this is just an intuition, not a claim). It serves as both input and output.
Computation—also known as a procedure, function, set of instructions, transformation, method, algorithm, or calculation.
In my early days, I ignored the fundamental notion of data and procedures. But eventually, it clicked: Programs = Data + Instructions
Watch Feynman on computing—he even starts with the same concept of data, introducing computers as information processing systems. And processing requires algorithms (i.e., instructions or procedures).
Programming is simply writing instructions for the computer to perform computations.
A computer is just a machine for computing.
Computation is a general idea: a transformation of one form of information into another.
Aside: so this guy pops up 3 days ago with this vibecoded sort of site and is epically AI-blogging so now we have three posts on the front page at the same time-ish? Great. Take it easy OP.
It started with all courses teaching algorithms but on the day job you wrote all algorithms by searching it on web or via a library.
Now they teach language but you just ask agents to check the accuracy of code and rarely read it.
Only few devs wrote new algorithms and only few devs will now write the actual new code. These few devs don't need courses but all other devs need to pretend that they are part of these "few" so they need all the courses, just in case...
I’m convinced my love of grocery store checkout logic puzzle books are the foundation of my programming skills. I was also good in tenth grade geometry which is all logic.
Yeah, but most* companies hire for just whatever X programming language they use, and do not care if you know how to program and do not care that you could pick up whatever X is in a couple of weeks. (Anecdotally for "most", I am sure there are exceptions)
Honest question, is leetcode tests an actual failure from the recruiting company perspective?
Sure, it means that from time to time you will reject people like the Homebrew creator. And it also means the recruiting process now sucks for the applicant.
But in a context where it's extremely tricky to evaluate an applicant during the short span of an interview, it seems honestly like the least "arbitrary/trusting your vibes" recruiting method we have now which could be deployed at a large scale.
At least, you are getting people you know had the ability to remember this stuff, and also were willing to put in the effort to learn it.
Leetcode is fine for large companies where software engineering is essentially a factory worker position - you take ticket in, produce code out. Engineers have very little say in the product or business.
In this situation, things like soft skills, thinking outside the box, etc are actually a downside. Rejecting the Homebrew creator is a desirable outcome in that case - because said creator is unlikely put up with "ticket factory" work.
If you legitimately need a "ticket to code" machine, Leetcode is the right approach. Just that most non-FAANG businesses need more than just "ticket to code", and then Leetcode becomes the wrong answer.
The harder leetcode interviews I've had, I definitely was not prepared for simply from college material. Some companies really throw the kitchen sink at you.
The more reasonable coding interviews I've had, on the other hand, I could have solved before even going to college. Those companies were (rightfully) just trying to get a sense for whether you can write and debug code in the real world, not memorize algorithms.
Applicants definitely peak in their leet code ability at graduation. Probably doesn't help that they're have lots of free time and motivation to grind for their first job. It's a mistake to hold more senior people to same standard.
Alright, this website is horrible to read and feels like MySpace in 2002. Did anyone actually spend time and read this? Or are we all just riffing off the title?
I can see why many people wouldn’t like it but I like it because of this. It’s not my style and I wouldn’t do a site like this for myself but it represents a time when the web was an extension of personal expression.
This appears to be the author’s personal style and taste. I’d wager the software he writes for others doesn’t look like this so this is probably creative outlet. I don’t need to look at yet another shadcdn, tailwind cookie cutter sass when reading someone’s blog.
In the early 2000's, I entered a university at the EXACT trough between the Dotcom Crash and the Web 2.0 Moment. In fact, I transferred from a lower-tier uni to a top-tier CS uni. At the time, they had still retained their "weed out" approach to intro CS (in Lisp) from the late 90's, hoping to keep kids from taking CS while thinking "I'll make a website and money will rain from the skies!"
My new uni completely rejected my previous uni's Intro CS curriculum. They forced me to retake their version: A Lisp-then-Java cycle that was a theoretical whiplash, which initially I resented. Who wants to re-take a class for topics they "already" learned?
By my second year, I saw the light. I understood the approach.
While my highschool friends at other unis had courses to learn {{topic}} and separate courses to learn {{language}}, the uni I was at had a policy of "languages are incidental" for most courses. Professors had a list of the languages that they would accept for projects. "Anything but Perl" was common, although "systems" courses required C. For every class with a required language, it was not taught during class. There would be an optional lab that you could attend to learn at least one of the languages allowed for the course. The expectation was that you could learn enough in two or three weeks before the first project kicked off, and the TAs really were there to help you figure it out (most courses had 20-30 students for 2-3 TAs).
The "bookend" intro courses that taught extreme FP and extreme OOP served as a forcing function that made me realize "Oh, languages really don't matter. Just pick up the details for the paradigm, and get on with the work."
As much as I resented having to "redo" an intro course cycle at first, I am forever grateful for the fearlessness that the overall experienced instilled in me.
We did have the oblig "learn language X" course. Which used to be C and had just switched to Java at our uni. But it was just to learn a language.
The Operating System class used Minix in a VM to teach concepts. You were expected to just use a Minix vi (that was fun!) or somehow figure out yourself how to best use something outside while still having a fast enough feedback loop. Nobody taught us C (since we were already a Java language year. You were just expected to figure it out. Quite a bunch of people couldn't and literally quit CS entirely over that course. I loved it!). We had to add a memory compactification algorithm to Minix to pass the course. That was a fun learning experience! And made me appreciate modern (well, I guess this was like 25 years ago now lol!) operating systems.
Scripting languages course: Pick one and do a project and turn it in. That was it. (I turned in something I had written in Perl as a side-job for hire and got an A without doing any course work at all (except for the two initial attendance checked classes)
> languages really don't matter. Just pick up the details for the paradigm
True. The best programming books also reflect this ethos. Some people think Introduction to Functional Programming (1989) by Bird & Wadler is the best programming book ever.
The language-specific details (Miranda) are limited to a three-page appendix! The rest of the book is language agnostic, provided that your target language is functional.
"Anything but Perl" was common
I would probably be the one to choose x86 Asm or APL... or even a mix of the two.
you are a Raku programmer :-)
What's the largest project you've spearheaded with your knowledge?
I won't oversell myself. I am now in management, and have many close friends who are better programmers than I am, both generalist and specialized!
Because of the era, I was able to be the lead engineer (as a freelance consultant) at a number of startup companies which tragically no longer exist (for reasons of product-market-fit or product-channel-fit). Eventually I started my own, which is a B2B2C marketplace, a blend of ecommerce and event bookings. So the largest project is "a whole darn company that has survived a decade", including a near-death experience from COVID. From a technical perspective, it is not a very interesting project ;) People at Shopify or Eventbrite have seen more technical complexity in both spaces than I have.
While we use AI for many internal processes, we aren't doing anything particularly cutting-edge in the product itself. It's mostly about brand strategy, market alignment, and customer experience. My day-to-day is sometimes technical, but mostly management. And that's the trap, yeah? You get good at something you enjoy, and then you find out that there's more money in doing something different, helping other people do the thing you used to enjoy.
I apologize if that is not a satisfying answer. I am grateful for the very unique university experience I lucked into, but I am no savant.
A life in tech filled with gratitude and fearlessness seems like a huge achievement in my eyes.
perl got fixed btw … now called Raku
My University in Eastern Europe was like this. They didn't have courses to learn languages but you had to use C for systems programming and Javascript for web frontends.
It was also math heavy and theoretical CS heavy.
> Reading code, mostly. Tracing data through five layers of someone else's design choices. Forming a hypothesis about why the bug is happening, then testing the hypothesis, then narrowing. Recognising that the function in front of you is too big and asking what part of it has its own reason to exist. Recognising that the schema in front of you encodes a decision someone made in 2019 and that the decision is now load-bearing for things they did not anticipate. Knowing which of the five tempting cleanups in the file is going to bite you in production and which is safe.
It always struck me as strange that universities never had a course that would teach open source code. As in: grab a repo of a popular open source project, read part of it and do your best to create a contribution in it.
The lectures should be about different open source projects and their design choices.
In the CS bachelor degree I'm responsible of, we have exactly that in the third and last year (it's in France, so as in ~all Europe the licence lasts three years and then students continue their studies doing a master in two years).
I've been teaching this course for ten years now, and it's been fantastic. A lot of open source contributions, mostly trivial, but some more significant than others too, have been made, to a lot of different projects. It teaches students to actually work on a real code base, using a real workflow (fork, clone, branch, commits, PR, review, commits, review, … hopefully merge), talking (in English) with maintainers, having to update tests and documentation not just code, and having to respect a lot of conventions that are not always explicitly listed anywhere (a first work that I always ask them to do is to present the project they have chosen, its tools, platforms, and languages, and to list all the programming conventions (indentation, naming, etc.) they can identify). At the end of it, it also make them realize what they can do, because at the beginning of the semester most of them think they will never be able to actually make a contribution to a real project.
This year only there were contributions to NewPipe, Cartes.app, Immich, Fossify apps, PyGameEngine, Jax, Shortcut, Wikimedia Commons App, Godot, …
Some years ago I even had students contributing to ls (yes, in the GNU core-utils).
That sounds like a lovely course to take.
CS degrees are about computer science, not software engineering. The fact that the best available degree for a software developer is generally a CS degree is a historical accident, but regardless universities unfortunately don't tend to cater towards what CS students are actually getting their degree for
That would just result in projects being flooded with low quality submissions by students who don’t care but are forced to do it. And who get angry when you don’t merge it since they need you to for their course.
We have such a class at our university. We used to have students issue PRs to real projects but then stopped for that very reason. Now we have our own big OSS project that they work on quarter-to-quarter. Seems like a decent compromise.
Oh, since you're here, I want to say thank you for all your guides! I learned from them yeaaars ago, and still recommend them to my own students to this day, especially your network programming guide which is linked from all of the network lab session sheets of my systems and networks course. Thanks!
Thank you for the network programming guide.
The solution would seem obvious: the lecturer should fork the repo, students submit PR to the fork and if they are deemed worthy they're pushed further upstream.
I teach such a course, and we don't have that. First, students must work on an existing issue of the project they choose and are only allowed (for my course) to submit an issue or a PR non related to an existing issue if they have already finished a first contribution that have been merged by the maintainers into to same project. The course grade is based on multiple factor and the code of the contribution itself is far from being the most important. The most important aspects are communication with the developers (and being respectful and polite certainly is significant) and the ability to identify and then respect the (often implicit) conventions of the project, as well as the proper use of the forge workflow for submitting a PR (fork, clone, branch, PR, discuss, etc.). Getting the contribution actually merged into the project is a neat bonus on the grade but is not required to pass the course.
Also, I totally ban using LLM, and unmotivated students often choose to work on very simple issues like easy refactoring or cosmetic aspects of web projects. It's okay with me for two reasons: first because it filters out unmotivated students from working of important issues and giving useless review work to open source maintainers, but also because we have all the other courses to do complex projects, here the point is to teach them by practice the workflow of contributing to an actual project, discussing with actual people, etc.
For some students it's already a good thing to have been able to get a copy of the latest development version of a given project, to install all of its development dependencies and tools, to compile it, and to reproduce the bug they chose to work on. It's not enough to pass the course, but it's a necessary first step to contribute to any project and it's quite a different experience from what they're used to with small school projects that are designed for teaching or that they entirely wrote themselves.
Yet precisely that is happening with LLMs generating code for a lot of people who don't really understand what they are submitting chasing clout for competing in the labor market.
lessons could be learned without submitting upstream PRs
You and I both know it's easier to rewrite a project from scratch than contribute to somebody else's project. Only half-joking.
You'd be (half-jokingly) amazed at how many people are entirely incapable of understanding and debugging an existing code base.
Like, literally: "Error message has string 'abdc-1234-something-whatever'". They can barely figure out to maybe search the code base for that error message. Unfortunately they can't find the full string. Now they're stuck and can't think of anything else to try.
So, effing, amazing. How do these people ever get through (coding) life? Ever heard of substring search coz error messages frequently have parts that are concatenated/variables inserted? Search for parts of it until you find something. It's not that hard dude, yes the 1234 probably is some dynamic id, so search for just something-whatever and you'll instantly find the relevant code and you can debug further.
But no, this "Senior" can't think of anything when not finding the full string anywhere in the codebase and would rather throw up their hands and let others figure it out.
Either a really dumb "Senior" that somehow got through so far at previous companies or they're silent quitting during probation period already.
If this continues it's not gonna be silent.
I see it mentioned often, but it's a completely foreign stance to me. I'll take contributing to existing project over writing one from scratch any day, even if it's shitty enough to require general renovation. It's so much easier to jump onto work when there's an existing skeleton already than do all this boring grunt work to set things up and decide on layout that maybe was exciting when I was still only starting to learn how to program, but hasn't been for decades anymore.
I could see LLMs affecting that though. Their ability to output shitty and yet somewhat functional skeletons to work on manually further is just spot on.
Having taught at a university I'll say that the general reason is because there's already too much to teach, so you do your best. It's extra hard since there's a million people saying "why don't they teach X?" and you have to accommodate them.
There's problems like do you teach Python or C? It sounds silly but the difference is not about languages but how much you teach about systems. Teaching Python you get people going and they can produce faster, which does help students get less discouraged. But teaching C forces learning about the computer system and enables students to dive deeper to teach themselves many different subtopics that no 4 year program can.
What I think is generally missing and would be good to implement is code review and teaching how to understand a large existing codebase (all that grep, find, profilers, traces, tags, and all that jazz). This often gets taught in parallel (e.g. have students review each others code) but it's hit or miss, a lot of extra work, and not everyone does it.
Here's the shitty part: I was often told by peers and people higher up "don't look at student's code, just look at output and run tests." I always ignored, because that advice is why we're failing so many students. But I also understand it because professors are overburdened. There's too much work to do and teaching isn't even half the job. Then every new administrator or "office assistant" they hire, the more work you have (seriously, it'll take days to book a flight because you have to use some code but it takes 2 days for someone to tell you the code and 5 more to tell you that it was the wrong code and it's clearly your fault because you clicked on "book flight" and not trips > booking > flights > schedules > trips > access code > flights > search available flights. Honestly, I think all this llm agent stuff would sound silly if people actually just knew how to design things...)
I believe when i was at utoronto the compsci dept had a course like this (2005ish)
umich currently has a course like this (but it's a bit of a blowoff)
I'm responsible for a CS bachelor degree in France (licence informatique). In our curriculum, we teach how to learn programming and then programming paradigms, not languages, and we use a lot of different programming languages for that from the first semester. At the end of the first year, our students have already approached 4 programming paradigms using ~10 different programming languages, during the second year this is reinforced by the introduction of a new paradigm (OOP) and some more advanced course using different languages (for example the introduction to functional programming in the first year mostly uses Racket, but our second functional programming course in the second year uses OCaml).
Grew up with this guy. We both did community college courses on programming before we were out out high school. I'm impressed with the library he's built up and CCs tend to be more pragmatic than UCs in California.
This isn't a plug/whatever - just good content from an old friend.
https://www.youtube.com/@ProfessorHankStalica
To be fair, to learn to think, you have to learn the language first.
Learning to program without knowing the language is useless and counter-productive.
Of course, this doesn't mean you have to learn 10+ languages first... but you have to learn a real programming language (not a toy one) before you can learn to program.
Edit: * a language
> To be fair, to learn to think, you have to learn the language first.
Which language is the language? A competent programmer can think about programming and reason about programs written in most languages without having to know that particular language intimately (with some exceptions that push outside the normal algorithmic language notation of the Fortran, C, Java, JS, Common Lisp, Rust, Go, etc. family of languages; but those are minority languages and a competent programmer shouldn't need more than a short period of time to become literate, if not expressive, in it).
I meant "a language". Corrected it.
> A competent programmer can think about programming and reason about programs written in most languages without having to know that particular language intimately
That's because the programmer already learned how to program.
But when they started, they definitely didn't write only pseudocode that wasn't runnable (to see the results) for months/years.
> they definitely didn't write only pseudocode that wasn't runnable (to see the results) for months/years.
GT started students that way and it worked well for years. A full semester (number varied, but was the CS 101 course, 1301/1311/1501 or something like that), taught with only pseudocode. They got rid of it because of appearances, trying to be like every other school out there. Eventually settling on Python, I think, after a brief stint with Scheme (which ended after a major cheating scandal).
This, we learn natural language like English first before we can use it to express ideas, argue for or against those ideas with evidence. The problem is not teaching a programming language, the problem is stopping there and not teaching how to use it to solve real problems.
Bullshit.
You need to learn to leetcode in psuedocode first.
Bullshit.
I never see anyone learning to program using pseudocode (which isn't runnable to get feedback).
If they used pseudocode, were they just run the program in their heads?
In The Art Of Computer Programming, one of the most influential and comprehensive series of books on the subject, Knuth uses a fictional assembly language called MIX in the examples. The reader does "just run the program in their head."
In Software Tools Brian Kernighan and P.J. Plauger describe a pseudo-language called RATFOR (Rational Fortran), and then throughout the book implement RATFOR in itself.
Getting feedback while learning to program has a lot of value, but so does learning to think through code in your head. People old enough to remember when you had to wait a day to run your program and get results back (very slow turnaround) know the value of that skill, we used to call it "desk checking" -- reading through your code and running it in your head and on paper.
The newer versions use MMIX which is much closer to ARM assembly.
There's a compiler plugin for gcc, and when I worked through volume 1 I did type the code in and run the exercises.
I found it incredibly useful, but obviously YMMV.
Sure it is useful to run code in your head. I didn't say we must not think through code.
But to unable to run actual code at all? Come on. Who learns programming that way?
I don't think anyone suggested that.
I suggested that. You should be able to look at algorithmic code and prove it correct without worrying about running it.
> But to unable to run actual code at all? Come on. Who learns programming that way?
Edsger Dijkstra was a proponent of that approach i.e. develop program and proof by hand in a language for which there is no compiler/interpreter.
I wrote about it here - https://news.ycombinator.com/item?id=47985605
> were they just run the program in their heads?
This is itself a skill people need to learn, that I'm not sure is possible with pseudocode and no prior experience. Too easy to gloss over details without actually running it to learn where your blind spots are.
I did this workshop a decade or so ago where I learned my co-workers don't do this, and never did learn how they understand code otherwise. One of them mentioned he didn't even realize this was a thing.
> never did learn how they understand code otherwise.
This particular statement interested me.
In code review, I always am a stickler that "if I need to run the code in my head to prove something about it for me, I want to see that in a unit test - I shouldn't have questions about the code that aren't already answered by the tests"
When I took an introductory programming class at Sacramento City College in fall 2004 during my senior year of high school, we spent the first half of the semester designing our programs using flowcharts and pseudocode. We were encouraged to check the logic of our flowcharts and pseudocode. In the second half of the semester, we implemented those programs in C++.
I haven’t seen this pedagogical practice in any other introductory course I’ve seen since. I believe it’s a holdover from the early days of computing, when programmers didn’t have access to personal computers or even interactive computing, which meant that programmers needed to spend more up-front time on design. Think of the punchcard era, for example.
I teach introductory programming in C++ at Ohlone College in Fremont, and I have my students write C++ on Day 1, starting with “Hello World” and going from there without flowcharts.
I think it's for all intents and purposes impossible to program like this in this century. Like imagine just writing x + y in C++. Are you seriously going to enumerate every declaration of operator+ in the translation unit in your head to see if it's eligible (don't forget ADL)? And then every single possible implicit conversion or promotion that could make other ones eligible? And then go through all the overload resolution rules that practically no humans have memorized (with any template instantiations that may come into play) to figure out if the declaration you wanted is actually the best match? That's before you even look at its definition...
In one of my classes they had to explicitly ban people from using Python in their psuedocode submissions lol. (Generally this meant things like "no list comprehensions" and similar Python syntax details).
/s
?
Not at all. It's called learning computer science. Just like you can do calculus without simulation, you can understand the semantics of a computer program without running it. It might make it harder, but running it is only a didactic tool - as Knuth did, you should be able to prove it correct without ever running it.
Yes but not everyone learns like that. Some people need to feel something before learning the theory. It makes the theory easier to digest.
It's funny, I learned a pile of languages in my undergrad and some UML nonsense. None of it covered properly how to write code that was meant to be read, which IMHO is one of the most basic things.
Just "hey nobody can understand why that line is the way it is, what should we do about that" is probably one of the basic building-block skills of developing on a team, and you teach it wholly by abusing prima donna cowboys until they write something legible or quit.
Sorry I am pasting my old comment here, but the intention is same Before learning programming one should know what is computing in general? It sets good mental model, after that you can easily pickup and start writing program yourself .
Data, data, data :)))
Some basic notions to know: Input → Computation → Output
Information is omnipresent (this is just an intuition, not a claim). It serves as both input and output.
Computation—also known as a procedure, function, set of instructions, transformation, method, algorithm, or calculation.
In my early days, I ignored the fundamental notion of data and procedures. But eventually, it clicked: Programs = Data + Instructions
Watch Feynman on computing—he even starts with the same concept of data, introducing computers as information processing systems. And processing requires algorithms (i.e., instructions or procedures).
Programming is simply writing instructions for the computer to perform computations.
A computer is just a machine for computing.
Computation is a general idea: a transformation of one form of information into another.
https://en.wikipedia.org/wiki/IPO_model
Richard Feynman Computer Science Lecture: https://www.youtube.com/watch?v=EKWGGDXe5MA
Old documentry on programming: https://www.youtube.com/watch?v=dFZecokdHLo
George Hotz video: what is programming? https://www.youtube.com/watch?v=N2bXEUSAiTI
https://denninginstitute.com/pjd/GP/gp_overview.html
https://htdp.org/2003-09-26/Book/curriculum-Z-H-5.html#node_...
https://www3.nhk.or.jp/nhkworld/en/shows/texico/
Aside: so this guy pops up 3 days ago with this vibecoded sort of site and is epically AI-blogging so now we have three posts on the front page at the same time-ish? Great. Take it easy OP.
It started with all courses teaching algorithms but on the day job you wrote all algorithms by searching it on web or via a library.
Now they teach language but you just ask agents to check the accuracy of code and rarely read it.
Only few devs wrote new algorithms and only few devs will now write the actual new code. These few devs don't need courses but all other devs need to pretend that they are part of these "few" so they need all the courses, just in case...
https://cs.ossu.dev/coursepages/spd/ UBC teaches programming
I’m convinced my love of grocery store checkout logic puzzle books are the foundation of my programming skills. I was also good in tenth grade geometry which is all logic.
How to Design Programs: https://htdp.org/2026-2-25//Book/index.html
I agree with the sentiment, except you learn these things on the job, by making mistakes and asking questions.
Yeah, but most* companies hire for just whatever X programming language they use, and do not care if you know how to program and do not care that you could pick up whatever X is in a couple of weeks. (Anecdotally for "most", I am sure there are exceptions)
Not FAANG. They just need to know you can leetcode extremely fast in arbitrary languages.
junior ask: how to start programming? me: write process in natural language first. no code yet. ...whatever you do, don't write code yet.
it appears to me that there may be a gate-keeping involved that stops the hordes from really learning how to program.
Look at the books on programming in the last 15 years--none teaches how to program and problem-solve.
If you want to be a good developer, learn to program.
If you want to be a well-paid developer, learn leetcode.
Good point, developing oneself and acquiring skills is often at odds with maximizing one's income.
So much of what is debated on HN is people talking past each other from these opposing perspectives.
Honest question, is leetcode tests an actual failure from the recruiting company perspective?
Sure, it means that from time to time you will reject people like the Homebrew creator. And it also means the recruiting process now sucks for the applicant.
But in a context where it's extremely tricky to evaluate an applicant during the short span of an interview, it seems honestly like the least "arbitrary/trusting your vibes" recruiting method we have now which could be deployed at a large scale.
At least, you are getting people you know had the ability to remember this stuff, and also were willing to put in the effort to learn it.
Leetcode is fine for large companies where software engineering is essentially a factory worker position - you take ticket in, produce code out. Engineers have very little say in the product or business.
In this situation, things like soft skills, thinking outside the box, etc are actually a downside. Rejecting the Homebrew creator is a desirable outcome in that case - because said creator is unlikely put up with "ticket factory" work.
If you legitimately need a "ticket to code" machine, Leetcode is the right approach. Just that most non-FAANG businesses need more than just "ticket to code", and then Leetcode becomes the wrong answer.
I’ve felt what I learned in my CS degree has been sufficient to allow me to perform well in leetcode interviews.
The harder leetcode interviews I've had, I definitely was not prepared for simply from college material. Some companies really throw the kitchen sink at you.
The more reasonable coding interviews I've had, on the other hand, I could have solved before even going to college. Those companies were (rightfully) just trying to get a sense for whether you can write and debug code in the real world, not memorize algorithms.
yea dawg maybe if you graduated in the last 4 years lmao
Applicants definitely peak in their leet code ability at graduation. Probably doesn't help that they're have lots of free time and motivation to grind for their first job. It's a mistake to hold more senior people to same standard.
Alright, this website is horrible to read and feels like MySpace in 2002. Did anyone actually spend time and read this? Or are we all just riffing off the title?
> feels like MySpace 2002
I can see why many people wouldn’t like it but I like it because of this. It’s not my style and I wouldn’t do a site like this for myself but it represents a time when the web was an extension of personal expression.
This appears to be the author’s personal style and taste. I’d wager the software he writes for others doesn’t look like this so this is probably creative outlet. I don’t need to look at yet another shadcdn, tailwind cookie cutter sass when reading someone’s blog.
Firefox Reader Mode saves the day yet again!
Look on my works, ye Chrome Heathens, and despair!
Who still does boot camps in $currentyear?
You can get all these fundamentals for free and probably better from an LLM.