The last few months have mostly been spent building Profilis, a lightweight observability tool for Python services. v1.0.0 is now out, and it proved a few important ideas:

• Event creation should be extremely cheap.

• Observability should never block the request path.

• Instrumentation should remain framework agnostic.

In other words, observability should behave like infrastructure, not an experiment.

But shipping the first version also surfaced new questions.

The architecture works, but several parts of the system still feel… fluid:

• the event schema is flexible but not formally defined

• the collector works well in a single process but multiworker deployments need clearer guidance

• exporters are powerful, but pipelines are implicit

So before jumping into features, I started thinking about Profilis v2 in a slightly different way.

Instead of designing features, I started asking a sequence of architectural questions.

The Current Architecture

At its core, Profilis is a small telemetry pipeline.

Instrumentation produces events.
Those events are buffered asynchronously.
Then exporters consume batches.

The design goal is simple:

Keep the hot path extremely cheap.

Instrumentation emits small dictionary events, which the collector batches and forwards to exporters on a background thread.

This keeps observability from interfering with request latency.

But the current version also left several design questions open.

Should Profilis Have a Stable Event Schema?

Right now events are simple dictionaries.

Example:

{
  “kind”: “HTTP”,
  “method”: “GET”,
  “route”: “/orders”,
  “dur_ns”: 148200,
  “status”: 200
}

This flexibility made development easy. Adapters could evolve quickly without worrying about strict schemas.

But over time this becomes risky.

Exporters need predictable fields.

Event evolution becomes implicit.

Backward compatibility becomes unclear.

So the first question is straightforward:

Should events have a versioned schema?

And I can think of two possible scenarios here

1. Keep Flexible Dict Events

Pros:

• adapters remain simple

• schema evolution stays flexible

Cons:

• exporters must tolerate schema drift

• compatibility guarantees remain unclear

2. Introduce a Versioned Schema

Events could include explicit metadata:

{
  “schema_version”: “2.0”,
  “profilis_version”: “2.x”,
  ...
}

This allows exporters and processors to rely on a stable contract.

The likely direction for v2 is a versioned schema, while still keeping plain dictionaries on the wire for performance.

Internally, typed contracts (TypedDict) can enforce structure without slowing down emission.

Should the Collector Become Async?

Modern Python frameworks are increasingly async first.

That raises an obvious question.

Should AsyncCollector actually become an asyncio task?

A hypothetical async collector might look like this:

async def collector():
    while True:
        batch = await queue.get()
        await exporter.send(batch)

At first glance this feels natural.

But there’s a subtle problem.

Profilis deliberately keeps the telemetry process separate from the application runtime.

If the collector depends on the application event loop:

• event loop congestion could affect telemetry

• exporters could interfere with request scheduling

• instrumentation behavior becomes framework dependent

The current implementation avoids this entirely by using a dedicated worker thread.

So the design question becomes:

For now, the threaded collector remains the safer option.

It keeps the observability pipeline independent of whether the application is:

• synchronous

• asynchronous

• or a hybrid stack.

How Should Profilis Work Across Workers?

Single process applications are easy.

But production deployments often look like this:

Each worker runs its own collector.

This works, but it fragments telemetry.

So v2 raises an important design question:

Should collectors remain process local, or should workers forward events to a shared pipeline?

Possible directions I can think of from here:

1. Per Worker Pipelines

Each worker exports its own telemetry.

Pros:

• simplest architecture

• no inter process communication

Cons:

• fragmented aggregation

2. Shared Collector Process

Workers forward events to a central collector.

Possible transports:

• Unix sockets

• UDP

• shared queues

Pros:

• centralized processing

• unified exporters

Cons:

• increased complexity

• potential bottlenecks

The likely direction would be optional shared collectors, while keeping the default architecture simple.

Should Pipelines Become Explicit?

In v1 the collector sends batches directly to sinks.

But real telemetry pipelines often require intermediate processing:

• metadata enrichment

• route normalization

• PII redaction

• sampling adjustments

So another question emerges.

Should Profilis introduce a processing stage?

Processors could add functionality without complicating exporters.

But the key constraint remains performance.

If processors become expensive, they defeat the purpose of the architecture.

So if v2 introduces processors, they must remain extremely lightweight.

Should Profilis Integrate with OpenTelemetry?

OpenTelemetry has effectively become the default observability ecosystem.

