Engineering on David Parry

🔧 My Career Is Not Writing Software

Sat, 01 Aug 2026 14:00:00 -0500

My friend Bruno recently wrote about the difference between a job, a hobby, and a career.

His explanation was simple and insightful.

A hobby is something you do because you enjoy it. A job is something you do because someone pays you. A career combines the two. You are paid for the work, but you would continue doing some version of it even if no one were paying you.

I recommend following Bruno’s perspective. His writing often takes a familiar idea and causes me to think about it differently.

In this case, he used software development as an example.

A person who has made software development a career will probably continue creating software outside a specific job. They may build an application for themselves, contribute to an open source project, help a friend, or use software to support another hobby.

That description certainly applies to me.

But as I thought more about it, I realized something.

My career is not writing software.

Writing software is one of the things I do. It is a skill I have practiced for decades, and it is still something I enjoy.

But my career is broader than writing code.

My career is solving problems, creating useful things, restoring failing systems, and helping ideas become something people can depend on.

Software is my medium.

Writing Code Is Not the Whole Work

I have discussed this idea with managers throughout my career.

I do not see software development as only an engineering exercise. I also see it as a form of creation.

You begin with an idea, a problem, or an unmet need. You then create something that did not exist before.

Code is part of that work, but code is not the complete work.

The complete work includes understanding the problem, identifying the constraints, selecting the right approach, making tradeoffs, designing the system, testing the result, securing it, operating it, and ensuring that someone else can maintain it.

Writing code may be the most visible activity, but it is only one stage of creation.

A person can write a great deal of code without solving the right problem. They can also create something quickly that leaves the company with years of technical debt, operational complexity, or security risk.

That is why I do not define my career by the act of writing software.

The value is not in how much code I produce. The value is in what the software makes possible.

Software Is the Medium

Artists choose a medium based on what they want to create.

A painter may choose oil, watercolor, charcoal, or acrylic. A sculptor may choose stone, wood, clay, or metal. Each medium has strengths, limitations, costs, and risks.

Software is no different.

When I create a system, especially one intended for enterprise use, I must choose the language, architecture, frameworks, infrastructure, and tools that fit the actual problem.

Those decisions cannot be based only on what is fastest or easiest for me.

A technology may let me produce a prototype in a few hours. That does not mean it is the correct medium for software that must operate in production for the next ten years.

The company may have to hire people with specialized skills, introduce new build systems, approve unfamiliar infrastructure, monitor another dependency ecosystem, establish new security controls, and support another runtime long after the original developer has left.

A choice that saves me several days can cost the company years of additional effort. That is technical debt — and it can begin before the first line is written, when someone selects the wrong medium.

A Prototype Is Not a Production System

A scripting language or experimental tool may be an excellent choice for proving an idea — data exploration, a short-lived automation, an internal experiment, or a prototype.

But a prototype answers only one question: can this idea work?

A production system must answer much more. It must be secured, tested, observed, maintained, and supported by the organization. It must scale, survive upgrades, remain understandable to the engineers who inherit it, and operate within the company’s architecture, compliance requirements, and security controls.

The technology that creates the fastest prototype may be one of the worst choices for the final system. The problem is not the language or tool itself. The problem is using a medium outside the context in which it is appropriate.

My Convenience Cannot Become the Customer’s Risk

Security makes the choice of medium even more important.

A tool may make development easier while introducing vulnerable dependencies, insecure defaults, weak authentication patterns, poor secrets management, or an ecosystem the organization is not prepared to govern.

The most serious failure occurs when my technical choice forces the customer to weaken its own security posture.

The customer may have to open unnecessary network paths, permit additional data movement, expose new services, install poorly governed components, or approve dependencies that do not meet its security standards.

At that point, I have not solved the customer’s problem. I have transferred the consequences of my decision to the customer.

Choosing a technology because it was the fastest option for me is not responsible engineering.

My convenience cannot become the company’s technical debt, my enthusiasm for a new tool cannot become the operations team’s burden, and my prototype cannot become the customer’s security vulnerability.

