DEV Community: Shannon Mettry

Your job title is lying about you

Shannon Mettry — Sat, 04 Jul 2026 11:35:17 +0000

Job titles don't really explain what we do.

Especially in tech where you can have the same title as someone doing something completely different and a completely different title from someone doing exactly the same thing.

I have been thinking about this for a while and it is time to actually say it out loud.

What my title actually says

Product Application Consultant. Also internally known as Product Specialist.

When I read that on my own CV I genuinely have to resist the urge to apologize for it. Not because the work isn't good. Because the title tells you absolutely nothing about the work.

It doesn't tell you that I write JavaScript logic every day. It doesn't tell you that I make POST requests like nobody's business. It doesn't tell you that I have architected entire workflows from scratch, scoped them, built them, delivered them.

It doesn't tell you about the integrations I maintain across multiple platforms, the APIs I debug, the incidents I handle, the new projects I scope end to end.

Product Application Consultant. Sure. That.

Where it actually hurts

For a while it was just a background frustration. A slow burn. The feeling of knowing what you debugged and knowing your title gives people absolutely no indication of that.

Then I started job searching and it became a real problem.

When you are applying for roles and your title doesn't reflect your actual skill set you are starting every conversation at a deficit. Recruiters see the title before they see anything else.

And Product Application Consultant doesn't say developer. It doesn't say integration engineer. It doesn't say I have been knee deep in JavaScript and API architecture for nearly three years.

And the frustrating part? A lot of the developers I have come across are doing similar work to me. Same problems, same tools, same logic. Different title. Different perception. Different salary band.

That is not a small thing.

The title trap in tech

Tech is especially bad for this because the same title can mean completely different things at different companies. A Solutions Engineer somewhere might be doing pure sales. At another company they are building complex technical integrations. An Implementation Consultant at one place is clicking through a UI. At another they are writing code.

There is no standardization and that creates a weird invisible hierarchy where your actual skills get buried under a label that HR invented and nobody outside your team fully understands.

So what do you do about it

Honestly I am still figuring that out.

What I know is that the title is not the whole story and you cannot wait for it to tell your story for you. You have to show the work. Write about it, talk about it, build in public, make it visible somewhere that a title cannot reach.

Because you know what you debugged. You know what you built. You know how deep the work actually goes.

Your title might be lying about you. That doesn't mean you have to let it.

Nobody talks about the aftermath of closing a brutal ticket

Shannon Mettry — Sun, 28 Jun 2026 16:22:16 +0000

Nothing like finally closing a ticket you've been working on for days.

That's what I posted on LinkedIn recently. People related to it immediately. But the LinkedIn version was the clean, punchy summary.

The real version is messier and honestly more interesting.

What it actually looks like

You wake up. You open the same file you've had open for three days. You rerun the same code. You fix one error and another one appears. You fix that one and something else breaks. You do this for eight hours. You go home. You come back and do it again.

And then one day — poof. It works.

And you expect to feel like a champion. And you do, for about twenty minutes. And then someone drops a new ticket in the queue and you're supposed to just... pick up your bootstraps and go again.

Nobody talks about that part.

The aftermath nobody mentions

There's a specific kind of exhaustion that comes after a grueling ticket. It's not tiredness exactly. It's more like your brain has been squeezed completely dry and needs time to refill before it can do anything useful again.

And the weird thing is you feel guilty about it. Like you just closed something hard, you should be on a roll, you should be motivated and energized and ready to attack the next problem.

Instead you're staring at your screen achieving approximately nothing and wondering what's wrong with you.

Nothing is wrong with you. Your brain just ran a marathon and you're expecting it to immediately run another one.

What I do instead

I go outside. Fresh air, no screen, no thinking about code.

Sometimes I run. There's something about moving your body that unsticks whatever got stuck like the mental load physically shakes loose when your feet hit the ground.

Sometimes I just exist for a bit. No podcast, no music, no productive activity. Just being without thinking. Which sounds simple and is actually harder than debugging a POST call.

That's it. That's the whole strategy.

Give yourself the space

If you've just closed something brutal and you feel slow and foggy and unable to start the next thing, that's not laziness. That's your brain asking for what it needs.

