A favorite joke of mine that I remember from the wall of my computer lab in college goes "There are 10 types of people in this world: those who understand binary, and those who don't." (Get it? "10" in binary is 2. Okay, moving on.) Of course, there are many more types of people than that. (It's just a joke.) There are also many more than two types of types. Blood type. Type A personality. Type 1 diabetes. "He's not really my type." Dog people or cat people. Coffee or tea. Types upon types, but really they all just come down to the simple question: what kind of thing is this?

In software development, we learn early on that "type" means something very specific — a data type. Most people have heard of string and integer, and maybe they know about float and boolean. But you can also make up your own kind of types: ShoppingCart, BlogPost, Dinosaur. You get the picture.

For you non-developers out there, you might be surprised to find that in programming circles, the topic of "types" can sometimes come with strong opinions. Just how strict you should be about types is one of those things that can really get people going. Think tabs and spaces, or text editor holy wars. To everyone outside of tech, this sounds like nonsense. When my wife and kids ask me at the dinner table "what do you actually do, Dad?" and I try to explain the importance of types, they stare at me blankly. So this post is really for them, but maybe you'll learn something too.

I'll try to explain it by using a trick that a colleague once taught me: the "Five Whys." Like a toddler, you just keep asking "but why?" until you hit the bottom of something. So we'll start simple and go a little deeper at each step. Stay with me now...

# Why do we have types?

A type is just a label for what kind of thing a piece of data is: a number, a word, a date. Some programming languages make you label everything, while others let you skip it. To see why that matters, think about the difference between cooking and baking. (See, girls? We're starting with food. You're going to be fine.)

When you're sautéing something, you can wing it with a pinch of salt, a glug of oil, a handful of whatever's in the fridge. This is how my wife cooks: fast, furious, and leaves a trail of bowls, utensils, and a countertop mess in her wake.

My wife in the kitchen

That's like JavaScript, a "loosely typed" language. You can put anything anywhere, and it'll even let you add the number 5 to the word "banana." Instead of stopping you, it happily hands back "5banana" like it did you a favor.

Baking is a different story, though, because baking is chemistry. The wrong amount or a missing ingredient, and your bread doesn't rise or your cake is a brick, and you won't know until it's done and too late to fix. This is more my style of cooking: measure everything, read the whole recipe first, lay it all out before I start. I'm slower, and it's less exciting, but at least I know what I'm going to get.

That's more Java, "strictly typed." You declare what kind of thing goes where, up front, and the language holds you to it before it will even compile.

The tradeoff is real, and it's the same one my wife and I negotiate over when cooking dinner. Winging it is faster and easier sometimes, right up until the moment precision actually matters. With types, you catch your mistake during prep, but without them, you don't catch it until you open the oven, which, in software, means production.

(Because it confuses so many people I talk to, I have to just quickly clarify that Java and JavaScript are not the same thing. In fact, they're not even related. JavaScript just borrowed the name to ride Java's popularity back in the '90s, and we've been correcting people about it ever since.)

# Why would anyone care?

I sort of gave this away already, but the reason this matters is that types let you catch your mistake before anyone else does.

Years ago, as a product manager, the engineering team came to me to declare that they would be migrating our JavaScript codebase to TypeScript (a flavor of JavaScript that is indeed typed). This would take up half of our next several sprints, so I wasn't thrilled about it. It was that situation where you have to spend potentially months of engineering time that would produce exactly zero things you can put on a roadmap slide. (See: technical debt.)

But I did understand why they wanted to migrate. Without types, the only way to know if we'd broken something was to run the code and wait to find out. But with them, the compiler would tell us before ever shipping. And sure enough, it saved us several times down the line, when a problem got caught in code review instead of turning into a customer issue.

It's all those times that someone changes something small and deep in the codebase, the kind of change that quietly ripples out and touches things all over the place. The moment they make the change in a typed system, the code lights up and points you to every single spot that broke.

So that's what those months actually bought us: fewer bugs, and the ability to know things about the code without having to run it first.

# Why isn't just knowing the type enough?

During the COVID years, I jumped on the sourdough bread bandwagon (like so many). It didn't last long because my patience ran thin, but while I was doing it, I learned that not all flour is created equal. All-purpose flour is not bread flour is not cake flour, etc. With sourdough bread, the bread flour was superior. All-purpose might work, but it never came out as good because when you're baking, knowing which flour matters.

One of my few semi-successful loaves

Okay, so I'm stretching this metaphor a bit, but I'm trying to extend it to help explain type attribution. This is when you have to work out all of the specific types within your code. Developers have long done a version of this by hand using their code editor, where they can easily click on any object and jump straight to where it came from. They can follow the trail back through each file until they find where something was really born. That "click to follow the path" trick only works because the tool has quietly worked out what everything actually is. That's type attribution.

Remember all those types of types? This is where they can come back to bite you. You might have two different Customer types that share the exact same name but have nothing to do with each other. One might be a custom version that an internal team wrote, and the other may have been pulled in from some library. Attribution is the work of pinning down which Customer this actually is, where it was defined, and what it connects to. Now multiply that across millions of lines of code, and you've got a genuinely hard problem. (Are you still with me now? Hang in there.)

So why bother? Say you want to find every place in a giant codebase that handles sensitive data. You could just search for a word, the way you'd hit Ctrl+F in a document. But plain text search has no idea what anything means. Search for "log" and you'll get tons of hits (comments, typos, blogs, log in) but not all of them are what you're looking for. But with real attribution, you can find every place that a specific and exact kind of sensitive data flows into a specific and exact logging tool, and get back just those results. Types turn a codebase from a pile of text into something you can actually ask questions of.

# Why aren't they all my types?

No cook grows their own wheat or churns their own butter. They buy ingredients that somebody else made and then assemble them. Software works the same way. If you're picturing someone building an application by typing out all of the code, that's not quite what happens. (Especially not anymore with coding agents.) Modern software development is maybe 5–10% custom code that you actually write, and 90–95% code other people wrote and open-sourced (gave away for free).

One of my favorite xkcd comics: "Dependency" by Randall Munroe, xkcd.com (CC BY-NC 2.5)

That borrowed code has a name — dependencies — and they're the pre-made ingredients of software. Nobody writes their own code for the well-solved stuff anymore, like talking to a database or handling dates or doing encryption. And just like those store-bought ingredients for cooking, they're made up of ingredients of their own. Bread came from flour, which came from a mill, which bought wheat from a farm. A typical project pulls in dozens of libraries directly, and then those quietly pull in hundreds more underneath. (We call those transitive dependencies.)

It's a daunting task to track our food's supply chain, and it's the same with interconnected systems. We take our food for granted, and many developers take their dependencies for granted too. Understanding your code now means understanding everyone else's code too.

# Why does any of this matter?

Types tell you what everything is and dependencies tell you where it came from. When you put them together, you've got a sort of digital master cookbook, with every dish listed out, every ingredient included, and every source traced back to the shelf it came from.

And once you have a cookbook like that, you can do things that are otherwise impossible, like swapping an ingredient across ten thousand recipes at once, or finding every dish that used a batch that just got recalled, instead of opening jars one by one and hoping. Remember, we're talking about every kitchen and meal all at once. (That's called scale.)