The right medium should help the organization operate securely and sustainably. It should not require the organization to work around the weaknesses of my decision.

The Art Is in the Selection

This is where I see software as both engineering and art.

The art is not simply writing elegant code. It is understanding the problem well enough to choose the right medium.

It requires knowing when a proven framework is better than a custom solution and when a new technology has earned a place in production. It also requires recognizing when the fastest approach will create long-term costs, what should be built, what should be reused, and what should not exist at all.

The newest tool is not always the right tool, and the most fashionable language is not always the right language. The technology that allows one developer to move fastest is not always the technology that allows the enterprise to move safely.

A professional system must be more than impressive during a demonstration. It must be secure, maintainable, testable, observable, supportable, and sustainable. That is part of the creation.

Creating for Other People

Most software is created for someone else to use.

The user may never know what language was selected, which framework was used, or how difficult the architecture was to design. They experience the result through whether it works, whether they can trust it, whether it helps them, and whether it continues working as their needs change.

Those outcomes matter more than the amount of code written.

A painting may remain on the artist’s wall. Professional software cannot remain only with its creator. It must leave the creator’s hands and survive contact with users, operations teams, security teams, changing requirements, new engineers, and time.

The real test of the work is not whether I can understand it. The real test is whether others can use it, operate it, maintain it, and trust it.

Software as a Hobby

Not everything I have created was built for an employer or customer.

Years ago, I created my own personal password safe.

It was never intended to become a commercial product. I built it because I wanted to solve a problem for myself, experiment with an idea, and understand the complete system.

I would not claim that a personal project received the same testing, review, or security scrutiny as a mature commercial password manager.

Its value was different.

I designed it, understood how it worked, and controlled how it was used. Most importantly, I enjoyed creating it.

That was software as a hobby.

I have also created software without being paid that other people were able to use.

One example was a magnifying glass application. Over the years, at one point over a million people used it. I have also created reading tools, utilities, and other applications that solved practical problems.

No employer assigned those projects to me.

I created them because I saw a need and believed I could create something useful.

That supports Bruno’s point. A job may end when the company stops paying you, but a career continues because the desire to practice the craft remains.

Fixing Software Is Also Creation

A large part of my career has not involved starting with a blank screen.

It has involved entering failing projects, understanding what went wrong, and finding a path forward.

That work requires a different form of creativity.

You must understand the original intent, determine which parts still have value, and identify the decisions that created the current problems. You must then repair the system without causing more damage.

Sometimes that means correcting the code or changing the architecture. Other times, it means introducing better tests, replacing custom infrastructure with a proven framework, reducing complexity, or helping a team change how it works.

Fixing software is not merely maintenance.

It is restoration.

A person restoring a painting does not simply cover the damage with new paint. They study the original work, understand its materials, preserve what remains, and carefully repair what has been lost.

Software restoration requires the same respect for context.

You cannot fix a system until you understand it.

Once again, writing code is only one part of the work.

A Career Larger Than Any Job

Bruno’s distinction matters because jobs are temporary.

A company may hire you to apply your skills to a particular product, project, or business problem.

That job belongs to the company.

The career belongs to you.

A job can end because the project changes, the company changes, or the company stops paying you.

Your career continues.

The skills you developed, the judgment you gained, the systems you created, the failures you repaired, and the lessons you learned move with you.

That is why I think about a career over decades, not individual positions.

Each job becomes one place where I practice the larger craft.

My Career Is Creating

I enjoy writing software, but writing software is not my career.

My career is understanding difficult problems, selecting the right medium, creating useful systems, and repairing systems that have failed — balancing speed with sustainability, and protecting the company and the customer from unnecessary technical debt, operational burden, and security risk.

It is turning ideas into something people can use and trust.

Code is one of my tools. Software is my preferred medium.

But my career is creating.

💰 Skills vs MCP: What the Token Bill Actually Measures

Mon, 20 Jul 2026 09:00:00 -0500

