I’m Looking for the Right Problem, Not the Right Job Title — Could It Be You?

This is a slightly unusual post.

After almost 20 years of writing software, creating and leading an open-source project, writing multiple books, spending several years as a Microsoft MVP, and generally spending far too much of my free time thinking about developer tools, I've reached a point where I think I know what I want to do next.

And I'm not entirely sure what the job title is.

So instead of starting with a job title, I'm going to describe the kind of work I'd love to do.

I'm looking for a role where I can combine technical depth, API design, developer experience, product thinking and technical leadership.

If that sounds like something your team needs, I'd love to hear from you.

---

Two decades of building software

I've been coding for almost 20 years now.

Over that time I've worked across quite a broad part of the software development landscape, but I've increasingly gravitated towards one particular problem:

How do we make software easier and more enjoyable for other developers to build?

I've written multiple books, spent several years as a Microsoft MVP, spoken and written about technology, and built open-source software used by developers around the world.

You can find some of my books on Amazon.

Looking back, these experiences all taught me different parts of the same thing.

Writing books taught me how to explain complex technical ideas.

Being a Microsoft MVP taught me how much I enjoy sharing knowledge and participating in a technical community.

And building open-source software taught me something I didn't expect: how much I enjoy designing and evolving developer tools as products and ecosystems.

The project that has shaped me the most is Inversify.

---

Inversify

I created Inversify and have developed it from the ground up.

It started as an experiment around dependency injection in TypeScript and Node.js, but over the years it became a much bigger education in both technology and developer experience.

Working on Inversify meant going very deep into things like:

• TypeScript's type system
• decorators
• runtime metadata
• reflection
• compiler integration
• JavaScript and Node.js runtime behaviour
• module systems
• API design
• backwards compatibility
• versioning
• performance
• documentation
• developer experience

But that isn't actually the part of the experience I value most.

The other side of building Inversify was learning how to run and evolve an open-source developer ecosystem.

When thousands of developers are using an API, designing the API is only part of the job.

You have to learn how to listen to users without allowing the loudest user to define the roadmap.

You have to distinguish:

"I want this feature"

from:

"There is actually a deeper problem with the abstraction."

You have to make pragmatic decisions when there isn't a perfect technical solution.

You have to work with contributors.

You have to communicate breaking changes.

You have to think about migration paths.

You have to maintain compatibility.

You have to decide what not to build.

And you have to maintain trust with a community.

In hindsight, Inversify became an accidental education in developer-tooling product and program management.

---

Experimenting with developer experience

One of the things I've enjoyed most throughout this journey has been experimenting with new ways of making developers' lives easier.

For example, inversify-express-utils was one of my early experiments with decorator-based routing and controller APIs for Node.js.

The basic idea was to let developers express an HTTP API using TypeScript classes and decorators:

@controller("/users")
class UserController {
    @httpGet("/")
    public getUsers() {
        // ...
    }
}

At the time, decorator-driven routing and controller APIs were still relatively novel in the Node.js/TypeScript ecosystem.

Today, this style of API is completely mainstream.

That experience was incredibly interesting to me, not because of the particular implementation, but because of the process:

1. Identify a developer problem.
2. Imagine a better API.
3. Build a prototype.
4. Put it in front of real developers.
5. Listen to what they do with it.
6. Discover where the abstraction works and where it doesn't.
7. Iterate.

I've gone through versions of that cycle repeatedly over the years.

And I've realised that I really enjoy it.

---

From Inversify to RFLCT

More recently, I've started thinking about something much closer to the underlying language and tooling.

Inversify has historically relied heavily on decorators and runtime metadata.

After working with that model for years, I started wondering:

What if framework metadata could be expressed through TypeScript's type system instead?

That question led me to start experimenting with RFLCT.

The idea is still evolving, but imagine something like:

import { Reflect, resolve } from "rflct";

interface Shape { sides: number; }

