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.