Move deterministic business rules out of the model and into code. For the one workload I benchmarked, that single decision cut hosted-model cost by 32% on Claude Opus 4.8 and 76% on GPT-5, ran two to five times faster, and eliminated a silent age-calculation error because an authoritative clock replaced the model’s guess. That is the conclusion. Everything below is how I measured it, why the popular “Skills versus MCP” framing is the wrong dividing line, and where the result stops being defensible.

The question that sent me down this path came after a conference talk I gave about building MCP servers. Another engineer asked me something blunt: Why are you still talking about MCP when Skills can do all of this?

My first reaction was equally blunt. If I worked for a model provider, I might prefer the design that keeps more work inside the model. I work for the organization paying the bill, so I want deterministic business rules to run in ordinary code whenever that is practical.

That is my opinion, not evidence of a vendor conspiracy. Providers have good reasons to make models more capable, and customers are free to choose the architecture. Still, the incentive is worth noticing: when a model does more work, customers usually buy more inference. The two hosted models in this benchmark also price output tokens at five to eight times their input-token rate.

So I built a small benchmark to see how much that choice mattered. The result supported my architectural instinct, but it also exposed a problem with the original framing of this article. “Skills versus MCP” is not the real dividing line. The real one is model-executed rules versus code-executed rules.

What I actually compared

A Skill is a package, not an execution environment. The open Agent Skills specification allows a Skill to contain instructions, reference material, assets, and executable scripts. OpenAI’s description of Skills likewise says a Skill can include code.

MCP is a protocol through which a model-facing client can discover and call tools. An MCP server can contain business logic, but it can just as easily wrap a database, an API, a clock, or a bad nondeterministic service. The protocol itself does not make the result correct.

The benchmark therefore compared these specific implementations:

Instruction-only Skill: the Skill contains the rules and catalog in Markdown. The model performs the calculations.
MCP-backed tool: a Rust server performs the calculations and returns structured data. The model calls it and formats the response.
Prompt-only baseline: the same rules are placed directly in the system prompt and the model performs the calculations.

That is a narrower and more useful comparison: model-executed rules versus code-executed rules.

An executable Skill would make a legitimate fourth configuration, but “the Skill contains code” is not enough information. There are two very different ways an agent can use that code. It can run the script in a real software runtime, or it can read the source and attempt to follow the logic itself. The second option is still model-executed business logic. In fact, it may be worse than giving the model concise rules: the source consumes more context, while the model remains free to miss a branch, mishandle a boundary, or improvise around the implementation.

Running the script is different. Once ordinary software receives the same validated inputs, it can produce the same authoritative output as the Rust server. The remaining uncertainty sits in the orchestration around it. Will the model load the Skill, notice the script, invoke it instead of doing the calculation itself, construct the command and arguments correctly, and present the returned value without “correcting” it? If script execution is merely suggested in prose, the architecture still depends on the model choosing the deterministic path on every request.

If the agent runtime exposes the bundled script as a required, typed capability and reliably routes the request through it, I would expect the token and latency profile to resemble the MCP-backed path. At that point, however, the important win comes from executable code being treated as authoritative, not from the Skill label. If the model is expected to read and mentally execute the bundled source, I would expect more tokens without gaining the guarantee that made the code worth writing.

I have not tested either version of that fourth configuration yet. A useful follow-up would measure them separately: Skill plus enforced script execution and Skill plus source code for the model to interpret. Combining those into one “executable Skill” result would hide the architectural difference, but both versions still hit the core economic question: how much material must the model read, reason about, and generate before the code runs? Loading Skill instructions or source, deciding to invoke a script, constructing the command and arguments, and then consuming the result all use tokens. Executable code makes the calculation authoritative; it does not make the orchestration free. My expectation is that asking the model to interpret source will be the most expensive version, while enforced script execution should be closer to MCP. Whether it is cheaper or more expensive than a compact, typed MCP tool call is something the fourth benchmark must measure rather than assume.