So, it took quite a long build up and a lot of stretched analogies to get here, but at last, maybe my family will understand a little bit of what I actually do all day. I work with a tool called OpenRewrite which runs on something called recipes. (There's the payoff for that overused metaphor.) An OpenRewrite recipe is a little set of instructions that reaches into all that code and makes a change: find this, upgrade that, replace those, fix this one bug everywhere it appears. The only reason a recipe can do that safely, across the millions of lines of code in enterprise customer environments, is that it isn't just reading the code as text, it's working from the cookbook. (We call it the Lossless Semantic Tree, or LST). It knows the types, it knows the dependencies, and it knows what every ingredient is and where it came from. You could say, it measures before it bakes. Just like I like to do. So now maybe the next time someone asks my girls what their Dad does all day, they can say I help computers cook.

One year ago today, I started at Moderne. It was the week just following the inaugural Code Remix Summit.

One week ago today, I gave a talk at the second Code Remix Summit. It was my first conference talk since 2019.

So last year I missed Code Remix by one week. But this year I was on the schedule.

When I joined Moderne, it was pretty clear that it was the right move for me, and I shared my reasons why. All of that is still true, but what I didn't share at the time is my own list of personal goals I was bringing with me and the areas of growth I wanted to work on. Now, one year in, feels like a good moment to share some of that list and check in on where I've landed.

# Speaking and showing up more

One of the things I hoped to do more of this year was speaking and being more visible in the community. I had definitely let that muscle atrophy a bit in my last few roles, and I missed it. My Code Remix talk was the culmination of a year of slowly turning that dial back up, along with more LinkedIn writing, more demos in front of bigger audiences, and more willingness to put myself out there. I've been really happy with the engagement I've gotten on LinkedIn and fortunate for all the opportunities I've been given to appear and participate in presentations, webinars, and our weekly livestream.

In fact, we've got a little internal leaderboard going for most Code Remix Weekly appearances. I'm at four, chasing someone who's been at the company at least 4 times as long as me, and he's only ahead by one. Feels pretty good for someone in their first year on the team!

I'd love to do more talks, podcasts, and livestreams, because the only way to get better at it is to keep doing it, and I've got plenty of room for improvement. The funny thing is, every single time, my anxiety builds up so much leading up to it that I wonder why I chose to do it. And then the moment it's over, I'm always glad I did it and already looking for the next one. Apparently this is what wanting it looks like for me.

# Demos and narrative

I came into this job thinking I knew how to build demos in my sleep. A year of doing it at Moderne has reset that for me. The product moves fast enough that staying up-to-date with it is half the work, and you can't tell a story about something you don't understand yet. It's been challenging and fun to follow all the Slack threads, pull requests, and ADRs enough to keep up.

The other half is figuring out the narrative. The demos I'm proudest of this year are the ones where I crafted the most compelling story: the Java 25 modernization walkthrough, the Prethink launch video, and the internal, full product demos we created for analysts. I've always considered tech marketing to be a storytelling role, but storytelling for smart, technical audiences is its own discipline. These are people who can spot a hand-wave from a mile away, and who'll ask thoughtful, challenging questions that you can't fake your way to answering. Plus, getting that audience to lean in instead of lean back is the part of the job I've spent the most time trying to get better at, and the part I find the most rewarding.

# Contributing code

Getting closer to code was one of the things I most wanted out of this role, and Moderne has delivered on that in a few different ways. I've gotten to contribute a little code here and there: training modules and recipes, minor commits to the CLI, and especially documentation, where I'm most comfortable anyway.

But I also spend real time reading through code to understand it, whether it's product code or even the code the product operates on. From picking up more Java to revisiting other languages like Python, JavaScript, and .NET, it's been fun tapping into my engineering core while still staying in my marketing lane.

# Working more closely with product

When I was job hunting last year, I was mostly looking for product roles. Technical marketing wasn't the plan, but it was the path that opened up for me and it turned out to be the right one. Even so, I kept the option of moving back into product open in my head, figuring maybe somewhere down the line I'd eye a product role inside Moderne if the right one came up. But so far, the mix of skills that my technical marketing role has required seems to fit better for me anyway.

So I'm not really chasing a product role right now, but I'm leaning hard into product partnership. We've recently brought on a new outbound product manager, and I'm excited about what that opens up. Another technical storyteller to bounce ideas off of and collaborate with will make my work better. And an outbound PM gives technical marketing something that can sometimes be tough to get enough of: a sharper window into actual customer conversations. That's the part I'm most looking forward to.

# Learning marketing-y stuff

I'll always be technical first. No doubt about that. But one of the things I didn't really expect to come out of this role at first is my growth into the marketing part of technical marketing. Product marketing, demand gen, SEO and the digital side, even social media marketing (like I mentioned about LinkedIn earlier) are all areas I've gotten more fluent in over the past year. I've been part of positioning and messaging conversations before, but sometimes I felt like I only half understood, or had to sort of wing it. (I still feel like that at times.) Even my competitive intelligence work, an area I actually had some experience with, has grown through the challenges of a complex and ever-changing market.

Through it all, I have a supportive and experienced team to learn from, and I definitely feel like a more proficient marketer than I was a year ago.

# The AI of it all

When I started, AI was certainly popping up everywhere. It was in job descriptions, market consciousness, and just the general culture. I used AI in my day-to-day, mostly copy-pasting things into and out of ChatGPT to help with writing. Now that workflow looks so primitive. Engineers on our team (and everywhere) started using agents for serious coding work, and I followed suit for docs and demo construction. Now across our marketing team, we're constantly finding new places where agents can help: demand gen, competitive intel, content production, research, anything else we can think of. I don't have it all figured out, and I'm pretty sure nobody does yet. But leaning in, trying new tools, and adapting to new workflows, has been one of the more interesting parts of this last year (but really only 6 months probably).

Not coincidentally, this story is mirrored in our product narrative itself. The conversation around what Moderne does has credibly shifted to include agents alongside humans, because the same thing that makes our platform useful to a developer turns out to be very useful for agents too. Maybe even moreso. The underlying engine hasn't really changed, but the framing has, and so has the work.

# The people

Reflecting on everything I've mentioned so far, I realize that nearly everything I've made progress on this year has a person attached to it. Someone on the team who knew a thing I didn't and was generous enough to bring me along.

I've learned about social engagement and what actually makes content land. I've gotten a real demand gen education and a better appreciation for how leads drive the business. I've had a manager who's pushed me on personal growth and thinking like a marketer in equal measure. I've gotten sharper on narrative and outbound storytelling from working closely with product and product marketing. I've started to [kind of] understand some SEO stuff and the digital side of marketing in ways I certainly never have before. And then there's all the deeply technical stuff I've learned from engineering and leadership. The list goes on.

But it isn't just learning from colleagues. So much of the most rewarding work this year has been very collaborative: writing and reviewing drafts back and forth with product marketing, building video content with our multimedia manager, pairing with engineers and sales engineers on demos and training, and tightening narratives with product. The work is better for it, and the process is more fun.

This is one of the gifts of joining a small, sharp team. I came in ready to contribute, which I am, but the real benefit is how much I've picked up from the people around me, and how much I can still learn from them. I love this team!

# Gratitude, and the next year

A year in, I'm realizing how lucky I am to have landed somewhere that fits so well at this particular moment. The team is amazing, the product is compelling, and the market keeps handing the company new and bigger reasons to exist. Even better, the work itself lets me bring more of myself to the job than most roles would.

I don't know exactly what this next year looks like, but if this last year is any guide, nobody does. Still, I know what I want to keep working on, and I know I'm in the right place to do it.

See you at next year's Code Remix!

I've found there to be plenty of variance in the industry around job titles, so I usually don't put a ton of weight on them. I've had titles that weren't very descriptive of my actual role. I've had titles that seem to imply something that isn't even true about what I do. I've seen junior-sounding titles for people who seemed pretty senior, and senior-sounding titles for people who acted more junior.

Regardless of the names and levels, I've worked in technology for long enough to have collected several job titles that are difficult to explain at dinner parties or to family members. That's why, when I transitioned from enterprise IT into product management ten years ago, I wrote a post to help answer that dreaded question: “So... what do you do?”

Fast-forward a decade, a few roles, and a handful of technology fads later, and I’ve once again found myself in a job that even people inside tech sometimes struggle to define: technical marketing.

Despite being an important function, particularly for developer-facing products, the role of technical marketing can sometimes be confused with engineering, product, or traditional marketing. That's actually fair, though, because tech marketing does borrow elements from all three.

So how is technical marketing different?

# How Technical Marketing Fits In

Admittedly, the first time I joined a marketing team, I was a bit trepidatious about it, at least initially. Isn't marketing too far removed from the technology itself? Would I ever get to talk to an engineer or even write code again?

I quickly learned that actually, technical marketing isn't so far from product management, or any of the roles I've had in my career really. When I first got a job as a product manager, I described it as a role "in the middle", like the connective tissue between customers, engineering, and the business. Technical marketing lives in that same neighborhood, just a few doors down. While product management decides what to build and why, technical marketing focuses more on why what we built matters, and more importantly, how to show it.

I guess that might sort of sound like marketing more generally. Traditional marketing, or more specifically, product marketing, is indeed (at least partially) about telling the story of why something matters — the value proposition, perhaps you've heard it called. But it's that last piece I mentioned before, the "how to show it" part, that I think is the key distinction. A technical marketer can't just say something, they have to prove how it works and build understanding. If marketing inspires people to want to learn more, technical marketing helps them actually get there.

It's sort of analogous to the sales associate and sales engineer. When a salesperson pitches something in a room full of executives, talking about what it does might be enough. But invite some architects or developers into the room, and you better have a sales engineer there to field the tougher technical questions and show them how it works.

# What About Developer Relations?

Another area I’ve worked in and around is Developer Relations, which I’d describe as at least adjacent to technical marketing. Both disciplines are about building trust with a technical audience, so there’s definitely overlap.

In my experience, Developer Relations is primarily about cultivating a community of practitioners, sparking curiosity, earning credibility, and helping people succeed whether or not they ever become customers. It’s about awareness, trust, and engagement. Technical Marketing, on the other hand, focuses more on enablement and adoption, showing how the product delivers value, differentiates, and solves real problems for customers and partners. It's not a perfect delineation (like I said, there's overlap), but I guess you could say DevRel makes fans and Technical Marketing builds believers.

