06 — Failure Modes

Seven ways this plan quietly dies. All of them are common. All of them are survivable if you catch them early.

This file is not about the loud failures — the family emergencies, the health crises, the work explosions. Those are covered in 08_health_burnout.md and 99_pre_mortem/08_fm_life_and_health.md. This file is about the quiet failures, the ones where you keep showing up and doing something that looks like the plan but is actually not the plan. These are more dangerous because you cannot see them from inside.

Read this file at the start of every month. Fifteen minutes. It is the diagnostic. If any of the early-warning signs match your last four weeks, take the mitigation seriously.

F1: Tutorial Hell

What it looks like. You have 14 Baeldung tabs open. Three Marco Behler courses playing at 1.5x. A subscription to an educational YouTube channel you watch during dinner. Your git log for the week: zero commits. Your notes folder: full. Your src/ folder: empty.

Why it happens. Reading and watching feel productive. Both trigger the same “I am learning” dopamine. Neither one puts syntax in your fingers or forces you to make a decision. Passive input is easy; active output is hard, and your tired-after-work brain will always prefer easy.

Early warning signs.

  • Weekly hours on video/reading > weekly hours coding

  • More than 5 open browser tabs of Baeldung/Medium/dev.to articles

  • You can describe a concept fluently but cannot type its code without looking

  • Sprint retro lists “read chapter X” and “watched course Y” but no shipped code

Mitigation.

  • The 2:1 rule. For every hour of video/reading, two hours of coding. Track it.

  • Every video watched requires a 3-sentence written note: “The main claim is X. I will apply this by doing Y. I predict Z will happen.”

  • Close all tabs at end of session. Bookmark instead. Tabs are debt.

  • If a week has more consumption than production, next week is code-only, no new videos or articles.

F2: Framework-First

What it looks like. It is month three. You are watching a Spring Boot tutorial. You have not finished the concurrency file. You have not written a JMH benchmark. But Spring Boot feels like “real Java work,” and the tutorials are polished and satisfying.

Why it happens. Frameworks are visible. You build a REST endpoint, hit it with curl, and get a response. That feels like production. Meanwhile the Phase 05 concurrency work is invisible — you write a producer-consumer, it runs correctly, and there is nothing to show anyone. Frameworks give faster external validation.

Why it is a trap. Spring Boot hides the JVM. It hides threading. It hides classloading. It hides GC pressure. If you build on top of Spring without understanding the layer below, you cannot debug production. In an study, “I used @Async” is not an answer to “how does thread pool exhaustion cause your 99th percentile latency to spike?” — and that is the study you want to be ready for.

Early warning signs.

  • Spring Boot tutorials in browser history before Month 8

  • “I’ll just skim the concurrency phase” thought

  • Starting a Spring project during a phase that isn’t Phase 07

  • Excitement about @Autowired while not being able to explain what a ClassLoader does

Mitigation.

  • No Spring content in the browser until Month 8. Hard rule. This includes tutorials, courses, docs. You are allowed to know Spring exists. That is all.

  • The order is: JVM internals before Spring internals. If you cannot explain object headers, generational GC, and safepoints, you are not ready for Spring.

  • If you must scratch the itch: build a tiny Spring “hello world” once, in one afternoon, and then close it. Do not extend it. Return to the current phase.

F3: DSA Black Hole

What it looks like. You are on LeetCode problem 187. You started Phase 02 four months ago. You still have not started Phase 03. But you just got a medium hard graph problem in one shot, and it feels good, so you’re going to do one more.

Why it happens. LeetCode is a slot machine. Green tick + rank + streak + a leaderboard. It is designed to hijack your reward system, and it works. Also: DSA feels safer than design. “I solved 200 problems” is a legible metric. “I refactored a monolith toward SOLID principles” is not, until much later.

Why it is a trap. study loops for Java-heavy senior roles at Indian product companies (Zoho, Freshworks, Postman, Razorpay, Chargebee, Flipkart) weight DSA less than system design and Java-specific fluency. 150 problems is enough. 400 is a diminishing-returns misallocation.

