DEV Community: Shannon Mettry

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.