Truthfully, all of these areas — PM, DevRel, and Tech Marketing — sit along the same bridge between technology, communication, and empathy. But each one might put a little more emphasis on a different area: Product Management on strategy, Developer Relations on community, Technical Marketing on proof and enablement. I’ve been fortunate to work in all three, and each helped sharpen different skills from strategic clarity, to technical depth, and creative communication.

It's why I love these types of roles so much. They let me bring all sides of myself to work: the analytical and the imaginative, the engineer and the storyteller, the tech enthusiast and the theatre kid. It’s where my left brain and right brain finally get equal billing.

# So...What Do You Do?

There are probably several different views on what technical marketing is and how to define it. For me, when I explain my role, I find it’s helpful to break things into two categories (the same ones I used a decade ago when I wrote about product management): what we need to know, and what we actually do.

# What Technical Marketers Need to Know

Unsurprisingly the three key knowledge areas are pretty much the same as I listed for PMs.

To do this job well, we have to know the product as more than just a list of features. We learn it by using it. We dig under the hood to understand how things work, explore the user workflows, and every now and then work through a rough spot to figure out what’s really going on.

We try to stay close to the market too. That means understanding not just who competes with us, but what existing customers and potential users are actually struggling with, what’s changing in their world, and where things are headed next. Context matters as much as capability.