That raises another design question.

Should Profilis become a wrapper around OpenTelemetry?

Two directions are possible.

1. Native OpenTelemetry

Profilis emits spans through OpenTelemetry APIs.

Pros:

• ecosystem compatibility

• existing exporters

Cons:

• larger runtime footprint

• reduced control over performance

2. Lightweight Bridge

Profilis keeps its own pipeline but:

• reads OTEL trace context

• exports events via OTLP

Pros:

• interoperability

• minimal dependencies

The second approach seems more aligned with Profilis’ goals.

Interoperate with the ecosystem, but remain lightweight.

Should Profilis Become a Storage System?

Another question surfaced while building the UI.

Should Profilis persist telemetry data?

Possible storage engines could include:

• SQLite

• DuckDB

• ClickHouse

That would enable powerful analysis features.

But it would also fundamentally change the scope of the project.

Profilis currently treats exporters as pluggable sinks.

This keeps the core system focused on capturing and transporting telemetry.

The likely direction for v2 is to keep Profilis as a pipeline, not a database.

Storage should remain the responsibility of exporters.

A Pattern Emerges

Looking across these decisions, a pattern starts to emerge.

Profilis consistently optimizes for three things.

Hot Path Safety

Instrumentation must remain extremely cheap.

Operational Safety

The observability system should never endanger application stability.

Architectural Simplicity

The pipeline should remain small enough to reason about.

Every potential feature is evaluated against these constraints.

Not because complexity is bad.

But because complexity in observability systems often shows up at the worst possible time, when production is already on fire.

What Comes Next

Profilis v1 proved the architecture works.

v2 is about making that architecture more predictable, operable, and extensible without sacrificing the core principle:

Observability should be cheap enough to leave on.

The next few months will likely involve experimenting with some of these ideas in the open.

Some will make it into next version. Some probably won’t.

That’s part of the process.

But till then you can checkout the latest version on github. Or try,

pip install profilis

If you have come this far, would love to hear your thoughts, ideas or suggestions on this article.

Website | GitHub | LinkedIn | Signals & Noise

Most people make serious commitments to their life on January 1.

New year. New plan. New discipline.
Same outcome.

I used to do that too, plan long term, feel motivated for a while, then slowly drift as life changed. And life always changes. New responsibilities. Health issues. Work pressure. Family. Fatigue. Reality.

At some point, it became obvious: waiting for a perfect start date is just procrastination with better branding.

So I stopped waiting.

The Lie of Long Term Planning

The biggest problem with long term planning isn’t lack of ambition.
It’s the assumption that the future will stay stable.

People plan five years ahead as if:

• Their energy will remain constant

• Their priorities won’t shift

• Life won’t interfere

That’s fantasy.

Instead, I capped my planning horizon to one year. Anything beyond that is direction, not a plan. The real work happens closer to the present.

Here’s how I operate now:

• Vision: 1 year

• Planning: Monthly

• Execution: Daily

• Feedback: Weekly

• Recalibration: Monthly

Change isn’t treated as failure.
Change is expected and engineered.

From Goals to Systems (Life OS)

I stopped planning goals and started operating my life like a system.

This became my Life OS.

The core shift was simple but uncomfortable:
I moved from task based planning to time based execution.

Tasks lie. Time doesn’t.

Tasks depend on motivation.
Time depends on structure.

When the day is full, nothing new gets added without removing something else. That single constraint kills most fake productivity.

My calendar now enforces my priorities. Not my mood.

This is the system I’m running my life on right now.

Direction stays stable. Execution stays small. Feedback is frequent. Change is intentional.

Daily Execution Is Time Based, Not Emotional

Execution happens in fixed time blocks.
Not because I feel like it.
Not because I’m inspired.

But because the block exists.

This matters because motivation is unreliable. Structure isn’t.

Some days I execute fully.
Some days I barely scrape through.

Both days count.

Energy Is Not Constant, So the System Can’t Be Fragile

One of the biggest realizations in the last three weeks was this:
Energy comes in phases.

Any long term plan moves through:

• High energy (happy) phases

• Low energy (unhappy) phases

• Mixed, messy middle phases

Most systems are designed only for happy days.
That’s why they collapse.

I started thinking in simple paths:

• Happy path: full execution feels easy

• Unhappy path: bare minimum, protect the streak

• Mixed path: partial execution, no guilt