The workload

The customer record contains a birth date, ZIP code, ordered interests, and a maximum budget. The system must calculate age, classify the customer, filter a small activity catalog, apply discounts, rank eligible activities, and return the best matches.

The harness ran all three configurations 15 times on each of three models:

Claude Opus 4.8
GPT-5
qwen3:30b, served locally through Ollama

That produced 135 responses. The harness recorded provider-reported input, output, and total tokens; model and tool calls; end-to-end latency; estimated API cost; and the final text. The Rust server, Skill, prompts, harness, tests, and raw JSON are in the public benchmark repository .

There is one important wrinkle. The customer request did not include the current date. The MCP server read the host’s clock, while the instruction-only configurations had no equivalent clock tool. An earlier draft of this article said the date was part of the scenario. It was not.

That means the cost and latency comparison uses the same user request, but the later age comparison is not a controlled test of code versus model arithmetic. It also tests access to current state. I discuss those results separately rather than pretending the difference does not exist.

Results

Every number below is the mean of 15 successful runs. Prices are standard, non-cached API prices at the time of the test. GPT-5 was $1.25 per million input tokens and $10 per million output tokens . Claude Opus 4.8 was $5 and $25 , respectively.

The “text variation” column is the mean pairwise character-sequence difference among the 15 final answers, calculated with Python’s SequenceMatcher. It measures how different the rendered responses were. It does not measure semantic correctness, business-rule determinism, or auditability.

Claude Opus 4.8

Config	Input tokens	Output tokens	Total tokens	Model calls	Input $	Output $	Total $	Latency (s)	Text variation
Instruction-only Skill	1,210	1,193	2,403	1	$0.00605	$0.02983	$0.03588	12.5	48.5%
MCP-backed tool	2,071	561	2,632	2	$0.01036	$0.01403	$0.02438	9.0	38.8%
Prompt only	1,131	1,231	2,362	1	$0.00566	$0.03078	$0.03643	12.9	61.9%

GPT-5

Config	Input tokens	Output tokens	Total tokens	Model calls	Input $	Output $	Total $	Latency (s)	Text variation
Instruction-only Skill	802	2,089	2,891	1	$0.00100	$0.02089	$0.02189	16.1	76.8%
MCP-backed tool	963	408	1,371	2	$0.00120	$0.00408	$0.00529	4.8	38.7%
Prompt only	783	2,320	3,103	1	$0.00098	$0.02320	$0.02418	20.8	67.8%

qwen3:30b (local via Ollama on an Apple M4 Max with 128 GB RAM)

Config	Input tokens	Output tokens	Total tokens	Model calls	Input $	Output $	Total $	Latency (s)	Text variation
Instruction-only Skill	898	4,192	5,090	1	$0.00	$0.00	$0.00	43.4	76.7%
MCP-backed tool	1,480	1,086	2,565	2	$0.00	$0.00	$0.00	10.8	58.9%
Prompt only	882	5,112	5,994	1	$0.00	$0.00	$0.00	54.4	73.2%

Cost per 1,000 requests

Model	MCP-backed tool	Instruction-only Skill	Prompt only	Tool vs Skill	Tool vs Prompt
Claude Opus 4.8	$24.38	$35.88	$36.43	32% less	33% less
GPT-5	$5.29	$21.89	$24.18	76% less	78% less

What those numbers support

The tool-backed path sent more input because the request included a tool schema and required a second model call. It still cost less because it used far fewer completion tokens. On these models, for this task, the price difference between input and output was large enough to overwhelm the extra round trip.

The same implementation was also faster in this sweep. It reduced mean latency from 12.5 to 9.0 seconds against the instruction-only Skill on Opus, from 16.1 to 4.8 seconds on GPT-5, and from 43.4 to 10.8 seconds on the local model. The local comparison matters because there is no per-token invoice to blame. Generating fewer tokens still consumed less wall-clock time on my hardware.

