DEV Community: Angela Choi

How I Approach Debugging API Issues with Customers

Angela Choi — Mon, 15 Dec 2025 20:33:00 +0000

Debugging API issues with customers is one of my favorite aspects of implementation work. It's technical, but it's also very human. Often, customers join the meeting stressed because something that should be functioning isn’t. My role is to help them slow down, understand what is happening, and move forward with confidence.

Over time, I have developed a straightforward way to approach these conversations. This method keeps the problem manageable and helps customers feel supported rather than overwhelmed.

Start with Their Expectations

Most calls begin with someone claiming that something is broken. Before I examine an error message or a log, I always ask one question: "What were you expecting to happen?"

This question reveals a wealth of information. It helps me understand their goal, why they chose a specific endpoint, how their workflow is set up, and where things might have gone awry. Many API issues aren’t actual bugs; they are mismatches between the customer's expectations and the API’s behavior. Once we align on the goal, the rest of the conversation becomes much smoother.

Walk Through the Request Step by Step

Next, I ask them to walk me through the request they sent. I want to see the parameters, the environment, and the response they received.

Slowing down often surfaces the issue quickly. Sometimes it's due to using a staging token in production, a missing required field, or a small typo hidden within an otherwise perfect JSON body. These mistakes are easy to overlook when you're under pressure, so taking it step by step helps both of us to see what’s really happening.

Simplify the Request

If the request is complex, I help the customer simplify it. We strip it down to the smallest version that should work.

If there’s a large payload, we test with a minimal one. If multiple actions are chained together, we test just one. This approach makes it easier to isolate the problem and provides customers with a troubleshooting method they can reuse later.

Check the Basics First

Most API issues stem from simple matters, so I always start there:

Is the token valid?
Is the correct endpoint being used?
Are field names spelled correctly?
Is the content type appropriate?
Are the correct environments in use?
Are test and production credentials mixed up?

These details can cause significant frustration, but it’s never due to carelessness. APIs are strict, and documentation doesn’t always reflect real-world behavior.

Explain the System’s Response

I never want to simply provide a fix. I always explain why the error is happening and how the system is interpreting their request.

When customers understand the "why," not just the "how," they feel more confident and less dependent when something goes wrong in the future. Debugging turns into a learning opportunity instead of a setback.

Collaborate Rather Than Take Over

Even when I know the answer, I refrain from taking control. I explain what I’m checking and why, then allow the customer to try the next step themselves.

This keeps the process collaborative and helps customers develop their own troubleshooting skills. Over time, I have seen individuals transform from feeling anxious about APIs to becoming comfortable debugging on their own.

End with Clear Next Steps

Before concluding the call, I always provide a recap. I want them to leave knowing exactly what to do next:

The correct request to send
The appropriate permissions to use
How to test the endpoint
What to watch for next time

A clear wrap-up turns a frustrating experience into something beneficial.

Why I Enjoy This Work

The best part of debugging with customers is the moment everything finally works. You can hear the relief in their voices. It feels like a shared victory because we solved the problem together.

I take something that feels stressful and make it manageable. Helping someone understand what’s happening and regain their confidence is what makes this part of the job so rewarding for me.

Why I Fell in Love With Implementation Work

Angela Choi — Mon, 15 Dec 2025 20:05:44 +0000

A few years ago, if you had told me that I would love implementation work, I wouldn't have believed you. Coming from a teaching background, I had experience working with students, but I never envisioned myself teaching adults how to use software or assisting developers with API integration. This role has surprised me in the best possible way. While implementation is technical, at its core, it is profoundly human.

People often perceive implementation as merely checklists, administrative tasks, and onboarding calls. And while there is a fair amount of that, the real work occurs in the moments when you guide people through change. Change brings habits, emotions, and fears that are often unrelated to the software itself.

It Is Not Really About the Tech