The rule is brutal and simple:

Showing up beats doing it perfectly.

Life doesn’t care about my plans.
So my system had to work even on bad days.

On low energy days, I don’t renegotiate my life.
I shrink the effort, not abandon the system.

The block never disappears. Only the expectation changes.

Weekly Scores and Monthly Recalibration

Every week, I give myself a score.

Not based on feelings.
Based on behavior.

Did I show up to the blocks?
Where did I break the system?
What pattern caused it?

A low score doesn’t trigger self hate.
It triggers investigation.

Monthly, I recalibrate:

• Drop what’s unrealistic

• Narrow what’s bloated

• Postpone without guilt

This is the part most people avoid, because it forces honesty.

Why I Don’t Wait for The Right Time Anymore

I stopped waiting for the perfect day to start.

Start today, and when that perfect day finally comes, you’ll already be far ahead.

I picked this up from Kunal Kapoor during an event:
Opportunity looks like luck only when preparation is invisible.

Life throws opportunities anyway.
Most people just aren’t ready when they arrive.

So the rule now is simple:

Don’t waste time. Do the work.

This Isn’t New, It’s Finally Internalized

I’ve tried versions of this before.
The difference now is internalization.

It’s not a productivity experiment anymore.
It’s habit formation.

Cue → Action → Reward.
Repeat. (I picked it from Atomic Habits).

Will it work perfectly forever? Probably not.
But what’s the harm in doing something pragmatic instead of endlessly planning?

There Is No Finish Line

There’s no winner spot.

There’s only one real question:

• Am I better than I was a year ago?

• Did I accomplish most of what mattered?

• Am I moving in the right direction?

That’s it.

If the answer keeps improving year after year, the system is working.

And if someone still wants to wait for January 1 after reading this, that’s not ignorance anymore.

That’s a choice.

Every time I start a new side project, I promise myself I won’t reinvent the wheel. Yet here I am, shipping Profilis, a modern profiling library for Python web apps.

Now, before you roll your eyes and say, “But don’t we already have cProfile, PyInstrument, py-spy …?” You’re absolutely right. We do. They’re great tools, powerful in their own right. But if you’ve ever tried plugging them into a real world project that isn’t a toy script, you probably know the friction:

• Some are CLI first, harder to integrate in app.

• Some add a bit too much overhead.

• Some make sense only if you’re profiling one off runs, not continuous monitoring.

• And almost all of them feel heavy when all you want is a quick, no nonsense snapshot of what’s eating up time.

That itch, that gap between too simple and too heavyweight, is why I built Profilis.

What I Learnt While Building It

I’ll be honest: building Profilis wasn’t about replacing the giants. It was about learning by doing. And it taught me a few things worth sharing:

0. Simplicity > Magic
   Developers don’t want black boxes. We want to know exactly what’s being measured and how. Profilis is intentionally minimal: a decorator, a context manager, a StatsStore. No hidden side effects.

1. APIs Should Feel Native
   I obsessed over making usage Pythonic. A single import, a single line of code, and you’re profiling. If I had to look up docs every time, I failed.

from profilis.decorators.profile import profile_function

@profile_function(emitter)
def expensive_calculation(n: int) -> int:
    """This function will be automatically profiled."""
    result = sum(i * i for i in range(n))
    return result

2. Visibility Matters
   Profiling isn’t useful if it stays in logs. That’s why Profilis ships with a tiny JSON + HTML dashboard baked into Flask. You get a view of KPIs and bottlenecks at a glance right in your browser.

3. Constraints Are a Gift
   By forcing myself to ship a 0.1.0 MVP, I avoided rabbit holes. No over engineering. Just enough to prove value.

Why It Helps the Dev Community

Profilis isn’t here to “win” against cProfile or py-spy. It’s here to serve a specific slice of developers:

• Builders who want quick performance insights inside their app.

• Teams who prefer lightweight instrumentation without extra dependencies.

• Learners who want to peek under the hood of how profilers work.

By keeping it simple and pluggable, my hope is that Profilis lowers the barrier to actually caring about performance. Because let’s be real, most of us only reach for profilers when things are already on fire. What if instead, it was easy enough to profile continuously, like logging?

What’s Next

This is just the start. v0.1.0 ships with the basics including decorators, context managers, stats collection, and a dashboard. The roadmap includes:

• Richer visualizations and charts

• More granular insights (per function, per route, DB calls)

• Including support for popular databases

• Integrations with modern monitoring stacks

And of course, community feedback will shape where it goes.

Closing Thoughts

I didn’t build Profilis to compete. I built it to learn, to scratch an itch, and hopefully to make performance profiling a little less scary for the next developer who just wants to know what’s slow.

If that sounds like you, give it a spin:

pip install profilis

Would love to hear your thoughts, feedback, and ideas.

Website | GitHub | LinkedIn | Signals & Noise

Some weeks, I feel like I’m in motion constantly planning, designing, coding, writing, mapping out ideas and still end the week unsure what I actually finished.

It's not burnout.
It’s saturation.

Not because I'm lost. I know what I care about.
But when everything feels important, focus becomes a luxury.

The pattern I keep seeing in myself

I’ve always been someone who can juggle multiple domains engineering, product, design, content, even business models. I like building things end to end.

But over time, that strength turned into noise.

I’d start writing a blog series.
Midway, I’d sketch out a new product.
Then context switch into interview prep.
Follow that with a deck for a freelance pitch.
And somewhere in between, planning for future and design a personal finance app.

It wasn’t the workload that wore me down, it was the number of open loops.

This isn't about motivation

I’m not struggling to get started. I’m struggling to choose.

And that’s harder in some ways. Because when you're capable of doing many things, choosing one feels like closing doors you know you could open later.

But that’s the trap.

Everything can’t be a priority.
Everything can’t matter equally.
And just because I can build it, doesn’t mean I should, right ?

The illusion of momentum

When you're good at thinking across contexts, you start mistaking motion for progress. I did.

I could make progress on 5 different things every week, but none of them felt like they were compounding.
I was building sideways, not forward.

It got to a point where I had to pause and ask:

What am I actually moving forward?

I didn’t like how long it took to answer.

So I made one decision

Not a productivity hack. Not a new app. Just a call.

For this stretch, I’m choosing depth over variety.

That means fewer moving parts.
Not because the other ideas aren’t worth doing, but because trying to do them all at once is the reason they aren’t moving.

So right now, I’m focused on rebuilding my technical edge through structured prep, focused problem solving, and some personal technical writing.

Not to get a job or be relevant. Just to clear mental space, sharpen execution, and rebuild momentum on my own terms.

My system now is simple

Google sheet with three columns:

• Now: top priorities for this cycle

• Next: queued up, but not urgent

• Later: I still care, but they can wait

And I work in 6 day cycles.
Each cycle gets three things.
That’s it.

No overthinking. No guilt for what’s paused.

What I’ve learned so far

You don’t need to do everything right now.
You need to do something clearly.

Letting go of that internal pressure, to act on every idea the moment it shows up, is a skill I’m still learning. But every time I do it, I get a little more energy back.

What’s changed since

I’ve started finishing things again.
Small things. Focused things. But they’re shipping.
And that feeling of closing loops instead of creating new ones is underrated.

It’s also the only way I’ll ever get the big things out into the world.

If you're wired like me

If you’re someone who can see too much, too fast, you’re not broken.
You’re just saturated.

And clarity isn’t going to come from journaling or buying another productivity app.
It comes from making a call.

What’s the one thing that, if done, would make the rest easier?

Pick that.
Let the others wait.

Not forever.
Just for now.

I’ve seen it more than once, people with range. Folks who can lead, design, ship, scale, mentor, even navigate product and GTM discussions. People who can do the work of three, but are asked to fill just one box on the org chart.

At first, they over deliver. Then they start asking for more impact, more trust, more learning. If nothing changes, they slow down. They stop volunteering ideas. They quietly detach. And eventually, they leave.

This isn’t about one company. It’s a pattern. High performers who aren't challenged, trusted, or grown will always move on, even when compensation is “okay” and the culture looks fine on paper.

Why It Happens

It’s easy to assume people quit because they got a better offer or weren’t a culture fit. But often, it’s subtler than that:

• They’re capable of more. But no one’s paying attention.

• They want to grow. But the work doesn’t stretch them.

• They seek trust. But they’re still being second guessed.

• They want to make an impact. But they’re stuck in a delivery treadmill.

These aren't complaints, they’re early signals. And if no one is listening, even your most committed team members will eventually start to check out.

What You Might Not Notice