The provider APIs reported completion-token usage; those counts are what I priced. Depending on the provider and model, that usage can include billed reasoning tokens that never appear in the visible answer. It would be inaccurate to say every calculation was literally printed to the user.

The text-variation result is interesting but weaker. Tool-backed answers were more alike in all three sets, which makes sense because the model received the same structured result each time. A character-level similarity score is sensitive to headings, wording, and answer length, though. I would not use it as evidence that the business logic is deterministic. For that, I would test the function outputs directly.

Most important, this is one synthetic workload with one customer and one catalog. It shows that moving this set of rules into code reduced tokens, latency, and hosted-model cost. It does not prove that an MCP call is always cheaper. A large tool schema, a chatty tool response, network latency, retries, or a tiny calculation could reverse the result.

The clock result: useful, but not a fair arithmetic contest

All configurations returned the same three activities in the same order:

Guided Nature Walk — $20
Mountain Hiking Tour — $45
Jazz Club Evening — $60

The reported age differed:

Config	Claude Opus 4.8	GPT-5	qwen3:30b
MCP-backed tool	36 (15/15)	36 (15/15)	36 (15/15)
Instruction-only Skill	35 (14/15)	36 (15/15)	33 (12/15)
Prompt only	35 (15/15)	36 (15/15)	33 (14/15)

The benchmark ran on July 19, 2026, and the customer was born on May 15, 1990, so 36 was correct. The Rust service read that date from the system clock. Opus often behaved as if the year were 2025, and qwen often behaved as if it were 2023. GPT-5 returned the exact benchmark date even though the user request and harness system prompt did not supply it. The data does not tell me whether that date came from model behavior or provider-side context, so calling it a “guess” would go beyond the evidence.

This result demonstrates a real production lesson: if an answer depends on current state, give the system an authoritative source for that state. It does not demonstrate that MCP is uniquely able to provide one. A bundled Skill script, a local command, a conventional API, or an MCP server could all read a clock.

It also explains why the bad ages did not change the recommendations. Ages 33, 35, and 36 fall into the same age band, generation, and discount tier in this catalog. Near a boundary, the error could matter. A 65-year-old calculated as 62 would miss the senior discount; an 18-year-old calculated as 17 could cross discount and eligibility rules. Those are examples of what the defect could cause, not outcomes observed in this run.

For repeatable testing, the server already has a FixedClock implementation. The benchmark should use it, or pass the same explicit date to all three configurations. I plan to add that controlled case before making broader correctness claims.

Where I draw the boundary

This experiment reminded me of reading a SQL execution plan. Returning the right rows is necessary, but it is not the end of the engineering work. At scale, I also care about the cost of getting those rows, the behavior under failure, and whether I can test the logic without asking a probabilistic model to repeat it.

My rule of thumb is now:

Use Skill instructions for judgment, workflow, and reusable operating procedures.
Use executable code for calculations, eligibility, prices, policy rules, and access to authoritative state.
Use MCP when that executable capability should be a shared, discoverable tool with a stable interface. A bundled Skill script or ordinary service may be simpler when it should not.

That is also what I look for when interviewing engineers who use AI. This is a personal hiring preference, not a universal standard. I care less about whether a candidate can make a model produce working code and more about whether they can explain which parts belong in model reasoning, which parts need a deterministic boundary, and what the choice costs at production volume.

The benchmark changed my wording, not my conclusion. “MCP beats Skills” is too broad. The claim I can defend is this: for this workload, code-executed business rules beat model-executed rules on cost and latency, and an authoritative clock prevented a silent data error.

That is enough to influence an architecture. It is not enough to declare a universal winner.

Reproduce the experiment or challenge it in the skill-vs-mcp repository . The raw 15-run result set used here is included.

☕ Java at Thirty: Still One of the Strongest Bets in the Enterprise

Sat, 18 Jul 2026 11:00:00 -0500

Three decades after its release, Java is still solving the problems that matter most to enterprise software. That staying power is easy to dismiss as inertia. I don’t think it is. I think it’s the predictable result of a platform that optimized for the things large organizations actually care about — and kept investing in them long after the hype cycle moved on.