After helping thousands of users transition from our legacy platform to a new one, I began to notice patterns. Most people weren't afraid of new features. They were afraid of losing what they already understood. The old platform was familiar. Even if it was clunky, they knew how to navigate it.

What I learned is people do not fear new systems. They fear losing confidence. Being the person who helps them through that moment has become the most rewarding part of my job.

Where Tech Meets Empathy

Implementation exists at the intersection of technical knowledge and human understanding. One moment, I'm explaining an authentication flow or reviewing API logs; the next, I'm reassuring someone who worries that one wrong click could break everything.

There is something meaningful about being the calm voice on the call. When someone is stressed or stuck, I can slow things down and help them feel capable again. You can almost hear it when things finally click. The moment a workflow makes sense or when resistance transforms into curiosity. These moments never get old.

The Wins Feel Personal

As a former developer, I loved shipping new features. However, the wins in implementation feel different. When a customer finally sends their first successful API call after weeks of struggle, it feels like a shared victory. When a team that initially dreaded migration begins teaching each other, it marks a genuine turning point.

These wins are not about solving problems. They involve watching people regain confidence. That sense of impact is what makes the work so rewarding.

You Become a Translator

A significant aspect of this job is translation:

I translate technical concepts into actionable steps.
I translate old workflows into new ones.
I translate customer frustration into valuable product feedback.
I translate complex API processes into clear paths forward.

I still get to utilize my technical skills, but I also help people understand what they are doing. That balance is rare, and I value it more than I initially expected.

What Implementation Taught Me

Implementation has taught me patience. It has taught me to listen for the real question behind each inquiry. I’ve realized that most users believe they are the only ones struggling, when, in reality, almost everyone experiences difficulty during periods of change.

Migrations have shown me that success isn't about feature parity. Instead, it's about guiding people through the uncomfortable space between what they used to know and what they are learning now. Along the way, I discovered that this type of work allows me to connect genuinely with the people I am helping.

Why I Love It Now

I love implementation work because it combines the aspects of technology and human connection that matter most to me.

I help people feel confident.
I simplify complex ideas into manageable steps.
I support customers through real technical challenges.
I balance patience with technical knowledge.
I see the immediate impact of my work.

It never feels like I’m just rolling out an updated software. It feels like I'm assisting people in moving forward through one workflow at a time, one conversation at a time, one API integration at a time.

That is why I have fallen in love with this work, and honestly, I’m glad I did.

What Platform Migrations Taught Me About Customer Behavior

Angela Choi — Wed, 10 Dec 2025 20:22:41 +0000

As a Technical Implementation Manager, my primary responsibility is overseeing software migrations, guiding our users as they transition from our legacy platform to the new one. My goal is to make this process smooth and manageable. After assisting thousands of individuals with this transition, I've come to understand that migrations are less about the software and more about the people involved.

While there are technical considerations, such as importing data, rebuilding workflows, reconnecting integrations, and answering questions like "Where did this feature go?" or "How do I do XYZ?", the core issues are fundamentally human. Change brings uncertainty, shakes confidence, and triggers a mix of emotions, including frustration, hesitation, excitement, and ultimately, relief.

These emotional milestones have taught me a great deal about customer behavior and their true needs. Here’s what I’ve learned:

Customers Don’t Fear Change — They Fear Losing What They Know

Initially, I believed that resistance to migration stemmed from a lack of understanding of the new platform. Over time, I realized that users were not clinging to the old system. They were protecting their comfort zones. For many, migrating feels like losing:

Familiar workflows
Muscle memory
Confidence
A sense of being the "expert"

Even the most advanced power users can suddenly feel like beginners, which can be uncomfortable. Once I started acknowledging these feelings of loss rather than pushing past them, conversations shifted. People became more open and collaborative.

Lesson: Empathy helps move people forward faster than any amount of documentation.

Training Isn’t Just Teaching — It’s Reassurance