High performers don’t always say, “I’m unhappy.” They just:

• Stop raising their hand for hard things

• Avoid long term ownership

• Show up, do the job, log off

• Smile in meetings but go quiet in 1:1s

• Keep hitting goals but the spark’s gone

That’s the quiet quitting phase. The exit is just a formality.

Why They Leave

It’s rarely one thing that makes high performers leave. More often, it’s a slow accumulation, burnout that goes unnoticed, health taking a hit from unsustainable pace, trust quietly eroding, and a growing feeling that they’re not learning anything new.

They’re not unhappy all the time. But they’re not growing either. Not challenged, not stretched, not seen. And that’s when disengagement sets in.

The scariest part? They don’t always leave with a complaint or conflict. Most often, they leave quietly.

What Leaders Can Do Differently

This isn’t fixed by motivational talks or a Friday fun event. It’s about systemic action. Here's where it starts:

0. Create Space for Stretch

Let them try things beyond their role. Assign ownership of new, ambiguous problems. Let them fail and learn.

1. Talk About Growth, Not Just Goals

Not just “What are you delivering?” but “What are you excited to learn?”
Build the roadmap around that too.

2. Audit Their Utilization Honestly

If someone can work across frontend, backend, infra, ML and you’re only giving them UI tickets, that’s a design flaw, not a resource issue.

3. Don't Wait for Feedback Loops

By the time someone says they’re not learning, the damage is already done. Use regular checkins to ask about challenge, energy, and growth, not just timelines and blockers.

4. Trust Out Loud

Trust isn't just delegation. It's telling them you believe in them, backing them publicly, and getting out of the way.

Before I wrap up

Sometimes, the people who leave are the ones who wanted to stay the most. They brought energy, took ownership, and gave their best, but somewhere along the way, the system didn’t evolve to meet their growth.

If you’re in a position to design orgs, shape culture, or retain talent, don’t just focus on who's underperforming. Pay attention to your silent overachievers too.

Because when they leave, it won’t be loud. It’ll be clean, calm, and quiet. And by the time you notice, it’ll already be too late.

In 2023, I hit one of the lowest points of my life.

It wasn’t triggered by a toxic boss or an overwhelming deadline. It wasn’t because someone pushed me too hard.
I did it to myself. I worked like hell, not because I had to, but because I loved doing it. I poured myself into work, into code, into problems I couldn’t stop thinking about. It gave me purpose. It made me feel alive.

Until one day, it didn’t.

The Downfall I Didn’t See Coming

At first, it was just fatigue. I thought I was just tired, a few days of rest and I’d bounce back.
But the tiredness lingered. My mind stopped working the way it used to. I began feeling anxious for no reason. My sleep went for a toss. I couldn’t focus, couldn’t think straight.
And then something even worse happened: I stopped feeling like myself.

The very thing that brought me joy… coding, building, solving, became unbearable. I couldn’t even look at my laptop. I didn’t want to. I physically couldn’t bring myself to open it.

Life felt empty. The world around me felt disconnected. Everything I once enjoyed became… dull.
And then came the thoughts, the fear that something terrible was going to happen.
I remember waking up with a tight chest and a heavy heart, unsure if I’d even want to get through the day. Touchwood, that was a dark phase.

The World Didn’t Get It

The worst part? Very few understood.

When you break your leg, people see it. When you burn out, it’s invisible. And when you’re someone who’s always been driven and high-performing, it’s even harder for people to believe something’s wrong.

Some thought I was just slacking. Some thought I was overreacting.
But burnout isn’t “in your head.” It’s real. It crushes your confidence, wrecks your routines, and flips your personality inside out.

I wasn’t lazy. I wasn’t weak. I was broken, quietly, deeply, and completely.

The Slow Road to Recovery

Getting out of that state wasn’t easy.
It didn’t happen in a week or a month. It took over a year to fully recover. And honestly, it didn’t come from a therapist or a miracle cure. It came from slowly, painfully, reconnecting with life.

Here’s what helped me:

• Meditation - just sitting with myself, quietly, without pressure.

• Walking and light running - moving my body when my mind refused to move.

• Watching movies and traveling - things I stopped doing in the name of work.

• Talking to friends - people who didn’t need to understand fully, just stayed present.

• Reading books - slowly reigniting curiosity again.