Early warning signs.

  • LeetCode streak > 60 days AND Phase 03 not started

  • Rationalizing: “one more hard problem and then I’ll switch”

  • Solving mediums fluently but unable to design a class hierarchy for a real problem

  • Feeling anxious about starting the OOP refactor project (“I’m not ready”)

Mitigation.

  • Hard cap: 150 LeetCode problems total for the entire 13 months. Track it. When you hit 150, stop.

  • Phase-out ritual: on the day you finish problem 150, write a retrospective, close the LeetCode tab, delete the bookmark, move to Phase 03. Ceremonially.

  • “No LeetCode Sundays” after M4. Even inside the 150-cap. Sunday is your sabbath (see 08_health_burnout.md); if you code, it is portfolio work, not competitive puzzles.

  • If the pull is strong, ask why. Usually the answer is: fear of the harder, less-legible work coming next.

F4: AI-Crutch Relapse

What it looks like. It is week 3 of Phase 01. You are supposed to be hand-coding programs 1-20 with no AI. But you were tired last Tuesday, and you asked Claude “how do I write a palindrome check in Java again?” and it worked, and now you are asking Claude every third program.

Why it happens. This is the single highest-probability failure mode for you specifically. You have been using AI for all your coding for two years. The neural pathways for “figure it out yourself” have atrophied. When friction appears, your hand reaches for Cursor by muscle memory, not by decision.

Why it is catastrophic. The entire point of Phases 01 and 02 is to rebuild the muscle memory that AI has replaced. If you use AI during these phases, you finish month 6 with a beautiful GitHub full of code you cannot write. You have a portfolio; you do not have the skill. In an study, when someone asks “can you write a ThreadPoolExecutor on the whiteboard,” the illusion collapses.

This is the failure mode with the highest probability and the highest cost. It is treated in more detail in 99_pre_mortem/01_fm_ai_crutch_relapse.md.

Early warning signs.

  • You have Cursor/Copilot enabled during a Phase 01 or Phase 02 session

  • You typed a prompt into Claude/ChatGPT with a Java syntax question

  • You cannot recall from memory the syntax you used in yesterday’s program

  • Your commit messages are AI-generated (a sign the whole flow is AI-mediated)

  • You feel a small resistance / avoidance when starting a hand-coding session

Mitigation.

  • Physical paper notebook for Phase 01. Yes, actual pen. Write the first draft of each program on paper. Then type it. Sounds ridiculous. Works.

  • AI-off blocks on the calendar. 9:30-10:30 PM daily, no AI. Turn off Copilot in IntelliJ (uninstall it if that’s what it takes).

  • Separate dev profile. Create a macOS user account or an IntelliJ profile with no AI plugins for M1-M3.

  • The M2 checkpoint. By the end of M2 you should have ≥ 30 hand-written programs committed. If you don’t, stop everything and reset (see reset protocol).

F5: Shiny Object Syndrome

What it looks like. JEP 480 drops. You spend two evenings reading it. GraalVM has a new native-image demo. You watch it and spend a weekend trying it. Someone tweets about Rust for backend and you buy a book. Meanwhile the current sprint has 4 days left and 2 of 3 goals are untouched.

Why it happens. Java is a rich ecosystem. New JEPs land every six months. There is always something interesting adjacent to what you should be doing. And “learning the newest thing” feels like being on the frontier, whereas “finishing Phase 04’s stream project” feels like homework.

Why it is a trap. Every hour spent on a shiny object is an hour not spent on the sprint goal. Over 13 months, an hour a week on shiny objects is 56 hours — more than a full sprint. That is a phase you will not finish.

Early warning signs.

  • More than 30 open browser tabs

  • Unfinished branches in git repos with names like try-graalvm or experiment-loom

  • README updates without corresponding code updates

  • Sprint retros where you did “interesting things” but not the planned things

  • More time on Twitter/HN than on the sprint

Mitigation.

  • One topic per sprint. The sprint file names the topic. Anything else is a shiny object.

  • The LATER.md file. Interesting-but-not-now goes here, with a one-line note. Revisit quarterly during buffer weeks. Most items will look less shiny in three months.

  • Tab count under 15. If tab count > 15, close everything not related to the current sprint goal.

  • HN and JEP reading is a Saturday morning activity, capped at 1 hour. Not a Wednesday night activity.