When someone logs into a new platform for the first time, they don’t just want a comprehensive product tour. They want reassurance that they won’t break anything. I learned to slow down my demos, explaining why I was clicking certain things and showing what happens if a mistake is made. My go-to phrase became: “It’s okay if you make a mistake. You can’t break anything here—feel free to explore.”Once users feel safe to explore, their learning curve shortens dramatically and their confidence increases.

Lesson: Great training alleviates anxiety as much as it fills knowledge gaps.

Customers Want to Know Why, Not Just How

Simply walking someone through new workflows step-by-step won’t resonate unless they understand why the changes are important. Instead of just saying, “We moved this feature,” I provide context:

“We redesigned this to reduce the number of steps.”
“This is automated now to help teams save time.”
“We split these settings to avoid configuration errors.” This approach makes everything feel more intentional and less arbitrary.

Lesson: Providing context accelerates adoption.

Small Frictions Turn Into Big Emotions During Migration

Minor issues, like a missing button, a renamed setting, or an extra click, can trigger disproportionately strong reactions during migrations. While these would usually be minor annoyances, during a migration—when users feel overwhelmed—these moments can become “proof” that the new platform is inferior. Once I understood this, I proactively addressed those frictions:

“Here’s where that feature moved.”
“This workflow has changed, but here’s what you gain.”
“It may be different, but it’s not broken.”

The goal is to mitigate frustration before it escalates.

Lesson: Anticipate friction and address it early.

People Don’t Adopt Systems — They Adopt Stories

Features alone do not convince people; outcomes do. The pivotal moment in most migrations occurs when I illustrate how the new platform can help users achieve their goals:

“This will cut your reporting time in half.”
“You’ll have much more control over your data.”
“This sets you up for the improvements you’ve been requesting.”

The narrative must connect to their daily reality, not just our roadmap.

Lesson: Adoption is driven by emotions, not just logic.

Migration Success Depends on Understanding Your Champions and Skeptics

Every migration involves two groups:

Champions: Excited, curious, vocal, early adopters
Skeptics: Quiet, hesitant, sometimes frustrated and often very influential

Champions help build momentum, while skeptics can make or break the rollout. I learned to support both groups in different ways:

Champions received sneak peeks, early access, and advanced sessions.

Skeptics were given one on one feedback sessions with our Product Designer to better understand their frustrations and gather honest input about the new platform.

Lesson: Support your champions, but listen closely to your skeptics. Both groups shape the success of a migration, and giving each what they need leads to a smoother, more balanced rollout.

Final Thoughts

After supporting so many people through these migrations, what stays with me most is that this work is really about the humans behind the screens. Every rebuild, every “where did that go,” every moment of confusion or relief has shown me that change is personal long before it is technical.

Once I started approaching migrations with that mindset everything shifted. Conversations became easier. People opened up. They trusted the process more because they felt understood instead of rushed. And in those moments I realized that my job is not just to move users to a new platform, it is to help them feel confident in a new environment.

Looking back, the biggest thing I have learned is that successful migrations happen when people feel supported, not pushed. When they feel like they can ask anything. When they understand the why behind the changes. And when they know they are not alone while they figure it all out.

That is the part of implementation work I enjoy the most. It is not just about upgrading a system. It is about helping people navigate a transition with a little more clarity, a little more confidence, and a lot less stress. Every migration is an opportunity not just to move data, but to move people forward.

What Hogwarts Can Teach Us About Security

Angela Choi — Mon, 24 Mar 2025 20:46:12 +0000

How does Hogwarts keep its magical secrets safe? Enter the world of Identity and Access Management (IAM), the digital equivalent of Hogwarts' security system. Let's break it down using a little wizarding magic.

🔐 What is Identity and Access Management?

IAM is like the enchanted portraits guarding the entrances to Hogwarts common rooms. It’s a system that ensures only the right people (or wizards) can access specific areas, information, or perform certain tasks. It helps keep everything safe and organized.

To make it simple, let's see how Hogwarts uses IAM every day!

