Senior Weakness Diagnosis
Why this chapter matters
Many engineers reach senior level with strong implementation ability and hidden architecture gaps. Those gaps are not character flaws. They are usually the result of incentives: shipping features, fixing tickets, learning frameworks, and optimizing for local correctness.
Architect-level work exposes those gaps. A decision that works for one component may fail across teams. A performance fix that works locally may not survive real users. A clever abstraction may become a migration tax. This chapter helps you diagnose the weaknesses before they become expensive.
Core mental model
Senior engineers are often judged by whether they can solve hard problems. Architects are judged by whether they can make hard problems easier for other people to solve safely.
The transition requires moving from:
| Senior habit | Architect habit |
|---|---|
| Solve the assigned problem | Reframe the problem and expose hidden constraints |
| Optimize local code | Optimize system behavior and change cost |
| Know the framework | Know the browser, product, team, and runtime boundary |
| Review implementation | Review decisions, risks, and verification evidence |
| Fix incidents | Turn incidents into guardrails |
Diagnostic map
| Weakness | What it sounds like | Production symptom | Remediation |
|---|---|---|---|
| Framework-first thinking | "Next/React/Vite solves this." | Decisions fail when product constraints shift. | Start from route, data, latency, ownership, and failure requirements. |
| Local performance thinking | "The component is optimized." | p75 field metrics remain poor. | Profile route-level critical path and main-thread work. |
| Shallow accessibility | "We added ARIA." | Keyboard, focus, or screen-reader workflows break. | Write component contracts: semantics, focus, keyboard, names, states. |
| Security by assumption | "The backend checks it." | Browser leaks data or exposes unsafe sinks. | Map browser trust boundaries and attacker-controlled inputs. |
| Weak ownership model | "Shared owns it." | No one fixes cross-cutting quality regressions. | Name owner, approval path, exception expiry, and metric. |
| Tool-led architecture | "We should adopt X." | New platform complexity without measurable outcome. | Require decision context, alternatives, reversibility, and verification. |
| State confusion | "Just put it in global state." | URL, cache, server, local, and component state drift apart. | Classify state by ownership, lifetime, shareability, and sensitivity. |
| Thin failure modeling | "We handle errors." | Users get generic failures, stuck pending states, or duplicate actions. | Build failure matrices for API, network, permission, stale data, and partial outage paths. |
| Verification mismatch | "We have tests." | Tests pass while production journeys regress. | Place tests against the highest-risk behavior and add production signals. |
| Weak product translation | "This is technical debt." | Stakeholders cannot prioritize the work. | Translate debt into user harm, business risk, support cost, or delivery drag. |
Self-audit
Answer these honestly:
- Can you explain why a route should be static, server-rendered, streamed, or client-heavy without naming a framework first?
- Can you debug a slow interaction using a browser trace and a React profile?
- Can you describe where user input can become unsafe browser behavior?
- Can you write an ADR that a product manager and backend engineer both understand?
- Can you name the team that owns each shared component, utility, route, and quality gate?
- Can you explain what should happen when the network, API, model, experiment, or third-party script fails?
- Can you classify route state into URL, server, client cache, local durable, derived, and transient UI state?
- Can you write failure states before implementation starts?
- Can you name the rollback signal for a risky release?
- Can you turn one repeated review comment into a documented standard, lint rule, template, or shared helper?
Skill maturity scorecard
Use this scorecard to decide where to spend practice time.
| Skill | Developing | Strong senior | Architect-ready |
|---|---|---|---|
| Product framing | Implements requested UI | Clarifies user outcome and edge cases | Connects technical choices to business risk and product strategy |
| Runtime reasoning | Knows framework lifecycle | Reads browser traces and network behavior | Designs route/runtime strategy across devices and delivery layers |
| Data/state modeling | Chooses a state library | Separates URL, server, cache, local, and UI state | Defines data ownership, freshness, mutation, and conflict policy |
| Accessibility | Fixes reported issues | Designs keyboard/focus/semantic contracts | Scales accessibility through components, review, and governance |
| Security/privacy | Avoids obvious unsafe code | Maps trust boundaries and sensitive data | Creates browser security/privacy guardrails and exception process |
| Performance | Optimizes components | Profiles route and interaction bottlenecks | Sets budgets, CI gates, and field metric feedback loops |
| Verification | Adds tests | Tests risk at the right layer | Designs verification systems and production quality signals |
| Communication | Explains implementation | Explains tradeoffs and alternatives | Produces decisions other teams can reuse without needing you |
Remediation loops
Weakness improves fastest when practice has output. Use two-week loops:
| Loop | Output |
|---|---|
| Runtime loop | One performance trace, one bottleneck explanation, one fix or rejected fix |
| State loop | State ownership map for one route |
| Accessibility loop | Component contract with keyboard, focus, semantics, and screen-reader notes |
| Security loop | Threat boundary sketch for one feature |
| Verification loop | Test plan that maps each test to a named risk |
| Communication loop | ADR reviewed by one frontend, one backend, and one product partner |
Remediation plan
| If this is weak | Study | Practice |
|---|---|---|
| Rendering/data reasoning | Part II and Part III | Build a route rendering matrix. |
| Performance diagnosis | Part VI | Capture one trace and one field metric baseline. |
| Security/reliability | Part VIII | Write a threat model and degraded-state matrix. |
| Design-system judgment | Part VII | Write a component accessibility contract. |
| Decision communication | Part I and Part XII | Write two ADRs with alternatives. |
| Leadership/governance | Part IX | Run a simulated review packet. |
Exercise
Pick a feature you recently shipped. Rewrite its design note as an architecture decision:
- user outcome
- constraints
- alternatives
- chosen design
- tradeoffs
- failure modes
- verification
- rollback
If that feels difficult, the weakness is not writing. The weakness is usually that the original decision was never made explicit.
Portfolio exercise
Create a "before and after" weakness artifact:
- before: a real or realistic feature design written the way you would have written it as a mid-level engineer
- diagnosis: the hidden assumptions, missing failure modes, missing owners, and missing verification
- after: the same feature rewritten as an architecture-ready note
- evidence: one metric, test, trace, or review artifact that would prove the better version works