F6: Community Avoidance

What it looks like. You have not asked a question in r/java. Not commented on a Nicolai Parlog tweet. Not joined the Java Discord. Not opened a PR on any project. Not messaged the senior Java engineer at Zoho you keep meaning to reach out to. Your work is a private cathedral. No one knows you are building it.

Why it happens. Introversion. Impostor syndrome. “I’ll join the community when I’m good enough.” The idea that you have to earn the right to participate. Cultural pattern of not raising hand in class.

Why it is a trap. Learning in isolation is slow. Every question you don’t ask is a bug you don’t get help with. Every PR you don’t open is a code review you don’t receive. Every LinkedIn post you don’t publish is a recruiter who doesn’t find you. When August 2027 comes and you want an opportunity, there is no network to draw on.

Early warning signs.

  • Zero public commits in a calendar week

  • Zero comments/replies on any Java forum in a month

  • Not knowing the name of a single active person in the Java community

  • Feeling anxious about “looking dumb” if you ask a question

  • The senior engineer you keep meaning to email — still not emailed

Mitigation.

  • Sprint 1 non-negotiable: join r/java, join at least one Java Discord (JavaBrains community, Baeldung’s, or search Discord for Java), follow 20 Java accounts on Twitter/X.

  • 1 public post per sprint minimum (see 05_teach_to_learn.md). LinkedIn counts.

  • 1 PR to an open-source Java project by M6. Not a big one. A typo fix, a docs improvement, a small bug. The point is doing the workflow once.

  • 1 message per sprint to another engineer. Internal Zoho or external. Ask a question. Share a note. Comment on their post. Reach out to the senior architect you keep meaning to talk to.

  • Reframe: the community expects beginners to ask beginner questions. You are not violating any rule by participating.

F7: Sprint Bloat

What it looks like. Sprint S4 started with 3 goals. On day 5 you added a fourth because it “felt related.” On day 9 you added a fifth. On day 14 you finished 2 of the original 3 and none of the added ones, and the retro is a mess of half-done things.

Why it happens. Ambition. Underestimating tasks. The illusion that adding scope shows commitment. Wanting to catch up after a slow start to the sprint.

Why it is a trap. Overpacked sprints erode the cadence. When you finish a sprint at 50% completion, you learn that sprint plans are aspirational rather than binding, which corrupts the whole system. Underpacked sprints that ship 100% are healthier than overpacked sprints that ship 50%.

Early warning signs.

  • Sprint file edited mid-sprint to add goals (git blame will catch you)

  • More than 3 goals in a sprint

  • Sprint retros with 4+ carry-over items

  • Feeling that each sprint plan is “not enough” when you write it

Mitigation.

  • Sprint scope is set on day 1. Locked on day 2. Reduced only, never expanded, after day 2.

  • Max 3 goals. If you write a fourth, one of the first three has to move to next sprint or LATER.md.

  • If a sprint feels light on day 1, do not add scope. Add a stretch bullet marked [STRETCH], only touched if all 3 main goals are done.

  • Sprint retros must call out any mid-sprint additions and mark them for elimination.

The Monthly Diagnostic

Once a month (first day of each calendar month works), read this file top to bottom and score yourself honestly on each:

Monthly Diagnostic — {month}

F1 Tutorial Hell:            [1-5]  Notes:
F2 Framework-First:          [1-5]  Notes:
F3 DSA Black Hole:           [1-5]  Notes:
F4 AI-Crutch Relapse:        [1-5]  Notes:
F5 Shiny Object Syndrome:    [1-5]  Notes:
F6 Community Avoidance:      [1-5]  Notes:
F7 Sprint Bloat:             [1-5]  Notes:

1 = no signs, 5 = actively happening.

Highest score this month: F__ — mitigation for next month:

If any score is 4 or 5, that failure mode is your top priority for the next month. Apply the mitigation before anything else.

Next: 07_motivation_sustainment.md Previous: 05_teach_to_learn.md