1. 🔑Authentication: Proving You’re a Wizard
When Harry arrives at Hogwarts, he has to show his student ID (like the Hogwarts letter) to enter the castle. This is just like logging in with a username and password.

In the real world: You authenticate by entering your credentials (username and password) to prove who you are.

2. 🚪Authorization: Knowing Where You Belong
Once inside, Harry’s student ID determines where he can go. He can visit the Great Hall for meals but needs special permission to enter the Restricted Section of the library.

In the real world: After logging in, authorization defines what data or systems you can access. You might view emails but not confidential financial reports.

3.🦄Single Sign-On (SSO): One Spell, Many Doors
After Harry enters Hogwarts, he doesn’t need to show his ID every time he enters a classroom. Similarly, Single Sign-On (SSO) lets you log in once and access multiple applications without typing your password repeatedly.

In the real world: Using Google or Facebook to log into multiple websites without creating new passwords.

4.🔎Tracking Activity: The Marauder’s Map of Security
The Marauder’s Map tracks everyone's location at Hogwarts. IAM systems do something similar by keeping logs of who accessed what and when. If someone sneaks into the Restricted Section, the system will know!

In the real world: IAM logs help companies monitor for suspicious activity and respond quickly.

🧙‍♂️ Why is IAM Important?

Think of IAM as the Hogwarts security spells that:

🔒Secure Data: Only the right people can access sensitive information, like how only professors can enter their offices.

🚫 Prevent Unauthorized Access: Keeps the digital Dark Wizards (hackers!) out of systems.

🚀 Enhance User Experience: Single Sign-On makes logging in easy, like using a Portkey instead of walking.

📜Support Compliance: Helps organizations follow security rules, just like Hogwarts students follow school rules.

IAM is like the enchanted guardian of the digital world. It ensures only the right people have access, keeps systems secure, and makes navigating online spaces as magical as a day at Hogwarts. So, the next time you log in to an app or website, remember - you're stepping into your own digital Hogwarts, protected by the powerful magic of IAM.

Accio Security!🔮✨

From Pizza Orders to Party Crashers: Understanding Web Security Threats

Angela Choi — Tue, 11 Mar 2025 01:40:07 +0000

Understanding web security threats is crucial for everyone, even those without a technical background. To make these concepts easier to grasp, here are four common web security threats explained using relatable, everyday scenarios:

1. 🍕The Sneaky Pizza Order (SQL Injection)
Imagine you're at a pizza restaurant where you write down your order. Normally, you'd jot down something like, "One pepperoni pizza, please." But what if someone wrote, "One pepperoni pizza; and also give me the secret sauce recipe"? If the chef blindly follows the instructions, they might accidentally reveal their secret recipe.
This is exactly how SQL injection works—hackers insert malicious commands into input fields (like login forms) to trick a website into revealing or modifying sensitive data.

2. 🥠The Fortune Cookie Prank (Cross-Site Scripting)
Picture this: You crack open a fortune cookie expecting a cheesy prediction, but instead, it says, "Warning: Your bank account has been hacked!" Even though it's just a harmless message on paper, it would still give you a scare.
This is similar to cross-site scripting (XSS). Hackers inject malicious scripts into websites that unsuspecting users visit. When the user’s browser processes the code, it could display fake alerts or even steal sensitive information like login credentials.

3. 📝The Gullible Assistant (Cross-Site Request Forgery)
Imagine you have an assistant who follows your instructions without question. Now suppose someone pretending to be you sends them an email saying, "Transfer $5,000 to this account immediately!" Without verifying the sender’s identity, your assistant might unknowingly send the money.
This is how cross-site request forgery (CSRF) works. It tricks authenticated users into performing unintended actions on trusted websites, such as transferring funds or changing account details.