Don't guilt yourself into pushing through it. Take the walk. Go for the run. Stare out the window for twenty minutes. Let your brain unload.

You will come back to your badass bug-solving self. You always do.

Just not always on the timeline your ticket queue would prefer.

Funny where this industry takes you

Shannon Mettry — Mon, 22 Jun 2026 17:29:05 +0000

Everyone in tech has one of these stories.

Where you started vs where you ended up.

Mine goes: hover animations → APIs sending data behind the scenes. Pretty much opposite ends of the stack. Here's what happened in between.

Where I started

I got into tech for the love of user interface. The feeling you get when you first land on a page that just works. Changing colors, hover states, animations, I was obsessed with how a good interface could make you feel something without you even noticing it was doing that.

That's what pulled me in. The invisible craft of it. The fact that someone had made a deliberate decision about every pixel you were looking at.

I thought that was my lane. Frontend, UX, the visual web. I was pretty sure that's where I'd stay.

What integrations actually are

Then I ended up in integrations. And I had to explain it to people who had no idea what that meant, which forced me to actually think about it clearly.

Here's the simplest version: integrations are about sending and receiving data between systems. Getting one platform to talk to another. Making sure the data is formatted correctly when it leaves, arrives intact on the other end, and actually contains everything it was supposed to contain.

And when it doesn't work, which it frequently doesn't, you're debugging.

Why wasn't the data sent? Why was it received but missing half the information? Why did it work yesterday and not today? That's a lot of what the job actually is. Detective work, basically. Except the crime scene is a POST call and the culprit is usually a field that wasn't mapped correctly.

It sounds dry. It genuinely isn't.

The moment I realized I'd shifted

It happened gradually and then all at once.

I was deep in a workflow one day , writing JavaScript, running SQL queries, testing POST calls in Postman, thinking architecturally about how to build the whole thing end to end. And I looked up and realized there was nothing visual about any of it. No UI. No hover states. No thinking about how a user would feel landing on a page.

I was doing backend work. Full stop.

And somehow I wasn't upset about it. I was just... in it. Curious about it. Wanting to go deeper.

That's when I stopped thinking of myself as a frontend person. Not with any dramatic announcement. Just a quiet realization that the identity had shifted without asking permission.

What I'd tell someone early in tech

Go in with an open mind. Always be open to trying new things.

I know that sounds like generic advice but I mean it specifically. You genuinely have no idea what's going to tickle your feather. I didn't know integrations existed as a discipline when I started. I definitely didn't know I'd find debugging data flows more satisfying than perfecting a hover animation.

You don't find your thing by planning for it. You find it by staying curious and saying yes to things that scare you a little.

The industry will take you somewhere unexpected. That's not a warning. It's the best part.

Codewars did not teach me JavaScript. My job did.

Shannon Mettry — Thu, 18 Jun 2026 16:08:05 +0000

Why your brain learns faster by doing than by studying, and the neuroscience that explains it

I spent months on Codewars. One to two problems a day, every day. When I couldn't figure out the answer I would look it up and memorize it.
I also bought courses. Multiple. I knew the basics of JavaScript well enough to talk about it.

And yet nothing really stuck. The Codewars questions felt abstract and disconnected. The examples made no logical sense to me. I would finish a problem and think okay, and? My brain would not hold onto it because it had nowhere to put it.

Then I got a job that threw me into real code. Real systems. Real consequences.

And everything changed.

The moment it clicked

I remember the specific moment I knew something had shifted.

I got a ticket that required updating a complex, long script. Hundreds of lines of code. The kind of thing that would have made past me close the laptop and go make a coffee and quietly panic.

Instead I sat with it. Read through it. Understood what it was doing, where to go in, what to change.

I did not memorize my way to that moment. I built my way there through months of real work with real purpose.

That is not a coincidence. That is neuroscience.

What is actually happening in your brain

When you learn something in a real context your brain does something different than when you study it abstractly. It does not just store the information, it stores it connected to everything around it. The system it lives in, the problem it solves, the feeling of figuring it out.

