Building a Career on Capabilities, Not Tools

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.

The last two connect to Technical Writing as Reasoning, and the AI rows to Working with AI Coding Agents: A Disciplined Loop and From Assistant to Agent: Tools, MCP and Evaluation. For where these rows sit in the wing, see Engineering and Career: 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: Choose Targets You Can Observe.

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 the Capstone Project Method.

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:

1. Sequence them. Take one, finish it, and learn from the result before choosing the next.
2. 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.
3. 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.
4. 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.
5. 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.

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.

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 The Philosopher-Engineer: Study and Workshop Together, and the question of what all this skill is for belongs to Reasoning for What Ends? Wisdom, Character and the Examined Life.

Try this

1. 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.
2. List every course you have started. Keep one active, and move the others to a reference list with the single question each could answer.
3. Write your three evidence stories in five sentences each, then cross out any number you cannot reconstruct.

Further reading

• Ericsson, Krampe and Tesch-Romer (1993), and Macnamara et al. (2014), for the research on practice and its limits.
• Newport, So Good They Can't Ignore You (2012): an argument for skill over passion, written for a general reader.
• The vendor's official exam page for any certification you consider, read at the time of decision.
• Beyer et al., Site Reliability Engineering (2016): operations as an engineering discipline.