4. 🎉The Party Crasher Nightmare (Distributed Denial of Service)
Imagine hosting a small dinner party for 10 friends. But someone spreads a fake invitation online saying you're hosting an all-you-can-eat buffet. Suddenly, hundreds of strangers show up at your door, overwhelming your space and preventing your actual guests from entering.
This is similar to a distributed denial-of-service (DDoS) attack. Hackers flood a website with so much fake traffic that legitimate users can’t access it, effectively crashing the system.

By using these relatable examples, even non-technical individuals can better understand how these threats work and why implementing cybersecurity measures is so important.

⚔️Stay Vigilant, Stay Secure!🛡️

Implementing Devise Lockable: A Step-by-Step Guide to Account Locking in Rails

Angela Choi — Wed, 05 Mar 2025 18:33:08 +0000

In October 2024, I presented at the Toronto Ruby Meetup on discovering the potential of using Lockable. Devise is a popular authentication library that provides ready-made solutions for user authentication. One of the features it offers is Lockable, which is used to lock a user account after a certain number of failed login attempts. This feature helps improve security by preventing brute force attacks.

A few days months ago, as I was logging into my work laptop, I mistyped my password and ended up getting locked out for one minute. After the minute was up, I tried again, but I was locked out for 10 minutes this time.

The lockable module locks an account after several failed sign-in attempts. You can unlock by email or after a specified period or it can require manual unlocking by an admin. This helps protect user accounts from unauthorized access.

Step-by-step guide

This guide outlines how to implement lockable functionality in your Rails application using two strategies: 1) unlocking via email or time-based methods, and 2) customizing failure and unlock strategies.

Install Devise
Before we dive into implementing lockable, ensure you have Devise installed. If you haven't installed it yet, follow the instructions below.

Unlock by email and/or time based unlock

1. Config file
Let’s take a look at how this would look like in your config file. In this example, I am utilizing both email and time-based strategies. Users will have a maximum of five failed login attempts, and a warning will be issued on their final attempt. To regain access, users can either receive an email with a link or wait one hour to unlock their account.

Lockable adds the following options to devise:
maximum_attempts: how many attempts should be accepted before blocking the user.
lock_strategy: lock the user account by :failed_attempts or :none.
unlock_strategy: unlock the user account by :time, :email, :both or :none.
unlock_in: the time you want to unlock the user after lock happens. Only available when unlock_strategy is :time or :both.
unlock_keys: the keys you want to use when locking and unlocking an account

To learn more about lockable options, please refer to this doc.

2. User Model
Next, we can go to the User model. In my user model, I’ve added a few devise modules already. You can add the lockable module here.

3. Create a migration
rails g migration add_lockable_to_devise

In your migration file, you’ll want to add failed_attempts and locked_at to users so that you can keep track of this information in the backend. If your unlock strategy is email or both you can add unlock_token to your users.

Customizable failure and unlock stratgies

1. Config file
In your config file, you can set the lock_strategy and unlock_strategy to none. You might be wondering how users will unlock their accounts in this case. To address this, you can create a toggle button that allows administrators to lock and unlock user accounts.

2. Users controller
In the users_controller, you can create a function to toggle the lock status of a user’s account. The code below first checks whether the user's account is locked. If the account is locked, the function will unlock it; otherwise, it will lock the account.

An example of a toggle unlocked and locked button

Key Takeaways

The Lockable module from Devise adds a critical layer of security to your application
It is easy to implement the lockable using Devise
Implementing the lockable feature can enhance user trust and safety by protecting their accounts from unauthorized access

API Webhook Security

Angela Choi — Mon, 03 Mar 2025 21:00:00 +0000

Web security is a crucial aspect of modern development, and it's important for everyone to understand how to protect their web applications and APIs. I've been exploring this field extensively lately, and I'd like to share some insights I've gained, particularly in the realm of webhook security. Let me walk you through some key strategies to keep your webhooks secure and reliable.