• Acceptance - this was the biggest one.
  That it’s okay to be where I am. That I don’t need to be “fixed.” That it’s okay to slow down, to fall apart, and to take my time rebuilding.

These sound simple, but they saved me. They gave me breath again. One day at a time, they helped me come back, not to who I was, but to someone more grounded.

What Burnout Taught Me

It taught me what’s actually important in life, and what’s not.
It taught me that rest is productive. That doing something slowly doesn’t mean doing it badly. That I’m not my output. That success doesn’t mean sprinting all the time.

It also taught me empathy. Now when I see someone zoned out, detached, or unmotivated, I don’t judge. I wonder what they’re going through underneath. Because I know how hard it is to function when you’re burning inside.

And I’ve learned to protect myself better now, with boundaries, balance, and space. The grind will always be there. But I won’t, if I keep ignoring my limits.

To Those Going Through It Right Now

If you’re going through something similar, I want you to know this:

You’re not alone.
You’re not broken.
And you won’t feel like this forever.

Burnout is real. It’s valid. It doesn’t make you any less smart, talented, or worthy.
You don’t have to bounce back immediately. You don’t have to pretend you’re okay. You just need to start small, breathe, rest, walk, talk, cry if you need to. It’s okay.

You’ll come back. Maybe not as the old you. Maybe as someone stronger, slower, wiser, kinder.

The Part That’s Rarely Spoken About

Burnout in tech, especially among people who love what they do, is under-discussed.
We celebrate sleepless nights, late pushes, and always being “on.” But we don’t talk enough about what happens when that fire turns into a flameout.

Burnout isn’t a badge of honor. It’s a warning sign.
Let’s stop pretending it’s not real. Let’s talk about it. Let’s support each other through it.

Because no amount of success is worth losing yourself.

Take care of yourself. The world can wait.
And if you're in that phase right now, I see you. You’ll find your way back.
You already took the hardest step: acknowledging it.

Getting onboarded onto a new project is always an interesting phase, new challenges, a different team dynamic, and the opportunity to create impact. But sometimes, the unexpected hits you in ways you didn’t quite anticipate.

Recently, I got assigned to a project from a reputed client. Given their stature, I expected a level of professionalism, clear ownership, and structured collaboration. Turns out, I was wrong.

The Reality Check

From day one, the client made it clear this wasn’t going to be smooth sailing. Instead of constructive discussions, we got belittling remarks for minor things. Instead of shared responsibility, we saw a blame game. And instead of professionalism, we got a frustrating mix of arrogance and unaccountability.

It’s one thing to have a demanding client pressure is part of the job. But when that pressure turns into toxic interactions, it starts impacting morale and efficiency.

How to handle a rude client … without losing your mind :)

If you ever find yourself dealing with a client who is more of a problem than a partner, here’s what has helped me navigate the situation:

0. Don’t take it personally

The first instinct when someone disrespects you is to react emotionally. But stepping back and treating it as a professional challenge rather than a personal attack helps in keeping your composure. Most of the time, their attitude has nothing to do with you and everything to do with their own stress, ego, or insecurities.

1. Stay professional, no matter what

You can’t control how they act, but you can control how you respond. Keeping your communication crisp, professional, and objective prevents the situation from escalating. Sometimes, the best way to handle rudeness is to not give it the reaction it seeks.

2. Document everything

When dealing with a client who shifts blame, documentation is your best friend. Every decision, discussion, or agreement put it in writing. Emails, meeting notes, and task trackers help ensure that when accountability comes into question, the facts are on your side.

3. Set boundaries on communication

Some clients don’t respect work life balance or the effort teams put in. It’s important to set clear expectations on communication what’s acceptable, what isn’t, and what will not be tolerated. If a client is rude in calls, subtly redirect them to email, where their words will be recorded.

4. Escalate if needed

If the situation gets out of hand, if the client’s behaviour is affecting the team’s productivity or well being, it’s worth raising the issue with leadership. They likely have experience handling difficult clients and can step in if necessary. Some clients need that pushback to realize they can’t treat teams like that.

Lessons Learned

Difficult clients exist in every industry, but how we deal with them defines our professional growth. Some clients will always be challenging, but staying professional, setting boundaries, and focusing on the work (rather than their attitude) is often the best approach.

At the end of the day, you can’t control their behaviour, but you can control how much it affects you. And sometimes, that’s enough to turn a frustrating experience into a learning one.