Developing Developers (2015)

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.