Building a Career on Capabilities, Not Tools

A general guide to choosing certifications, courses, projects and books so that skill compounds instead of sprawling.

Technology careers invite a shopping habit: another course, another badge, another framework. Each purchase feels like progress, and most of them leave you with a longer list and no deeper skill. This page proposes a different organising idea: choose by capability, the thing you can actually do and show, and let tools be the means.

The recommendations here are a reasoned approach, not findings from a study of careers. The evidence on practice is stronger than the evidence on career strategy, and the page marks which is which. Provisional

Capabilities, and a demonstration for each

A capability is something you can do on an unfamiliar system. A tool is one way to do it today. Tools change every few years; the capability transfers.

Protocol and state reasoning. A demonstration worth keeping: Diagnose a failed request and reply from evidence, naming what each observation does and does not establish.
Identity and security. A demonstration worth keeping: Explain who can reach what, and where coverage is missing.
Reliability. A demonstration worth keeping: Detect an unusable service and restore a verified useful state.
AI-assisted engineering. A demonstration worth keeping: Spec, agent change, reviewed diff, tests, deploy, rollback on your own repository.
Software and data. A demonstration worth keeping: A small reproducible tool with explicit failure behavior.
AI judgment. A demonstration worth keeping: A baseline, an evaluation set, bounded tools and a known cost.
Architecture. A demonstration worth keeping: A comparison of options on requirements, dependencies, burden and recovery.
Communication. A demonstration worth keeping: Someone else can act on your write-up without you narrating it.

The last two connect to Technical Writing as Reasoning, and the AI rows to Working with Coding Agents and Building Bounded Agents. For where these rows sit in the wing, see Engineering Start Here.

Library versus queue

A course library is a shelf you may browse. A queue is what you actually work through. Confusing them is the main way learners sprawl.

One active course per track. If you want to add one, finish or drop another.
Treat the rest as reference: open them for one question, then close them.
Watching videos without touching your own work does not count as practice.

The reason is attention, not discipline for its own sake. Spreading effort across many half-finished courses produces familiarity, which feels like understanding but fails when tested. The case for focused, feedback-rich practice is made in Ericsson, Krampe and Tesch-Romer (1993). Later work (Macnamara et al., 2014) found that deliberate practice explains a smaller share of performance differences than that paper's popular summaries suggest, varying by field, so use it as support for the method rather than as a guarantee. See Deliberate Practice.

Cumulative projects

Choose a few projects that build on each other and give each acceptance checks written in advance, for example "a failed target can never show as healthy" or "re-importing does not double count." Then finish a usable version before adding another framework, database, certification or dashboard. A project that someone else can run from its README is worth more than three that only you can start. The method is the one described in Twelve-Week Arcs and Capstones.

Certification strategy in general terms

Certifications can be useful: employers sometimes filter on them, and a syllabus gives structure. They are also a category where marketing is loud. A cautious approach:

Sequence them. Take one, finish it, and learn from the result before choosing the next.
Choose the next from demonstrated gaps, not from what is popular. A real project or a failed practice case tells you more than a job-board keyword count.
Cap the campaigns. Two substantial certification efforts in any twelve months is a sensible ceiling for a person with a job and a life; this is a judgment, not a rule.
Verify the exam against the official source. Versions, objectives, prices and retirement dates change. Read the vendor's current exam page before you study, and again before you book.
Remember that a readiness gate is not a pass guarantee. Your own mock cases show that you are probably ready; only the exam is the exam.

Certifications from a vendor prove knowledge of that vendor's product and exam objectives. They are strongest alongside a demonstration of the capability beneath them, which is why the table above comes first. Keep the exam syllabus and the product documentation distinct: the syllabus tells you what is tested; the documentation tells you what the product actually does.

Evidence stories

Keep three stories, refreshed every quarter, in the form: situation, what you observed, what you did, how you verified, what remains unknown.

A failure you isolated.
An operation you made dependable.
A thing you built and can defend.

Do not invent metrics. "Reduced incidents by 40%" that you cannot reconstruct is worse than "I could not measure the change, but here is the check that now catches the failure." Honest limits read as competence.

A reference shelf organised by question

Instead of reading a whole curriculum, keep a shelf indexed by the question you actually have.

Networking: how does this connection behave? A reputable reference: Fall and Stevens, TCP/IP Illustrated, Volume 1, 2nd ed.; the Wireshark User Guide.
Operations: how should this be run and recovered? A reputable reference: Limoncelli, Hogan and Chalup, The Practice of System and Network Administration, 3rd ed.; Beyer et al., The Site Reliability Workbook (2018).
Performance: what measurement separates these explanations? A reputable reference: Gregg, Systems Performance, 2nd ed.
Security: what assumption is hidden? A reputable reference: Anderson, Security Engineering, 3rd ed.
Architecture: how do I explain a design choice? A reputable reference: Hohpe, The Software Architect Elevator (2020).
Data systems: what durability or replication problem do I have? A reputable reference: Kleppmann, Designing Data-Intensive Applications, when the project needs that depth.

Read one selected passage per question. Older books can describe historical defaults, so confirm any command or protocol detail against current documentation.

Sustainable pacing

A plan you cannot sustain is a plan you will abandon. Build slack into it.

A reduced week: a shorter version of the routine for busy weeks.
A bad-day minimum: twenty minutes and a note saying where you stopped.
Protected breaks: scheduled rest is part of the plan, not a failure of it.
Cut scope, do not stack: after two disrupted weeks, shrink the goal or move the date rather than piling missed work onto later weeks. Lifters meet the same no-stacking rule in the recovery-based strength cycle: a missed session creates no make-up workout.

This is the same logic as consistent musical practice: short regular sessions with a clear target tend to beat rare long ones, which is a widely held teaching view rather than a settled finding. The broader ideal of keeping study and making together is in Philosopher-Engineer, and the question of what all this skill is for belongs to Reasoning for What Ends.

Try this

Fill in the capabilities table for yourself, writing one real demonstration you could show today. Mark the weakest row and design a small project for it with two acceptance checks.
List every course you have started. Keep one active, and move the others to a reference list with the single question each could answer.
Write your three evidence stories in five sentences each, then cross out any number you cannot reconstruct.