This is called contextual learning. Your hippocampus, which handles memory formation, encodes information much more effectively when it is attached to a meaningful experience. Abstract exercises give it nowhere to anchor. Real problems give it a whole ecosystem to hold onto.

There is also the dopamine loop to consider. Every time you fix something real like a bug, a broken integration, a script that finally runs correctly your brain releases dopamine. That dopamine hit reinforces the behavior and the learning attached to it. Your brain literally marks that moment as worth remembering.

Why algorithms and abstract exercises are so hard for certain brains

Here is the thing nobody says out loud. Codewars and algorithm challenges are not bad. They work for some people. Specifically they work for people who can hold abstract problems in their head and find satisfaction in solving them without real world context.

Not everyone's brain works that way.

Some people, and I am clearly one of the, need the concrete thing first. The real system, the actual purpose, the tangible result. The theory makes sense after the experience, not before it.

Neuroscientists call this bottom up learning. You build understanding from specific real experiences upward toward general principles. The opposite, top down learning, starts with the abstract concept and works toward application. Neither is better. They are just different and most technical education assumes everyone is top down.

If you have ever felt stupid because you could not get through algorithm challenges, you are probably not stupid. You are just bottom up in a top down world.

What actually worked for me

Real projects with real stakes. A job that required JavaScript every single day for eight hours. Tickets with consequences. Systems I could break and fix and break again.

The repetition mattered too. Doing the same types of problems over and over in slightly different contexts until the patterns stopped being something I had to think about and became something I just saw.

That is how procedural memory forms. The same way you learn to drive or surf. Not by studying the theory but by doing it until your brain stops treating it as a conscious effort.

How to use this if you are learning right now

Stop grinding abstract exercises if they are making you feel like you are not smart enough. That feeling is your brain telling you it needs context not confirmation that you are broken.

Find a real project. Build something you actually care about even if it is small and messy. Contribute to open source. Get a job that throws you in the deep end. Find any context that gives the code a reason to exist and your brain something real to hold onto.

The courses are not useless. The foundation matters. But the foundation only becomes a building when you have something real to build.

Your brain is not the problem. The method might be.

REST vs SOAP — what nobody told me when I started working with both

Shannon Mettry — Wed, 17 Jun 2026 16:40:06 +0000

REST and SOAP are both ways of sending and receiving data between systems. They do the same job. They just do it very differently. And nobody really explained that to me clearly when I started. I just kept looking for patterns until things clicked.

This is what I wish someone had said out loud.

How I actually encountered both

I use REST most of the time. It feels natural at this point. I think in it, I debug in it, it's the default mode.

Then a client comes along running Adobe Campaign Classic and suddenly I am looking at XML wrapped in envelopes and thinking okay, different rules here. SOAP shows up with older enterprise systems a lot. The kind of platforms that were built before REST was even a thing and have no intention of changing now.

You don't always get to choose which one you work with. The system chooses for you. So you learn to read both.

My approach when I hit something unfamiliar is always the same, look for the patterns. What is this sending? What structure is it expecting back? What breaks when something goes wrong? The specifics change but the thinking doesn't.

What REST actually is

REST stands for Representational State Transfer. It is an architectural style for building APIs that communicate over HTTP. It sends and receives data in JSON format, which is lightweight, human readable, and maps naturally to JavaScript objects.

It works with standard HTTP methods: GET to retrieve data, POST to send it, PUT to update it, DELETE to remove it. If you have done any web development you already know these.

javascript// GET request — retrieving a user
const response = await fetch('https://api.example.com/users/1', {
  method: 'GET',
  headers: {
    'Content-Type': 'application/json'
  }
});

const data = await response.json();
console.log(data);

// POST request — creating a user
const newUser = await fetch('https://api.example.com/users', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    name: 'Shan',
    role: 'Integration Developer'
  })
});

const result = await newUser.json();
console.log(result);

Clean. Readable. Does exactly what it looks like it does.

What SOAP actually is

SOAP stands for Simple Object Access Protocol. The word simple is doing a lot of heavy lifting there.

SOAP sends data wrapped in XML inside a defined envelope structure. It has strict rules about how messages are formatted, what headers look like, and how errors are handled. It was built for enterprise environments where consistency and security matter more than convenience.