Let me be careful about the claim I’m making, though.

The honest version of the claim

I’m not going to tell you Java is the optimal language. That’s an opinion dressed up as a fact, and it falls apart the moment you change the context — Java is not my first reach for a data-science notebook, a systems kernel, or a quick shell script.

Here’s the claim I’ll actually defend: Java remains one of the strongest choices for enterprise software where long-term maintainability, stability, and operational reliability are the dominant concerns. That’s a narrower statement, and it’s a stronger one, because it names the conditions under which it’s true.

For most organizations, success is rarely about using the newest language. It’s about delivering reliable systems, controlling operational risk, hiring engineers at scale, and maintaining software for a decade or more. Judge Java against those goals and its longevity stops looking like nostalgia and starts looking like fit.

Backward compatibility is a feature, not a limitation

The thing developers complain about — Java’s conservatism — is exactly what enterprises are buying.

Code written years ago still compiles and runs. Upgrades are usually boring, and boring is the point. When a platform breaks compatibility casually, every upgrade becomes a migration project, and migration projects are where budgets and timelines go to die. Java’s discipline here means a large codebase can move forward without being rewritten, and that compounds over the lifespan of a system.

Predictable releases you can plan around

Since the six-month release cadence and the Long-Term Support (LTS) model, Java gives organizations something they can actually build a roadmap on. LTS releases give you a stable target with years of support; the interim releases let the language keep evolving without forcing everyone onto the treadmill. You choose your pace. For a business planning multi-year investments, predictability like that is worth more than raw novelty.

The platform is still being invested in

Java isn’t coasting. Recent years have brought genuinely significant work to the platform — virtual threads reshaping how the JVM handles concurrency at scale, ongoing improvements to startup time and memory footprint, pattern matching and records modernizing the language itself, and continued GC advances. This is a thirty-year-old platform still receiving serious, well-funded engineering. That matters when you’re betting a decade of software on it.

A mature ecosystem and a deep talent pool

Two of the most underrated enterprise concerns are “what do I build on?” and “who will maintain it?”

On the first, the JVM ecosystem is vast and battle-tested — Spring and Spring Boot alone cover an enormous surface of what enterprises need, with libraries, tooling, observability, and integration patterns refined over many years of production use.

On the second, the Java talent pool is one of the largest in the industry. You can hire for it, you can staff teams at scale, and you can find engineers who’ve operated Java systems in production for years. That’s not a glamorous advantage, but it’s a decisive one when you’re maintaining critical systems over a long horizon.

Operational reliability is where it earns its keep

None of the above would matter if the runtime fell over under load. It doesn’t. The JVM’s observability, profiling, and tuning story is deep, and the operational patterns for running Java in production are extremely well understood. When something goes wrong at 2 a.m., “well understood” is exactly the property you want.

Where Java isn’t the answer

Being honest about the boundaries is what makes the rest credible. If your problem is a small script, a latency-critical systems component, data science and ML research, or a lean startup optimizing for the fastest possible time-to-first-feature, Java is often not the best tool — and you should reach for something that fits. The claim is about a context, not a coronation.

Why this is on my mind

I spend most of my time now building agentic systems on the JVM, and this is precisely why. The interesting, fast-moving part — the reasoning, the model calls, the orchestration — sits on top of a platform I can trust to still be maintainable, staffable, and operable years from now. New capability on a stable foundation is a good trade. It lets me chase what’s genuinely new without gambling the boring, load-bearing parts of the system.

The takeaway

Thirty years in, Java’s relevance isn’t an accident and it isn’t sentiment. It’s the payoff of a platform that consistently optimized for maintainability, stability, backward compatibility, predictable evolution, a deep ecosystem, and a large talent pool — the exact concerns that dominate enterprise software.

That doesn’t make it the best language for everything. It makes it one of the strongest bets you can place when you need systems to run, and keep running, for a very long time.