Preparation + Mindset = Skill

Skill is not innate. It is built through the deliberate interaction of preparation and mindset. Talent might give someone a head start, or determine the very best of the best, but sustained performance is dominated by these two forces.

Mindset

Before performance can be improved, you have to decide what level of performance matters. Mindset isn't about affirmations. It's about drawing a clear, often uncomfortable line in the sand.

  • "I don't ever want to be the reason my team fails."
  • "I want to be trusted with strategic technical decisions."
  • "I want to be world-class at this."

These aren't goals — they're standards. They define what "acceptable" looks like to you. They shape how you show up, what you commit to, and what you're unwilling to tolerate in yourself. If your mindset is vague, your preparation will be misaligned, and your growth will stall.

This step sometimes requires recalibration. You might want to be elite at something like competitive golf, but balk when faced with the lifestyle and sacrifices required. That's valid — but you need to be honest. Desire without alignment is fantasy.

Preparation

Once the standard is clear, preparation becomes a series of deliberate steps aimed at closing the gap between where you are and where your mindset says you should be.

Preparation involves:

  • Knowledge acquisition — understanding the field, its expectations, its culture.
  • Skill-building — practice, repetition, and feedback cycles.
  • Environment shaping — choosing tools, collaborators, or systems that reinforce performance.
  • Reflection and iteration — reviewing your performance, identifying bottlenecks, and adjusting.

The higher your standard, the more intense your preparation must be.

One of the greatest challenges is that you don't know what you don't know. Many people stall because they can't envision what proper preparation looks like at higher levels. To overcome this:

  • Find mentors or role models. Study how top performers prepare. What do they read? How do they practice? What tools do they use?
  • Join communities of practice. Participate in groups where preparation methods are discussed openly.
  • Analyze the performance gap. When you encounter someone operating at a higher level, ask: "What knowledge or skills might they have that I don't?"
  • Seek direct feedback. Ask those with more experience to evaluate not just your performance, but your preparation routine.

Skill

The transformation from preparation and mindset into skill happens through a cycle of action and reinforcement.

A clear standard filters out distractions and prioritizes relevant development. When you know exactly what matters, your learning becomes targeted rather than scattered. The right practice creates visible improvement, which provides evidence that your approach works.

This cycle explains why some people seem to learn faster even with similar amounts of practice — their preparation is guided by a clearer mindset, creating an efficiency that compounds over time.


Contrast Example

To make this concrete, here are two mindsets and how they shape preparation. These aren't value judgments — they're simplified archetypes meant to show how different internal standards lead to different growth paths.

Developer A: Steady Contributor

Codes during work hours with minimal tech engagement outside of them. Solves tickets using familiar patterns and tools. Avoids architectural choices or ambiguous problems. Rarely reads technical articles or documentation beyond immediate needs. Uninterested in feedback unless it blocks deployment. Doesn't reflect much on how things could be done better.

  • Mindset: "As long as I get the job done well, that's enough."
  • Preparation: Day-to-day repetition. Occasional learning when forced by task.
  • Skill outcome: Baseline competence. Dependable for well-scoped work.

Developer B: Technical Polymath

Studies runtimes, architectures, and language design out of curiosity. Builds tooling to solve pain points at work and in side projects. Reads books, papers, and production code to sharpen mental models. Actively seeks feedback, reads code reviews deeply, and experiments with different solutions. Teaches and mentors others to strengthen their own understanding. Reflects often on what could be improved and how.

  • Mindset: "I want to deeply understand and master my craft."
  • Preparation: Strategic, multi-dimensional — study, build, reflect, teach, repeat.
  • Skill outcome: Deep, transferable expertise. High adaptability. Systems-level thinking.

Neither is the wrong choice, assuming the mindset has been consciously defined. Not everyone needs or wants to be elite in their field, and choosing stability over intensity can be a wise, self-aware decision. Problems arise only when the mindset is vague — when aspiration isn't supported by preparation. Clarity about what matters to you is the foundation. The rest is alignment.


Example Preparation Framework

Below is a sample preparation framework for software development. It's not exhaustive — it's meant to illustrate how mindset translates into structured preparation across different levels of competence.