class Polygon {
  public color: Reflect<string, { optional: true }>;

  constructor(
    public shape: Reflect<Shape>,
    public label: Reflect<string>
  ) {}
}

container.bind(resolve<Shape>()).to(Polygon);

Then the compiler generates metadata automatically:

const __RFLCT_Shape = Symbol.for("@acme/shapes@1|src/geo.ts|Shape");

class Polygon {
  constructor(shape, label) {}
}

Reflect.defineMetadata("design:paramtypes", [
  { type: __RFLCT_Shape, metadata: {} },
  { type: String, metadata: {} }
], Polygon, undefined);

Reflect.defineMetadata("design:properties", ["color"], Polygon);
Reflect.defineMetadata("design:paramtypes", [
  { type: String, metadata: { optional: true } }
], Polygon.prototype, "color");

container.bind(__RFLCT_Shape).to(Polygon);

Reflect.defineMetadata("design:symbols", Object.assign(
  Reflect.getMetadata("design:symbols", Reflect) ?? {}, {
    "@acme/shapes@1|src/geo.ts|Shape": __RFLCT_Shape,
    "@acme/shapes@1|src/geo.ts|Polygon": Polygon,
  }
), Reflect);

The interesting part isn't really the syntax.

It's the architectural question behind it:

Can a universal tooling layer understand relationships expressed through TypeScript's type system and turn them into runtime metadata, while leaving the meaning of that metadata entirely to the consuming framework?

Inversify could define what postConstruct, preDestroy, injectFromBase, injectFromHierarchy, etc. mean.

Another framework could define completely different metadata.

RFLCT doesn't need to understand either framework.

This is the kind of problem I've increasingly found myself drawn towards:

the boundary between programming languages, frameworks, APIs, tooling and developer experience.

---

What I think I'm actually good at

I've spent most of my career writing software, and I'm very comfortable doing it.

But looking back at everything I've worked on, I think my highest-leverage skill is increasingly somewhere else.

I really enjoy:

• understanding difficult developer problems
• designing APIs
• designing abstractions
• thinking about programming-language constraints
• exploring new developer experiences
• talking to users and contributors
• collecting and interpreting feedback
• turning conflicting feedback into a coherent direction
• deciding what should and shouldn't be built
• prototyping ideas
• thinking about long-term API evolution
• connecting technical possibilities with actual developer needs

I still enjoy implementation.

But increasingly, I think I can create more value by deciding what we should build and why, and by designing the abstraction that makes it possible.

I don't want to become a non-technical product manager who throws requirements over the wall to engineers.

Quite the opposite.

I want to remain deeply technical.

I want to be able to understand the compiler implications of an API, prototype something when necessary, discuss architecture with engineers, understand the constraints, and get into the code when that's the fastest way to answer a question.

But I would like my primary leverage to come increasingly from technical design, product thinking and direction rather than from implementing every feature myself.

---

So what am I looking for?

I'm honestly not completely sure what the job title should be.

It might be:

• Technical Product Manager
• Developer Experience Product Manager
• Developer Platform Lead
• Lead / Principal Engineer
• Developer Tools Engineer
• Developer Productivity Engineer
• Technical Program Manager
• Developer Ecosystem Lead
• Architect
• or something I haven't thought of yet

The title matters less to me than the actual work.

I'm looking for a role where I can sit at the intersection of:

developers × APIs × technology × product × developer experience

and help figure out what the next thing should look like.

I'm particularly interested in:

• TypeScript / JavaScript
• Node.js
• developer tooling
• compilers and language tooling
• developer experience
• APIs and SDKs
• frameworks
• developer platforms
• programming-language-adjacent infrastructure
• open-source ecosystems

I'd love to work somewhere where developer tooling itself is the product, rather than something that happens to be built internally.

---

What I'd love to do

My ideal day would probably involve some combination of:

"Developers are struggling with X. Why?"

followed by:

"What would the API look like if we solved this properly?"

followed by:

"Can we actually make TypeScript, the compiler or the runtime do that?"

followed by:

"Let's prototype it."

And then:

"Let's put it in front of developers and see what happens."

I love that loop.

I'd love to do it with a team of people who are much smarter than me in their respective areas, where I can contribute the combination of technical depth, API design, developer empathy and years of experience operating an open-source ecosystem.

---

What I bring

I think my background gives me an unusual combination of experiences.

I've spent more than 20 years writing software.

I've created and built a major open-source TypeScript project from the ground up.

I've spent years working directly with developers and contributors.

I've designed APIs that have been used in real-world applications.

I've experimented with new developer-experience patterns.

I've written multiple technical books.

I've been a Microsoft MVP.

And along the way, I've ended up going very deep into areas I originally had no particular intention of becoming an expert in:

decorators, metadata, reflection, type systems, compiler integration and the relationship between compile-time types and runtime JavaScript.

I didn't set out to become a TypeScript language/tooling expert.

I was trying to build useful developer tools.

The technical depth came from having to solve the problems those tools created.

And I think that's an important part of what I can offer.

---

I'm looking for the right problem, not just the right title

I could update my CV and start applying to jobs.

But I'm not sure that's the best way to find this particular kind of role.

I'm not looking for just any job.

I'm looking for a team where this rather unusual combination of experience is useful.

I've spent years building a developer tool from scratch, evolving its APIs, working with its community, dealing with real-world developer feedback and becoming deeply familiar with the technical machinery underneath TypeScript and Node.js.

I suspect there are teams out there where that experience would be extremely useful.

I just don't necessarily know where all of them are.

So I'm hoping that someone reading this will think:

"Wait, this sounds like something our team needs."

Maybe that's at a large company working on developer infrastructure.

Maybe it's a team working on TypeScript, JavaScript, Node.js, VS Code, developer productivity or developer platforms.

Maybe it's a company I've never heard of.

Maybe it's a role that doesn't exist yet.

---

Where?

I'm based in the Irish countryside, so I can only consider fully remote roles.

I'm absolutely fine with occasional travel for things like:

• team gatherings
• conferences
• planning sessions
• customer or developer meetings
• important face-to-face events

I'm just not looking for a role that requires regular commuting to an office.

Remote-first is therefore an important constraint for me.

---

If this sounds like you

If you work on developer tooling, TypeScript, Node.js, compilers, developer productivity, APIs, SDKs, frameworks or developer platforms, I'd genuinely love to hear from you.

Especially if you work somewhere that values people who can move between:

technical architecture ↔ API design ↔ developer experience ↔ product direction ↔ open-source/community

If you know of a team that might be a good fit, please reach out!

Comments

[UnitBuilds]

Sounds like you're looking for a role in the new AI ecosystem? While I dont have a job for you, I do have a philosophical question. What would a world without Node.JS look like? I've been working a while on a MCP server, that drops Node.JS in favor of Rust and drops JSON-RPC in favor of my own flavor of deterministic triples. Results are around 20x reduction in latency. Given the world is running AI and AI runs the world through MCPs, 20x reduction means 20x less compute time, means higher throughput and lower overhead. So in a world that's stripping the existing single threaded, deprecated tools of the past, what would the targeted use-case be where you'd eliminate age-old trialed and tested norms, for something groundbreaking that innovates, where the rest of the industry remains stagnant?

[Remo H. Jansen]

I don't think Node.js is going away buy I can imagine a future in which we will be able to compile Node.js to native apps. Someone will release a AOT compiler for Node. We already have early atempts github.com/vercel-labs/scriptc

[UnitBuilds]

I wouldnt count on that in today's ecosystem. It takes AI a few hours to rewrite Node.js from scratch, it'll take only 10% longer to do the same, but better. Imagine Node.js but rust based and natively multi-threaded and zero-allocation?