Developing Developers (2015)
A university CS curriculum built around systematic program design, pair programming, and a Lisp-derived teaching language (Racket) is held up as producing graduates with strong mental models for manipulating data and reasoning about code. Commenters contrast this with bootcamps and more traditional “tinker until it works” approaches, arguing that explicit design processes, exposure to multiple paradigms, and structured mentoring make novices more effective and adaptable. Others caution that real-world competence also depends on talking to customers, domain modeling, and broader CS topics, and express concern that administrative pressure to simplify such curricula risks diluting their long-term benefits.
Perceptions of Northeastern’s CS Curriculum
- Multiple commenters with direct exposure to Northeastern’s program report strong outcomes: good interns/co-ops, fast ramp-up, and lasting mental models for problem-solving.
- Emphasis on systematic program design, simple teaching languages (Racket / student languages), and later transition to Java is widely praised for helping true beginners.
- Some note that students with prior programming experience often dislike the early courses, while novices thrive.
- There is concern that current administration is diluting this distinctive curriculum in favor of more conventional / “bootcamp-like” approaches.
Pair Programming, Debugging, and Teaching
- Many see pair programming as valuable in moderation: great for onboarding, hard bugs, and teaching junior developers.
- Several dislike full-time pairing, finding it exhausting, slower overall, or personality-mismatched.
- Variants such as “pair thinking,” “pair debugging,” or one person driving while narrating thought process are described as especially effective for mentoring.
Mental Models, Functional Patterns, and Bootcamps
- A recurring theme is that explicit mental models (e.g., thinking in terms of map/filter/reduce and data transformations) make everyday coding easier and less ad hoc.
- Some tie this to the Racket/HtDP style of teaching; others push back, arguing that PL / FP enthusiasts overstate the importance of such abstractions relative to systems topics (OS, DBs, networks, architecture).
- Bootcamp graduates are sometimes criticized for being tool/framework-driven and weak on core data-structure thinking, though others see this as more about missing conceptual grounding than innate ability.
Customer Focus and Methodologies
- Several argue that “developing developers” must include close, recurring contact with users/customers to avoid building unused features and misaligned systems.
- Strong domain models and schemas are seen as crucial outcomes of this contact.
- Debate arises around Waterfall vs. Agile/Scrum:
- Some praise Waterfall-style upfront requirements.
- Others note that real Waterfall is often misunderstood, and most successful processes introduce feedback loops.
- Scrum, especially “Scrum-as-practiced,” is heavily criticized as ceremony without substance.
Tools, Languages, and Learning Paths
- Books are defended as a primary way to deeply learn programming; others find them less effective than hands-on work.
- Several schools reported using Racket, Scheme, or other functional/Lisp-like languages to level the playing field and emphasize concepts over syntax, sometimes against administrative resistance.
- Tangents on early BASIC and critical historical quotes highlight how poor early languages may have shaped bad habits, though some see those critiques as hyperbolic.
AI Assistants as “Pair Programmers”
- Experiences with LLM-based pair programming are mixed to negative in this thread.
- Autocomplete-style tools are widely seen as useful; full conversational coding and debugging with LLMs often lead to frustration, incorrect code, and extra overhead to supervise and correct the model.