Fundamentals (Baseline Competence)

  • Complete a few beginner-friendly tutorials or courses and finish the projects.
  • Build a few small tools or apps (a to-do list, blog, API wrapper) from scratch without copy-pasting.
  • Practice version control daily: branches, merges, resolving conflicts, reading diffs.
  • Use the debugger instead of console.log for familiarity.
  • Set up a basic local dev environment: editor with extensions, terminal shortcuts, linting, formatting.
  • Learn to Google actively and ask better questions. Bookmark docs and error solutions.
  • Join a beginner-friendly community (Discord, forum, etc.).
  • Deploy at least one project publicly and share it with someone for technical feedback.

Result: Can solve basic problems with some support. Starts forming good habits around tooling and feedback.

Intermediate (Prepared and Useful)

  • Build small-to-medium-scope projects (~1k–5k LOC) end-to-end: backend, frontend, auth, persistence, deploy.
  • Break features into small tasks, estimate time, and track blockers.
  • Start contributing to open source or improving internal tooling at work.
  • Add CI pipelines to projects and configure tests, linters, type-checkers.
  • Build mental models for HTTP, databases, and JavaScript runtimes by reading docs and running test code.
  • Keep a dev scratchpad to document discoveries, weird bugs, or key takeaways from tasks.
  • Read 1–2 foundational books (A Philosophy of Software Design, Clean Code, Designing Web APIs) and apply techniques to personal projects.
  • Ask for code review regularly and revise based on feedback.
  • Practice pair programming or walkthroughs to improve explanation and debugging fluency.

Result: Comfortable in production codebases. Bridges theory and practice. Grows through structure, not just exposure.

Advanced (Architecturally Aware)

  • Conduct focused code reading sessions: pick a mature open-source repo and trace a feature end-to-end.
  • Keep a "why did we do it this way?" journal to capture architectural decisions and tradeoffs on the job.
  • Intentionally rotate between frontend, backend, and devops projects to broaden context and reduce blind spots.
  • Practice system design by sketching architectures for real or imagined problems, evaluating pros and cons.
  • Benchmark tools, frameworks, or protocols (REST vs gRPC, for instance) to understand real-world performance costs.
  • Rewrite project components to explore different patterns (functional core / imperative shell, CQRS, hexagonal).
  • Make performance a habit: profile before optimizing, and test theories with data.
  • Participate in team architecture reviews or RFCs, asking clarifying questions and suggesting simplifications.

Result: Builds robust, understandable systems. Thinks in tradeoffs, not checklists. Trusted with high-leverage design work.

Elite (Top Percentile)

  • Regularly re-read foundational texts (Structure and Interpretation of Computer Programs, Designing Data-Intensive Applications) and apply new insights to real projects.
  • Dive into language and runtime internals: read source code, contribute to issues, trace execution with debuggers and profilers.
  • Build minimal clones of core systems (in-memory DB, message queue, HTTP server) to internalize concepts.
  • Investigate historical systems (Erlang, UNIX, Postgres) to understand design tradeoffs and longevity.
  • Conduct technical deep-dives with peers: discuss architecture, read papers, critique designs collaboratively.
  • Lead postmortems and architecture reviews, identifying not just what failed but how systems can evolve.
  • Build intuition for complexity: run experiments, sketch ideas, test assumptions in isolated proofs of concept.
  • Write long-form reflections or design documents articulating hard-won insights.
  • Participate in or host advanced reading groups or workshops (papers we love, deep internals sessions).

Result: Has internalized principles across the stack. Navigates novelty through first principles. Inspires and elevates others through clarity and rigor.


Creating Your Own Framework

The examples above demonstrate how preparation varies across skill levels. To create your own:

  1. Define your target level. Be honest about where you want to be.
  2. Study practitioners at that level. What do they do daily? What resources do they use? What habits have they formed?
  3. Identify skill components. Break the domain into 3–5 core competencies (technical knowledge, tool proficiency, communication, etc.).
  4. Create concrete actions for each component. What specific, measurable activities build each competency?
  5. Establish a progression ladder. For each component, define clear steps from fundamentals to mastery.
  6. Build feedback loops. How will you know if your preparation is effective? Who can evaluate your progress?
  7. Schedule regular reviews. Assess whether your preparation aligns with your mindset and adjust accordingly.

The most effective frameworks are specific, actionable, and aligned with your personal standards.