xml<!-- SOAP request envelope -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <AuthHeader>
      <Username>shannon</Username>
      <Password>supersecure</Password>
    </AuthHeader>
  </soap:Header>
  <soap:Body>
    <GetUser>
      <UserId>1</UserId>
    </GetUser>
  </soap:Body>
</soap:Envelope>

<!-- SOAP response -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetUserResponse>
      <Name>Shannon</Name>
      <Role>Integration Developer</Role>
    </GetUserResponse>
  </soap:Body>
</soap:Envelope>

More verbose. More rigid. But when you are working with systems like Adobe Campaign or banking platforms or healthcare integrations, this is the language they speak and you meet them where they are.

The practical differences side by side

Data format: REST uses JSON, SOAP uses XML.
Protocol: REST works over standard HTTP, SOAP has its own protocol on top of HTTP.
Flexibility: REST is flexible about structure, SOAP enforces a strict contract.
Error handling: REST uses HTTP status codes like 404 or 500, SOAP has its own fault elements inside the envelope.
When you see it: REST is everywhere in modern APIs and web services. SOAP shows up in enterprise systems, legacy platforms, and anywhere that was built before REST became the standard.

How I approach switching between them

When I hit a new integration I look for patterns first. What format is the data in? What does the request structure look like? What does a successful response look like versus an error?

With REST that usually means checking the endpoint documentation and looking at the JSON structure. With SOAP it means finding the WSDL file which defines all the operations and data types the service supports, and then working out what envelope structure it expects.

The thinking is the same. The syntax is just very different.

The one line to remember

REST is a conversation. SOAP is a legal contract.

Both get the job done. One just requires a lot more paperwork. And sometimes the paperwork is not optional.

I stopped posting when I got a job. Classic.

Shannon Mettry — Sat, 13 Jun 2026 11:42:50 +0000

That's what I wrote when I came back to LinkedIn recently. Short, a little dry, kind of embarrassing to admit. People related to it immediately.

But the longer version is more interesting.

The return

I used to post every day. CSS tips, UX observations, little things I noticed about how people move through interfaces. I was genuinely excited about it. I'd wake up thinking about what to share. Then I got a job, got comfortable, got absorbed into the rhythm of meetings and incident queues and just... stopped.

I didn't notice how much I missed it until I came back. And coming back made me think about why I left in the first place. And that made me think about what social media actually is now and what we're all doing on it.

So now I'm back. Not with a strategy or a content calendar. More like an experiment.

What makes people stop scrolling? What gets a reaction and what disappears into the void? I have theories but no data. And the only way to get data is to show up and pay attention.

Also, rejection therapy. Because apparently posting on the internet still makes me nervous and I think that's worth pushing through.

How social media actually changed

Here's what I keep thinking about. Our phones are our TVs now. That's not a metaphor anymore, it's just true.

We don't sit down to watch something scheduled at a specific time. We scroll through hundreds of micro-moments from real people living real lives and decide in about half a second whether to stay or keep moving. The average human attention span online is now shorter than a goldfish. Which is either depressing or fascinating depending on your mood.

And it's changed everything around it. The way brands sell. The way people find jobs. The way ideas spread. The way trust gets built between a stranger and an audience.

Sales used to be about reach, get your message in front of as many people as possible. Billboards. TV spots. Email blasts. Now it's about resonance. Does this person feel real? Do I trust them? Do I want to keep watching? You can have a million followers and no trust, or a thousand followers and genuine influence. The metric that used to matter most is now almost beside the point.

Every person with a phone is now a potential channel. A media company of one. Including me. Including you.

The niche question

Everyone says you need a niche. Find your lane, stay in it, build an audience around one specific thing.

I don't have mine yet. I'm a tech person who loves integrations and APIs and also thinks about UX and also wants to try UGC content creation and also finds the sociology of social media genuinely fascinating. That's either a problem or just an honest starting point.

I think the people who say "find your niche first" are skipping the part where you have to try things before you know what fits. You don't find a niche by thinking about it. You find it by showing up, making things, paying attention to what feels natural and what feels like a performance.

