by danielam on 12/17/24, 12:46 PM with 111 comments
by mjdiloreto on 12/19/24, 1:30 PM
The combination of the "program design" process and the simplicity of the teaching language (student Racket) made the introductory courses at Northeastern excellent. I found that students who already had lots of programming experience hated the initial courses, but those of us with limited experience really excelled. For me, it really validates that Dijkstra quote about Basic programmers being psychologically injured.
The second introductory course used Java, but it mostly covered all the same topics as the first Racket-based course, just using Java constructs. It was a much more gentle introduction to the extra complexity of "real" programming languages, but the program design process was identical.
As I understand it, Northeastern is unique in its CS pedagogy, and there's only 1 other school I know of (WPI) that uses Racket as its teaching language. I will always be grateful for my time there.
by dakiol on 12/19/24, 10:54 AM
by hahahacorn on 12/19/24, 8:55 AM
I think that the curriculum design and principles that guide the NEU CS education are fantastic. I’ve been fortunate (or unfortunate, depending on your perspective) to quickly find myself in a mentorship position at work, and there have been a number of times where I realize that the boot camp hire just isn’t thinking the way I do _at all_. The first things drilled into my head were function signatures and manipulating data structures (by implementing a subset of the ruby enumerable module in Racket). This has made problem solving by manipulating data structures (a decently common part of the job, especially at first!) genuinely trivial. Things more or less immediately translate to a map, filter, andmap, ormap, or reduce when trying to get data from its input to its output for whatever unit of work I’m trying to do.
Other developers on my team though experience each new technique/thing as a new or different thing, which to me seems far more overwhelming. I think most developers naturally develop the intuition, but being told upfront “everything is just these 5 or a combination of them lol” implicitly by the work we were doing was something I’m grateful for.
I never enjoyed the pair programming at Northeastern. I was so behind my peers at the time, since most everyone else was like an AP CS student or had been coding since they were a child. I was busy trying to brute force the learning with 40+ hour weeks just for the CS fundamentals classes. I never found someone in my position. I was only paired with people that the intro course was trivial for or they just did not care at all haha. Most brutal part was waiting 5+ hours at office hours with a white board wait list 90+ names deep and then office hours would end and they would send us home. Life before ChatGPT was crazy.
by Izkata on 12/19/24, 7:11 PM
Specifically: I've had multiple co-workers who learned one programming language (bootcamp, self-taught, or otherwise) and were resistant to learning another one. Based on things they've said after I'd pushed them to do something in another language, I think their resistance was entirely because they remember how difficult the first programming language was and expect further languages to be similarly difficult. Instead, as they start to actually work with the second language they realize how much is conceptually similar - the things this article refers to as typically learned implicitly through experience.
But the alternate style described in the article does the same thing: moving from a sort-of pseudocode (the design process) to student Racket to Java (per another comment here) gets that same implicit learning benefit independent of a full restructuring of the curriculum.
I wouldn't be surprised if keeping the more traditional style and simply requiring different languages in different courses/years gets most of the benefits with minimal changes.
by delusional on 12/19/24, 12:48 PM
I've since leveled out a bit. With the technical stuff roughly figured out. I've since moved on to the people problems, and there it's much more about the cooperation. I couldn't meaningfully contribute to those "people problems" If I didn't have the antisocial beginnings though.
I have a hard time "developing" developers, when I look back at my own lived experience. I like what and who I am, but the cost has been pretty steep. I'm not sure I can take other people down that path in good consistence.
by somethingsome on 12/19/24, 8:22 PM
Similar approach for first years in two of the main universities in Belgium.
One uses lisp with SICP, the other the language developed in this book (Oz).
The book constructs many of the current programming paradigms, starting from almost nothing, with an emphasis on software design.
by achenet on 12/19/24, 8:53 AM
It would be interesting to see this method actually works, i.e. if Northeastern programmers are "more useful to their employers"/"better developers" than graduates of Universities using the older approach ('tinker until it works', as the featured article puts it)
by cushychicken on 12/19/24, 1:44 PM
They have all had some exposure to real world engineering practices in their respective disciplines’ teaching tracks.
They have to do coops to graduate, so you have them to work with for six months instead of ten weeks.
They are all eager to do real work and ship real stuff, and they understand quickly how to integrate into a team to do that. I don’t know if this is a selective property of Northeastern’s culture or something they instill in their students, but I really like it.
Worked with university interns before who are clearly on an industry pit stop en route to a postgraduate program and subsequent career as a corduroy elbowed academic. Thanks for playing, you’re a wonderful little creature, but we aren’t motivated to do the same things with our time. They may play the same game I do, but they’ve chosen a different character arc. They’re journeyman wizards building an arcana and looking for a tower. I’m a dwarf foreman looking to dig out the next Moria.
Love the Northeastern crowd. I’d put them as equivalent to or better than their rodent ringed counterparts from the other side of the Charles river.
by zabzonk on 12/19/24, 11:49 AM
Books, and reading them and doing, are the only way of learning how to be a software developer.
by crvdgc on 12/19/24, 12:31 PM
by t_believ-er873 on 12/19/24, 11:41 AM
by anktor on 12/19/24, 12:55 PM
Would it be correct to understand this as a syllabus, and not the actual explanations/lecture/content?
by red_admiral on 12/19/24, 2:27 PM
That said, it's not quite a red flag but perhaps a yellow one for me when someone trots out the "everyone else is doing it wrong" line with particular emotion-triggering words. Scott Alexander once said this was the approach of "every therapy book, ever" (https://slatestarcodex.com/2019/11/20/book-review-all-therap...)
For example, we start with the curriculum being "unique" (though they do caveat this in a link on the side), sits aloof from what is "currently fashionable", and then (Sec 1.1) paint "the vast majority" of other courses as "traditional" (section title) and "old-fashioned". Dismissing your "traditional", an emotion-laden word for some to say the least, normally activates my B.S. detector because every other startup pitch works like that. Come and invest in our innovative crypto as opposed to traditional, old-fashioned fiat currency!
Sometimes, something has become tradition because people tried it, it went well, they kept on trying it, and it kept on going well. (see also: Chesterton's fence)
I'm sure there are CS courses that could improve by following Northeastern's principles, but I'm also sure there's a lot of other colleges that turn out competent programmers who understand program design and teamwork and systematic reasoning.
Whether to start with a C-style, python style (indentation is structure), or (lisp (style)) language is a matter of taste, but I don't think I'd have got on well with the DrRacket IDE. I like to use my own editor, with my own color scheme and keybindings and regexp search/replace (where I don't need to check each time whether it's \1 or $1 to refer to a capture group), and where I can interact with git and store my code in a repo out of the box (or by opening a terminal window). Anything else feels too much like a walled garden to me.
by bob1029 on 12/19/24, 8:59 AM
It seems to me that a lot of wasted energy is in the form of working on problems that no one cares about. Not that this is necessarily bad (hobby, fun, art, side projects, new ideas, etc), but in a concrete business setting you need to be a bit more aggressive about making sure the customer still gives a shit about what you are working on over time.
I find all of this leads neatly into the 2nd most important thing for me which is making sure you have a good domain model (schema). If the tables, columns and relations that represent the business are high quality and accurate (I.e., your customer understands them), the code that follows will usually go smoothly. Staying on the customer's heels regarding the applicability of your software to the business means you can keep this well aligned over time.
I think much of the tech bloat we see today is a side effect of attempting to outrun the complexity of the customer's specific needs. After sitting on the phone with vendors and customers for a week, you will likely not find yourself playing around with the idea of using some esoteric language or infra to implement things. It's incredible what being directly exposed to the customers can do for a developer's growth.