The Shape of a Career

With a birthday approaching and one long professional chapter recently closed, I have been thinking less about what a career looks like on paper and more about the shape it takes while you are living it.

Résumés prefer straight lines. They turn years into dates, responsibilities into bullets, and hard decisions into tidy transitions. That is useful. A résumé needs to make sense quickly to someone who was not there. But it cannot capture the detours: the project that taught you something your title did not, the customer conversation that changed how you design systems, or the role that looked temporary and became foundational.

Looking back, my own path has not been especially straight. I started by building custom applications and commerce systems for a wide range of clients. That work required wearing every hat before I had names for most of them: discovery, design, development, deployment, support, and the uncomfortable but necessary work of explaining trade-offs to people who did not care what framework I preferred.

Later came security products, public-sector modernization, enterprise identity, and eventually hospitality technology. On a spreadsheet, that can look like a collection of unrelated industries. In practice, the work kept returning to the same questions: What is the real problem? Which system actually owns the data? Where does the handoff fail? What has to be true for a solution to survive contact with production and the people who depend on it?

Detours Build a Different Kind of Depth

At different points, I have been asked to make an interface usable, stabilize an integration, enter an unfamiliar codebase, build a demonstration that could survive serious questions, or turn an operational process into software. None of those tasks were interchangeable. Together, they built a way of working.

That is the advantage of a career that does not follow a perfectly prescribed track. You begin to see patterns that are hard to learn from one specialty alone. A technical issue is often a communication issue in disguise. A customer request may be a data-model problem. A beautiful architecture that nobody can deploy or support is not complete. A quick fix without a clear operating model becomes tomorrow’s incident.

The deeper lesson is not that every detour is good. Some are expensive. Some teach the same lesson twice because we were not ready to learn it the first time. But a route that looks inefficient from far away can still produce judgment, range, and resilience. Those are not always the easiest strengths to list, but they are often the ones that matter when the requirements are ambiguous and the stakes are real.

What a Decade of Ownership Clarifies

The most recent chapter lasted long enough to make that idea concrete. Building and operating a hospitality platform from its earliest days meant living with the full arc of technical work: discovery sessions, proofs of concept, executive demonstrations, integrations with legacy systems, production incidents, performance constraints, and the quiet maintenance work that keeps a product trustworthy.

It also meant learning that ownership is not the same as control. A founding engineer can build a great deal, but no one person owns the market, the company, the timing, or every decision that shapes the next phase. There is a particular kind of honesty required when a long partnership comes to an end. You can acknowledge what was built, be grateful for the people and problems that made you better, and still recognize that it is time to move on.

Leaving a company after years of shared effort is not a clean subtraction. There is loss in it, even when the separation is the right one. There is also room. The end of a role removes familiar responsibilities, but it can return questions that routine had pushed aside: What do I want to learn now? Which problems do I want to solve? What kind of team and product deserve the next stretch of attention?

The Value of Not Being Easily Reduced

There is a Chinese proverb that says, “A crooked tree lives its own life, while a straight tree is turned into wood.” I have found that image useful lately, not as an argument against being useful, but as a reminder that usefulness is bigger than fitting neatly into one narrow category.

The career version of that idea is not to become difficult for its own sake. It is to resist becoming so optimized for one job that you cannot recognize the next one. The ability to move between customer conversations and code, architecture and operations, legacy constraints and new tools has sometimes made for a less conventional title. It has also made it possible to contribute where the boundary lines are unclear.

That range is why I still care about a pragmatic monolith when it is the right starting point, and why I am spending time with Python, FastAPI, workflow pipelines, and React rather than treating the tools that built the last decade as the only tools worth knowing. Technologies change. The underlying habit is more durable: understand the work in front of you, choose the simplest reliable path, and keep learning before the environment forces you to.

Carrying the Right Things Forward

As this birthday gets closer, I am less interested in making a case for a single, polished career narrative. I am more interested in taking inventory.

I want to carry forward the patience required to understand complicated systems, the confidence to speak plainly with customers and executives, and the humility to investigate before declaring a solution. I want to keep building things that reduce real friction for people doing real work. I want to continue learning languages and frameworks without confusing novelty for progress.

Most of all, I want to keep enough of the irregular shape that got me here. Not every useful life or career is built in a straight line. Sometimes the bends are evidence of adaptation. Sometimes they are where the most interesting work begins.

The next chapter does not need to erase the previous one to be meaningful. It only needs to make honest use of what came before.