👀Be Vigilant with Webhook URLs
One of the main vulnerabilities in webhook services is server-side request forgery (SSRF). This occurs when an attacker manipulates your service into making unauthorized requests. Webhooks are particularly susceptible because they rely on user-provided URLs. To mitigate this risk, it's crucial to implement strict URL validation. This not only protects your system but also helps users by promptly informing them if their URL doesn't meet your security standards.

🔐Embrace HMAC for Authentication
Ensuring the authenticity of webhook requests is vital. Even encrypted messages can be intercepted, so we need to go a step further. This is where Hash-Based Message Authentication Code (HMAC) comes in handy. The webhook provider sends a message along with an HMAC signature. When the client receives it, they generate their own HMAC signature. If the signatures match, you know the message is authentic. If not, it's best to reject it. For example, Stripe cleverly includes their signature in a header called Stripe-Signature.

⏰Implement Timeouts and Retries
It's important to set reasonable time limits for webhook requests. If a request is taking too long, you should either terminate it or attempt a retry. Speaking of retries, make sure you have a robust retry mechanism in place for those inevitable hiccups. This ensures you don't lose valuable data due to temporary failures.

📈Monitor and Log Diligently
Keep detailed logs of all incoming webhook requests, including timestamps, IP addresses, and payload content (excluding sensitive information, of course). Set up alerts for unusual patterns, such as sudden spikes in requests. This proactive approach allows you to catch and address potential issues before they escalate.

💻Enforce Strict Authorization
This one's straightforward but crucial: ensure that only the user who subscribed to a webhook can access and modify that particular subscription. Always verify a user's permissions before allowing them to trigger any webhook actions. This prevents unauthorized access and protects the integrity of your system.

By following these guidelines, you'll be well on your way to maintaining secure and reliable webhooks. Remember, web security is an ongoing process, and staying informed about the latest best practices is key to keeping your systems safe.

Cheers to secure development!

Coding journey.

Angela Choi — Fri, 14 May 2021 02:41:22 +0000

2020
In 2020, one of my many New Year's resolutions was to learn to code. Of course, I waited until the last minute to try to accomplish this goal. At the end of October 2020, I began my first Web Development course to learn HTML and CSS online. This was my first time learning how to code. As a visual learner, I was particularly drawn to CSS and its capabilities. I love that I can immediately see my changes and there are a plethora of color options :) While taking this course, I was commuting to work as a teacher in NYC and would code before or after work on the subway. I found it therapeutic. It was my escape from reality. I felt like I was disappearing into a different world to solve problems (AKA trying to master all of CSS properties). I slowly began to fall in love with coding. I loved that I could create something powerful and impactful with code and wanted to learn more.

2021
In February 2021, I was accepted into General Assembly's Software Engineering Immersive Flex program. It's a 6-month part-time program. For me, this program allows me to keep my job while I learn to code. I also like that it is a bit slower pace so that I have time to process the information.

Reasons why I decided to delve deeper into programming:

1.⌚Time
Every year I've been telling myself that I want to code. Now, that I am working from home I have the flexibility and time to learn.

2.🛠️ Going outside of my comfort zone skills
I am a pro at soft skills. However, I need to strengthen my technical and analytical skills. Coding allows me to utilize different skills I normally don't get to practice such as technical, analytical, and being extra detail-oriented.

3.🐱‍💻Be a student and understand how it's like to learn online
As a teacher, I know what it's like to teach online, but I don't know what it's like to be in my students' position- to be taught online. Now, I have a better understanding of how my students learn online.

4.❤️📗Create impactful and useful projects related to education to help students, teachers, or both
With my new technical skills, I want to help improve the education system and creating an equitable user experience for all learners.

5.😃For fun
For me, coding is fun and enjoyable. I like that there are various ways to solving a problem, just like a math problem. I've been treating coding like a hobby/sport it's fun to practice and the more I practice the more I get to level up and discover more things along the way.

With that, this is the beginning phase of my coding journey and I'll be documenting as much as I can.