So that's what I'm doing. Natural, honest, with a dry edge of humor. No performing confidence I don't have. Just curiosity and consistency and seeing what happens.

Why this matters for people in tech specifically

If you work in tech and you're not building any kind of public presence, I'm not saying you have to, but it's worth at least thinking about.

The way people get hired is changing. The way people find collaborators is changing. The way you demonstrate what you know is changing. A CV is still important but it's increasingly one part of a bigger picture. What do you write about? What do you build in public? What problems do you talk about?

I'm not saying become an influencer. I'm saying show up somewhere consistently and be honest about what you're learning. That's it. The bar is lower than it looks.

I know because I just came back after years away and the most common response I got was "same."

So. Here we are. Let's see what this social media thing does.

How I stopped nodding along and actually contributed to open source

Shannon Mettry — Thu, 04 Jun 2026 15:57:00 +0000

For years I saw "open source contributions" on job descriptions and just... nodded along. Typed it into Google once, got overwhelmed, closed the tab.

It always seemed like something other people did. People who actually knew what they were doing. People who weren't me.

Then I started looking into it properly. And honestly? It still seemed big. Like I'd need to understand an entire codebase, find a complex bug, write some genius fix that the maintainers would applaud.
Turns out that's not it at all.

I found some resources that changed how I saw it completely. The bar to start is embarrassingly low, and that's intentional. The open source community built it that way on purpose.

So I did it. Was it a few lines of code? Yes. Did I do it directly in the browser like a person who has no idea what they're doing? Also yes. Do I care? Absolutely not.

Where to actually start:

goodfirstissue.dev — filters repos by good first issue label
up-for-grabs.net — same idea, different interface
Docs you already use — if you read something and think "that's oddly worded," you're already there
GitHub search — label:"good first issue" is:open and filter by language

Here's the thing though, this isn't just about open source. Everything seems big and intimidating at first. So you start small. One tiny contribution. Not because it's impressive but because it's real, and it's yours, and it builds something. Confidence mostly. Then you do a slightly bigger thing. Then a bigger thing after that.

You don't level up by waiting until you're ready. You level up by starting small and not stopping.

My first contribution exists now. That's enough for today.

Why WhatsApp API Integrations Fail: Lessons from Real-Time Systems

Shannon Mettry — Sat, 23 May 2026 18:32:24 +0000

In marketing technology, “sending a message” is never just sending a message.

In my case, I work on the technical layer that prepares and sends structured campaign data from a delivery creation system into the Meta WhatsApp Template API.

That means I don’t build the messaging platform itself. I build everything before it:

validating campaign data
enforcing strict formatting rules
structuring payloads correctly
checking whether requests were accepted
and building workflows that survive very opinionated APIs

And if there’s one thing I’ve learned from working with strict APIs, it’s this:

The hardest part is rarely sending the data.

The hardest part is convincing the API your data deserves to exist.

The reality of “real-time integrations”

People hear “real-time integration” and imagine something elegant:

System A → API → Message sent

In reality, the workflow usually looks more like this:

Delivery Creation System
        ↓
Data Validation Layer
        ↓
Payload Transformation
        ↓
WhatsApp Template Formatting
        ↓
Meta API Request
        ↓
Acceptance Check
        ↓
Webhook Confirmation
        ↓
Retry / Logging / Monitoring

The message itself is actually the easiest part.

The difficult part is making sure the payload satisfies every rule enforced by the receiving API.

And the Meta WhatsApp Template API has a lot of rules.

Strict APIs do not negotiate

One of the first things I learned is that WhatsApp templates are extremely rigid.

You are not sending “messages”.

You are sending:

approved templates
predefined structures
validated variables
controlled CTA configurations

Everything has to fit the exact schema expected by Meta.

Not “close enough”.

Not “technically valid JSON”.

Exactly correct.

The formatting constraints are where things get interesting

Most integration issues were not caused by networking problems or authentication failures.

They were caused by formatting.

For example:

Invalid newline characters

Something as small as an unexpected newline character can create problems depending on template validation rules.

This means data often has to be sanitized before it is sent.

Example:

function sanitizeText(value) {
  return String(value).replace(/\n/g, " ");
}

Simple?

