Working together

I build languages, frameworks, developer tools, and applications. I also write the material that helps people understand and use them. If your work could use that combination, I’d be glad to hear about it.

You don’t need to arrive with a finished specification. A useful starting point is the problem you’re trying to solve, who it affects, and what you’d like to make possible.

Consulting and employment§

I approach both as a chance to take responsibility for an agreed piece of work. We start by understanding the problem, then discuss the outcome, scope, timeline, resources, and how we’ll make decisions together. Payment and who provides equipment or other resources depend on the arrangement.

I work best with autonomy over my schedule and room to shape the technical approach. Direction and methods are open to discussion. We’ll agree on the coordination and review points the work needs, along with what day-to-day availability looks like.

My independent projects show how I think and build. An engagement can apply those capabilities to a different problem; it doesn’t need to use one of those projects or a particular programming language.

A clear scope and a clear finish§

For consulting, my usual starting point is a fixed-scope sprint of two to four weeks, with at least 50% paid upfront. We agree on what you’ll get, when you’ll get it, and how we’ll check that it meets the agreed criteria. Those consulting payment terms don’t describe employment arrangements.

The useful result depends on the problem. It might be a working system, a foundation for further development, or an investigation that answers a technical question. If there’s too much uncertainty to promise a build, we can first scope the work needed to understand it. Larger undertakings can be discussed as a series of defined stages.

Changes happen. We agree on how to handle changes to scope, timing, or resources before work starts, and raise surprises while there is time to make a decision together.

Handoff and continuing support§

We agree on the handoff as part of the scope. That can include source code, setup instructions, technical documentation, and time to walk through how the system works. Acceptance and any follow-up are part of that discussion.

Continuing support and maintenance are separate services. If you need them, we can discuss their scope explicitly. A completed sprint doesn’t automatically become an ongoing support arrangement.

Teaching as part of the work§

Sometimes the useful result is a team that understands the system well enough to carry it forward. If explanations, examples, or learning material would help, let’s include them in the discussion from the start.

The Tyu project brings a language, toolchain, book, and practical labs together. It’s one example of how I connect building a system with helping people learn it.

Supporting an independent project§

If one of the projects connects with your organization’s work, I’d welcome a conversation about support for its development or teaching material. We would identify a useful next step, who it benefits, and what support would enable.

This is a separate conversation from commissioning work on your own system. There isn’t a standard sponsorship package here; the fit depends on the project and your interests.

Exploring and contributing§

I’m curious about what people might make with these projects. The project sites and repositories are the places to explore, share applications, and discuss contributions. They are still the seeds of possible communities.

For these independent projects, I keep final responsibility for technical direction, with room for people to propose changes and take the work into applications I haven’t imagined. Each project’s documentation describes its current state; participation doesn’t imply an ongoing support commitment.