Teach Yourself Programming in Ten Years (1998)
Claims that you can “teach yourself programming in 24 hours” are widely rejected in favor of a decade-long path of deliberate practice, varied projects, and accumulating intuition. Commenters contrast deep expertise with more modest goals like getting job-ready via bootcamps, noting that success depends heavily on prior background, motivation, and sustained effort beyond any course. They also reflect on how the field’s tools, methodologies (like Scrum), and now AI assistants shape what and how programmers actually learn, while emphasizing that fundamentals and self-directed curiosity still matter most over the long term.
Time to “Mastery” and the 10-Year Horizon
- Many agree that ~10 years of sustained, varied practice feels about right to become a “solid” developer, though not necessarily a master.
- The 10,000-hour heuristic is seen as oversimplified but directionally useful; people emphasize deliberate, progressively harder practice rather than just elapsed time.
- Several note that some developers plateau at “1 year of experience repeated 10 times” if they don’t keep challenging themselves.
Professional Work vs. Hobby Projects
- Some argue a standard 40h/week software job is enough to accumulate deep skill over years.
- Others say only doing “generic commercial work” (especially at one company or stack) can stagnate learning; side projects and new domains accelerate growth.
- There’s tension between “code all the time because you love it” and “I won’t spend my evenings coding after a full day job.”
Paths Into Programming: CS, Bootcamps, and Self‑Teaching
- Multiple success stories: bootcamps, short intensive courses, self-study in basements, non‑CS degrees pivoting into dev.
- Pattern: success tends to require high motivation, many hours beyond “core” training, and often a rough first job where real learning happens.
- Lack of CS fundamentals can be felt later (e.g., data structures, algorithms), but many fill gaps as they go.
Nature of Software Engineering and Knowledge Decay
- Debate over whether software is closer to science, engineering, or social/legislative systems.
- Some claim fundamentals (algorithms, OS theory, concurrency, etc.) are stable; the chaos is in languages, frameworks, and tooling under economic pressures.
- Others feel much of day‑to‑day effort is wasted wrestling with poor tools, libraries, and “entropy,” analogous to bad physical tools or prefab components.
Scrum, Process, and Team Workflow
- Very strong criticism of Scrum: daily standups as “advertisements,” focus on short‑term optics, fragmentation of deep work, and serving management reporting more than engineering outcomes.
- Some defend a stripped‑down core (e.g., Kanban, simple standups) as useful; blame is often placed on bad culture and over‑ceremony rather than the core ideas.
AI Tools, Learning, and Deliberate Practice
- Some learners say tools like ChatGPT kept them from giving up by unblocking them at the edge of their ability.
- Others worry AI and autocomplete undermine deep understanding, likening it to always using GPS and never learning the route.
- Emerging norm: struggle first, then use AI like a senior developer for hints; use it heavily for boilerplate and tests, but not as a crutch for core problem‑solving.