Yes.

Important?

Extremely.

Because formatting is not cosmetic in systems like this.

Formatting is logic.

CTA rules: where flexibility disappears

Call-to-actions (CTAs) were another area with strict constraints.

Templates only allow certain CTA structures:

limited number of buttons
predefined action types
strict ordering requirements

Which means you cannot dynamically invent whatever UX the business wants.

At some point, every integration engineer eventually says:

“No, we cannot add a fourth button because Meta said no.”

And surprisingly often, that becomes a real architectural discussion.

The integration layer became a validation system

One of the biggest lessons from this workflow was realizing:

The system is not really a messaging system.

It is a validation system that occasionally sends messages.

Before anything gets sent, the workflow has to verify:

CTA counts are valid
variables match template expectations
required fields exist
formatting rules are respected
payload structure matches the approved template

Because once the payload reaches Meta:

it may be accepted
it may be rejected
or in some cases, it may fail in ways that are not immediately obvious

Which is why defensive validation matters so much.

Building the payload

Here’s a simplified example of the kind of transformation logic involved in the integration layer.

function buildTemplatePayload(to, template, variables, ctas) {

  if (ctas.length > template.allowedCtas) {
    throw new Error("CTA limit exceeded");
  }

  const sanitizedVariables = variables.map(variable =>
    String(variable).replace(/\n/g, " ")
  );

  return {
    messaging_product: "whatsapp",
    to,
    type: "template",
    template: {
      name: template.name,
      language: {
        code: template.language || "en_US"
      },
      components: [
        {
          type: "body",
          parameters: sanitizedVariables.map(value => ({
            type: "text",
            text: value
          }))
        }
      ]
    }
  };
}

The interesting part is not the JavaScript itself.

It’s the design philosophy behind it:

Data cannot be trusted to arrive API-ready.

It has to be transformed into something the receiving system is willing to accept.

“Message sent” is not success

Another important lesson:

Sending the request is only half the workflow.

After the payload is sent, we still need to determine:

was the request accepted?
was the message processed correctly?
did the delivery succeed?
did downstream systems confirm the event?

So after sending the payload, the workflow performs additional checks:

async function sendMessage(payload) {

  const response = await fetch(
    "https://graph.facebook.com/v19.0/messages",
    {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.TOKEN}`,
        "Content-Type": "application/json"
      },
      body: JSON.stringify(payload)
    }
  );

  const data = await response.json();

  if (!response.ok) {
    console.error("API rejection:", data);
    throw new Error("Message failed");
  }

  return data;
}

But even a successful API response is not the final truth.

The workflow still relies on:

response verification
logging
webhook confirmation
retry handling
reconciliation checks

Because in real integrations:

“Accepted by API” does not automatically mean “delivered successfully”.

Real-time systems are actually reliability systems

One thing I underestimated early on was how much of “real-time integration” is actually about resilience.

You quickly realize the real engineering work is:

handling retries
tracking failures
validating edge cases
preventing malformed payloads
monitoring delivery status

Not just sending requests quickly.

The API call itself is usually the shortest part of the process.

The surrounding system is where the complexity lives.

The most dangerous failures are silent ones

Hard failures are annoying.

Silent failures are terrifying.

Because if a payload fails quietly:

messages disappear
workflows become inconsistent
debugging becomes archaeology

That’s why observability became extremely important in our workflow.

Every step needed:

logging
validation
tracking
explicit error handling

Because eventually every integration engineer learns:

If a system can fail silently, it eventually will.

Usually on Friday afternoon.

Constraints actually improve engineering

At first, strict APIs feel frustrating.

But over time, I realized they force better engineering discipline.

You stop making assumptions.

You validate everything.

You think more carefully about:

structure
consistency
formatting
system reliability

And ironically, those constraints often produce cleaner systems.

Final thoughts

Working with the Meta WhatsApp Template API taught me something important:

Most integration work is not about moving data.

It’s about shaping data into something another system is willing to trust.

And in marketing technology, the real challenge is not sending messages in real time.

It’s building workflows reliable enough to survive strict APIs, validation rules, and the reality that every external system has opinions about your payload.

Very strong opinions.