The best technical marketers also pay attention to when something isn’t clicking for customers (and prospects). Whether it shows up during a demo, in a training session, or in the questions we hear out in the market, those moments usually reveal a gap in how we explain the product. That insight shapes what we build next, from clearer docs to new demos and enablement. Which leads nicely into...

# What Technical Marketers Do

To me, the most fun (and challenging) part of technical marketing is crafting a narrative. I'm not talking about inventing spin, though, because credibility is key with a technical audience. I mean we distill the heart of the value and figure out the most compelling way to reveal it. We make technical concepts feel relevant and even exciting.

In my day-to-day, that might look like:

• presenting a live or recorded demo
• recording feature walkthroughs
• building, facilitating, and maybe even delivering training courses
• writing technical content
• developing competitive materials to help sales and partners position the product
• enabling field teams with deeper technical context
• giving live product demos at tradeshows or events (I was doing this in only my second week on the job!)
• taking questions, confusion, or objections and turning them into clearer messaging or new content

It's a lot of learning in public, which can sometimes mean pushing through impostor syndrome to ultimately show expertise and prove the narrative.

If you’re curious what this all looks like in practice, here are a few recent examples I had a hand in:

• Java 25 modernization demo
• Feature walkthrough video
• Hands-on training sessions
• Blog about writing OpenRewrite recipes using AI

# Why I Love It

Across every role in my career — IT, product, developer relations, and now technical marketing — the theme has been consistent: translate technology into possibility and turn complexity into confidence.

What’s great is that I get to blend analytical precision with creative expression. The architecture diagrams matter, but so does the storytelling arc. The tech and the theatre kid get to show up every day. That combination is where I feel most at home.