DEV Community: kate astrid

The Wrong Question: Why Blameless Culture Builds Better Engineering Teams

kate astrid — Wed, 20 May 2026 10:15:58 +0000

The case for blameless culture — not as a feel-good HR initiative, but as a practical operating principle for teams building systems too complex for any one person to fully understand.

It’s 2:47am.

Production is down.

A deploy went out an hour ago, the on-call engineer is staring at a graph that fell off a cliff, and somewhere in a Slack channel someone is typing the question that quietly poisons engineering organizations:

“Who pushed this?”

It feels like a reasonable question.

Something broke. Someone did it. Find them, talk to them, make sure it doesn’t happen again. Clean, logical, satisfying.

It’s also almost always the wrong question.

The teams that figure this out tend to:

ship faster,
recover quicker,
learn more effectively,
and retain their best engineers longer.

The teams that don’t keep repeating the same classes of incidents while wondering why “people keep making mistakes.”

What Blameless Culture Actually Means

There’s a common misconception that “blameless” means “no accountability.”

It doesn’t.

Blameless culture isn’t the absence of responsibility — it’s the redirection of attention.

A blameless team still cares deeply about:

understanding what went wrong,
identifying who was involved and what decisions they made,
holding people responsible for follow-through on fixes,
and maintaining a high quality bar.

What it stops treating as useful is punishment as the primary mechanism for improvement.

The premise is simple:

In a sufficiently complex system, the question “who caused this?” almost always resolves to “a competent engineer doing reasonable work in a context that made the bad outcome easier than the good one.”

The outage, the data loss, the bad deploy — these are usually the visible tip of a much larger iceberg:

missing guardrails,
unclear ownership,
undocumented assumptions,
brittle tooling,
or processes that quietly invite mistakes.

Punish the engineer at the tip, and the iceberg remains.

Why Blame Feels Right (And Why That’s a Trap)

Blame is psychologically satisfying for the same reason scapegoating has existed in every human culture for thousands of years:

it provides closure.

Something bad happened.

We identified the cause.

We addressed it.

We move on.

The problem is that blame as an organizational instinct has predictable failure modes.

1. It Teaches People to Hide Things

The fastest way to ensure you never hear about the near-miss is to punish people for the misses.

Engineers learn quickly.

If reporting mistakes costs them socially or professionally, they’ll route around the reporting.

Incidents become sanitized.

Near-misses disappear.

The organization slowly loses its ability to see itself clearly.

2. It Optimizes for the Wrong Outcome

Blame focuses on the last person who touched the system.

But the last person to touch the system is rarely where the leverage is.

The leverage is usually in:

the deploy process that allowed the change,
the test suite that didn’t catch it,
the review process that waved it through,
or the documentation that failed to explain a constraint.

Punishing the engineer doesn’t improve any of those.

3. It Selects Against the People You Most Want to Keep

Senior engineers who can work anywhere tend to leave organizations where incidents become career events.

The engineers who stay often become more risk-averse.

Which means:

fewer ambitious changes,
slower iteration,
more defensive engineering,
and less ownership of ambiguous work.

You end up with a team optimized for self-preservation rather than impact.

4. It Misunderstands How Complex Systems Fail

Human factors researchers like Sidney Dekker and James Reason have spent decades documenting this:

In complex systems, failures are almost never caused by a single bad actor.

They emerge from the unlucky alignment of many individually reasonable decisions.

Blame assumes a simple causal chain. Real incidents almost never have one.

What Changes When Blame Leaves the Room

Teams that genuinely commit to blamelessness — not just as a slogan, but as a discipline — tend to see a set of compounding changes.

Postmortems Become Useful

When the document isn’t a trial, it can be honest.

Engineers describe:

what they actually thought,
what they actually tried,
what they misunderstood,
and where their mental model diverged from reality.

That’s the raw material organizations need to improve.

A defensive postmortem teaches you nothing. An honest one teaches you everything.

Near-Misses Get Reported

This is one of the highest-leverage effects.

For every outage that happens, there are usually many more that almost happened.

Caught at the last second. Or mitigated in staging. Or rolled back before users noticed.

In a blame culture, those incidents disappear. In a blameless culture, they become cheap learning opportunities.

Incident Response Gets Faster

When engineers aren’t worried about implicating themselves, they share information faster.

The unspoken fear of:

“Will this make me look bad?”

slows down active incident response more than most organizations realize.

Removing that fear speeds teams up.

Junior Engineers Ramp Faster

The cost of being wrong strongly determines how quickly junior engineers grow.

In blame-heavy environments, juniors learn to:

defer,
ask permission constantly,
avoid ownership,
and stay inside safe boundaries.

In blameless environments, they learn to:

take swings,
recover,
communicate clearly,
and build judgment.

Systemic Fixes Actually Get Built

When conversations move from:

“Be more careful.”

to:

“What would make this class of mistake impossible?”

teams start investing in compounding improvements:

better tests,
safer deploy tooling,
stronger defaults,
clearer ownership,
and more visible operational signals.

Each fix removes an entire category of future incidents.

What Blameless Culture Is Not

Blamelessness gets misused often enough that it’s worth being explicit about the boundaries.

It’s Not Consequence-Free

If an engineer repeatedly ignores process, cuts corners, or refuses feedback, that’s a performance issue.

Blameless culture doesn’t mean ignoring patterns.

It means not treating a single incident as evidence of bad character.

It’s Not the Absence of Standards

Some of the most rigorous engineering organizations in the world are also deeply blameless.

The quality bar is still high.

The difference is that standards are enforced through systems, not shame.

It’s Not “Everything Is the Company’s Fault”

There’s a lazy version of blamelessness that gestures vaguely at “the system” while removing all individual responsibility.

That’s not useful either.

Engineers still own their work.

The shift is in what happens after mistakes occur.

It’s Not Infinitely Patient With Repeated Mistakes

If the same person repeatedly makes the same category of mistake after systemic fixes are already in place, that’s a signal.

Blamelessness is a default posture for learning.

Not permanent immunity.

How To Actually Do It

Cultural change is mostly invisible work.

But there are a few practices that consistently distinguish teams that live this from teams that merely say it.

Write Postmortems in the Second-Person Plural

Instead of:

“Alex deployed a bad change.”

write:

“We deployed a change that…”

The information content is the same, but the framing changes everything: one treats an individual as the defendant, the other treats the team as the system.

Ask “How?” Before “Who?”

Compare:

“Who reviewed this?”

vs.

“How did this make it through review?”

The first surfaces a person, the second surfaces a process gap.

One produces defensiveness, the other produces better systems.

Separate Incident Reviews From Performance Reviews

These should never happen in the same room, with the same incentives, on the same timeline.

The moment an incident review starts feeling like a performance evaluation, honesty collapses.

Reward Engineers Who Surface Their Own Mistakes

This is one of the strongest cultural signals leadership can send.

The engineer who says:

“I deployed something I shouldn’t have. Here’s what I learned.”

should be visibly appreciated for transparency.

The behavior organizations reward becomes the behavior they get.

Fix the System, Every Time

Every postmortem should produce at least one concrete change:

a test,
a guardrail,
a tooling improvement,
a documentation fix,
or a process adjustment.

If the only takeaway is:

“Be more careful.”

then nothing meaningful was learned.

“Be more careful” is the null result of incident analysis.

Make Leaders Go First

Culture is set by what senior people do, not what they say.

The first time a VP, tech lead, or founder publicly owns a mistake and frames it as a learning opportunity, the organization recalibrates.

The first time they punish someone for an honest mistake, it recalibrates in the opposite direction.

The Deeper Point

There’s a version of this argument that’s purely pragmatic:

blameless cultures recover faster,
incidents become learning opportunities,
teams ship more confidently,
and organizations retain stronger engineers.

All of that is true.

But the deeper point is this:

Modern software systems are too complex for any one person to fully understand.

Teams of dozens or hundreds of engineers build:

distributed systems,
continuously deployed infrastructure,
services with millions of users,
and architectures evolving faster than any individual can mentally model.

In that environment, the question:

“Who is responsible for this failure?”

is usually less useful than:

“What about our system made this failure possible, and what would make it impossible next time?”

Blame is a tool from a simpler world. One where individuals could meaningfully own the totality of an outcome.

That world no longer describes modern software engineering.

The teams that understand this — the ones that shift from punishment to learning, from defense to curiosity, from individuals to systems — are the ones that will build the best software over the next decade.

The rest will keep asking who pushed the bad commit. And they’ll keep wondering why the same kinds of incidents keep happening.

The best teams don't have fewer mistakes. They have better conversations about them.

How We Halved Our Playwright E2E Suite

kate astrid — Tue, 19 May 2026 09:37:01 +0000

Five patterns that took a slow, flaky Playwright suite down to fast and stable.

We had a Playwright E2E suite that had grown into a painful, flaky part of CI.

Dozens of login/logout cycles per file. Fixed waitForTimeout calls everywhere. Hundreds of UI clicks just to set up state before each assertion.

Every other run, something would fail. We'd retry, hope for green, and move on.

Eventually we paid the tax.

The Before / After

Metric	Before	After
Tests	95	88
Runtime (clean)	~37 min	~17 min
CI reliability	~50% flaky runs	Stable with normal retries

Across the broader suite, a similar pass:

dropped about a dozen low-value tests,
replaced one E2E test with a focused unit suite that runs in 1.2 seconds instead of 30,
and stripped fixed waits from the most-trafficked files.

Five patterns did most of the work.

Pattern 1: Programmatic Auth

With 40+ login/logout cycles in a file, that's two minutes of click ceremony before you've asserted anything useful.

Most modern auth setups support a programmatic path:

Sign in via the auth provider's REST endpoint.
Write the resulting token to localStorage (or wherever your client SDK reads from).
Skip the form entirely.

Mirror it for logout — clear the session storage and cookies, then navigate to /login.

That last navigation is the part I'd skip on first attempt and regret.

Without it, after clearing storage the page is still on /dashboard/something and the SPA detects "no session" and starts its own redirect to /login.

The next loginAs then races that redirect, and you get sporadic "navbar not visible" errors that look like flakes but are actually deterministic timing bugs.

Pattern 2: API-Driven Setup

This was the single biggest win for us.

Most of what tests do to set up state is already callable via REST — those endpoints exist because the app uses them.

There's no reason to drive the UI to:

add a user to a group,
configure a setting,
assign a role,
or seed fixtures

when you could just POST directly.

Before: six UI steps for setup:

await page.goto('/admin/groups');
await page.getByRole('row', { name: /Test Group/ }).click();
await page.getByRole('button', { name: 'Add Member' }).click();
await page.getByPlaceholder('Search users').fill(TEST_USER_EMAIL);
await page.getByRole('option', { name: TEST_USER_EMAIL }).click();
await page.getByRole('button', { name: 'Add' }).click();
// ... wait for it to persist, navigate back, etc.

After: one API call:

async function ensureUserInGroup(page: Page) {
  const headers = await getAuthHeaders(page);

  await page.request.post(
    `/api/groups/${GROUP_ID}/members/add`,
    {
      headers: {
        ...headers,
        'Content-Type': 'application/json',
      },
      data: {
        user_ids: [TEST_USER_ID],
      },
    }
  );
}

Test setup went from ~25–30 seconds to ~3 seconds.

The Tradeoff

API-based setup means a test can pass even if the UI setup flow itself is broken.

We accepted that tradeoff.

We kept dedicated tests for the setup flows themselves, and the rest of the suite became free to focus on the behavior it actually existed to verify.

The principle:

Exercise the UI for what you're actually testing.

A test asserting:

“The frontend hides button X for a viewer”

does not need to configure viewer permissions through the UI too.

Pattern 3: State Assertions, Not Fixed Waits

Hardcoded page.waitForTimeout(1500) calls were everywhere — usually under comments like:

// wait for it to commit

On a fast CI day, harmless.

On a slow CI day, flaky.

Instead of:

await page.waitForTimeout(1500);

assert on the actual signal:

await page.waitForSelector('[role="alert"][aria-label="Saved"]');

The result is:

faster on the happy path,
more reliable under load,
and easier to reason about.

Reach for expect.toPass() with a polled async block when the signal comes from another page or from eventual backend consistency.

Pattern 4: For “Was This Persisted?” — Ask the API, Not the DOM

This was the subtlest bug in the suite, and the one we learned the hard way after a CI regression we couldn't reproduce locally.

If your frontend uses an optimistic-update library like:

RTK Query
React Query
SWR

then the DOM can temporarily lie about persistence.

A row hidden by an optimistic delete looks identical to a row that was actually deleted — until the cache refetches in the background and the row pops back into existence.

A toHaveCount(0) assertion succeeds against the optimistic state, then the next assertion in the test finds the row again.

When you're asserting that persisted state changed, poll the backend until the change is actually committed:

await expect(async () => {
  const resp = await page.request.get(
    '/api/.../items',
    { headers }
  );

  const items = await resp.json();

  expect(
    items.some((i) => i.name === itemName)
  ).toBe(false);
}).toPass({
  timeout: 30000,
  intervals: [1000, 2000, 3000],
});

Same idea for permission revocation:

await expect(async () => {
  const resp = await page.request.get(
    '/api/.../resource',
    { headers }
  );

  expect(resp.status()).toBeGreaterThanOrEqual(400);
}).toPass({
  timeout: 90000,
});

The distinction matters:

The DOM answers:

“What is rendered right now?”

The API answers:

“Did this actually commit?”

Those are not always the same question.

Pattern 5: Audit for Redundancy

After the speedups, the suite was still larger than it needed to be.

On honest review, three categories of redundancy stood out.

Symmetric Mirror Tests

Examples:

“User has elevated role + base permission”
“User has base role + elevated permission”

What we see here:

Different setup states.
Identical observable assertions.
Same backend path.

One test covered the public contract sufficiently.

Cleanup Tests Duplicating Hooks

We had tests whose sole purpose was deleting leftover fixtures.

But the suite already had afterAll cleanup hooks with retry safety.

The cleanup “tests” added runtime, not coverage.

Generic Component Smoke Tests

Several tests asserted things like:

the list loads,
pagination works,
columns render.

But those shared components were already exercised by nearly every feature test in the suite.

The smoke tests weren't paying for themselves.

The audit removed roughly a third of tests with no meaningful coverage loss.

A useful question turned out to be:

“Is this test distinct?”

not merely:

“Does this test pass?”

What We Didn't Do

Some dead ends are worth documenting too.

Parallelizing Tests That Shared Accounts

Concurrent logins for the same backend user triggered session revocation cascades across contexts.

We reverted it.

Reusing Auth Sessions Across Browser Contexts

Several client SDKs rejected rehydrated sessions across multiple contexts.

Each loginAs() now performs a fresh REST sign-in.

The overhead (~200ms) was small enough that determinism mattered more.

Using Short Retry Budgets for Permission Assertions

Eventually consistent systems can take longer than expected, especially during deploys.

A 15-second retry window was not enough.

We replaced short retries with explicit API polling patterns.

Takeaways

If you're using the UI as a setup harness, you're paying twice.
Use APIs to create state and reserve the UI for the behavior you actually care about.
Replace waitForTimeout() with state assertions wherever possible.
Fixed waits are bets against your worst CI day.
For “was this persisted?” — ask the API, not the DOM.
The DOM can be optimistic, cached, or mid-render.
Programmatic auth compounds across every test.
The savings stack up quickly, and you eliminate subtle redirect races.
Audit your suite for true redundancy.
“All passing” is not the same as “all paying for themselves.”

There’s no silver bullet here — just a stack of small, principled changes that compound.

Fast E2E suites usually aren't the result of one big optimization.

They're the result of removing dozens of tiny sources of unnecessary work.

From Chaos to Clarity: Fixing Our Monorepo

kate astrid — Tue, 19 Aug 2025 11:45:37 +0000

Introduction: Why This Story Might Save You Some Headaches

If you’ve worked in a large codebase, you’ve probably seen this: the code runs, but every change takes far longer than it should. Updating one feature often breaks another. Adding a dependency means worrying about conflicts. Old build tools still linger, and no one feels safe upgrading packages that half the system depends on.

That’s exactly what we faced in our journey-monorepo, the main repository for our team. Dependencies were wired together in inconsistent ways, different teams had introduced multiple overlapping build tools, and some libraries hadn’t been touched in years. Proposing a cleanup felt like asking to redesign a city while people were still living in it — risky, disruptive, and easy to delay indefinitely.

So why did we bother?

Development had slowed to a crawl. Builds were taking too long, and waiting minutes just to see a change in the browser was killing productivity.
Every change felt risky. The dependency spaghetti meant a small tweak in one package could break multiple apps — often in ways we wouldn’t notice until much later.
Onboarding new developers was painful. It took too long for new team members to get up to speed, mostly because they had to learn multiple bundlers, testing setups, and outdated tooling quirks.
Technical debt was blocking new features. We were spending more time patching, debugging, and wrestling with the repo than building the actual features our users cared about.
Costs were adding up. Longer build times meant higher CI costs, and outdated packages made security updates and maintenance more expensive in the long run.

In short, the longer we waited, the more time, money, and momentum we were losing.

And, hey, now we get a good story out of it.

Journey-Monorepo in a Nutshell

Journey-monorepo is the central place on the epilot platform for everything related to journeys. What you see in the screenshot above represents two main apps: journey-app on the left side and journey-builder on the right. Journey-builder is responsible for configuring journeys, and journey-app for rendering them.
Like in many startups, the repo started out clean and well-structured, but as the product grew quickly, the codebase expanded in unplanned ways — things were added wherever they seemed to fit at the time.

The “BEFORE” Setup

Apps:
- journey-builder.               
- journey-app
- entity-mapping
- journey-view

Packages:
- blocks-configurators
- blocks-renderers
- journey-elements
- journey-utils
- journey-logics-common

Let me show you the rough map of dependencies we had step by step. We are interested in two main apps: journey-builder and journey-app, so I am going to dive deeper into their connections. It is not important which app or package does what. What IS important is to see how many connections we had to keep in mind every time we needed to change anything.

Ok, this is fine.
This is too.
Yeah, cool.
Packages already become tangled, let's keep going.
Ok, even more connections.
Well, this is just a delinquent madness.

You might say: Kate, come on, this is what happens in every big project - things become deeply intertwined, and it is a normal thing to experience.
I will answer: yes, but I haven't finished.

Let's now add the build tools to this table to have the full picture.

Well, what we have here:

Webpack;
Craco;
Tsup;
Tsx;
Tsdx.

I don't know about you, but I hadn't worked with half of them before I started working on this repo.

In the end, it was a web of “if you change this, you might break that” — and “that” could be anywhere.

How We Tackled It

We kicked things off with an RFC — basically, “let’s write this down so we don’t lose the plot halfway through.”
Our two big goals:

Unify the tooling so we weren’t juggling five different build setups.
Untangle dependencies so teams could work without stepping on each other’s toes.

And this is exactly what we did.

Step 1: Cut the Cord on Unnecessary Dependencies
The first thing we had to do was face the dependency jungle. Over time, different teams had introduced overlapping packages, and no one was quite sure what depended on what anymore. Cleaning this up gave us a chance to regain control.

Untangled all the apps and packages as much as possible. We mapped out how everything connected and then started cutting back the unnecessary links. This meant reducing cross-dependencies that caused fragile builds.
Moved blocks-configurators into journey-builder. These configurators were never meant to be used outside, so pulling them closer to where they belong simplified the dependency graph.
Moved blocks-renderers into journey-app. Renderers were core to the application itself, so consolidating them in the main app made the architecture more intuitive.
Deleted journey-utils and journey-elements. Journey-utils was a very small package with some utilities that were moved to other packages. And journey-elements _ were later replaced by _concorde-elements. You can read more about it in this article written by my partner in crime.

This was a painful step, but once the dust settled, the repo felt lighter and easier to reason about. We no longer had to worry about accidentally breaking other parts of the system when making small changes.

Step 2: Standardize the Tooling
After trimming the dependencies, the next big challenge was our tooling. Different parts of the repo used different build systems, which slowed everyone down and made onboarding new developers a headache.

Phased out Craco, Tsup, and Tsdx by switching to Vite. These older tools had been added over time, each solving a narrow need. Vite gave us a unified, modern setup with faster builds and simpler configuration.
Swapped Jest for Vitest — faster tests, modern setup. Jest had served us well, but it was slow and required custom patching to keep working. Vitest gave us near-instant feedback and worked seamlessly with Vite, making the dev experience far smoother.

By unifying the tooling, we not only sped up day-to-day work but also reduced cognitive load. Developers no longer had to remember which tool applied to which package — everything just worked the same way everywhere.

This is how the "AFTER" setup looks:

As you can see, the monorepo is now far more streamlined — there are significantly fewer dependencies crisscrossing between packages, and we’ve eliminated most of the variations in build tools. This makes the structure easier to understand, faster to work with, and much less fragile when changes are introduced.

After the Restructuring: What We Learned

When the dust settled, it wasn’t just that the dependency graph was cleaner — we were thinking about the repo differently.

Immediate Wins

Changing things stopped feeling dangerous. Before, touching a shared package felt like pulling a brick from a Jenga tower. Now, fewer connections mean less risk.
Builds and tests stopped feeling like a punishment. Vite’s dev server = instant feedback. Vitest shaved minutes off test runs. Devs started running tests more often just because they could.
Onboarding went from “ugh” to “okay.” New folks could get set up without learning the quirks of four bundlers first.

Slower Payoffs

- Tooling swaps aren’t magic. Some Webpack plugins didn’t have a Vite equivalent, so we had to rethink features or drop them.

- Vitest exposed bad tests. Some “passing” tests were only passing thanks to Jest’s quirks. Painful, but worth fixing.

Trade-Offs & Reality Checks

- Not everything got unified. A couple of apps still run on legacy setups because migrating them wasn’t worth the risk — for now.

- Shared packages need rules. We now ask “does this really need to be shared?” before creating new ones.

- Refactoring is never “done.” There is always room for improvement, we all know. that.

Tips If You’re Thinking About Doing This

Draw your dependency graph before you start — it’ll help convince others (and yourself) that the cleanup’s worth it.
Expect setbacks. Some PRs will break things. That’s normal.
Automate checks for unused or outdated packages — saves a ton of review time.
Celebrate small wins. Removing the last Webpack config deserved cake.

Final Thoughts

This wasn’t a quick tidy-up — it was a half-year-long deliberate overhaul alongside working on other features. But it’s made a massive difference to how we work: faster builds, fewer “don’t touch that” areas, and a general feeling that the repo is ours again, not a beast we’re afraid of.

If I had to wrap it all up in one bit of advice?

Keep it simple.

Every extra dependency, tool, or package you skip today is one less thing you’ll have to untangle in the future.

What To Expect When You Join Epilot

kate astrid — Mon, 03 Feb 2025 13:24:46 +0000

Hey you, awesome engineer.

Let's imagine that you are joining epilot tomorrow. Would you like to have a sneak peek at your nearest future?

Here’s a quick rundown of how we onboard new team members—no stiff formalities, just a clear path to help you settle in, understand our product, and get involved fast.

A Friendly Start
On the day one we’ll introduce you to your team lead and a dedicated onboarding buddy—think of them as your go-to guides for all things at epilot. Need pointers on our processes, product roadmap, or just want to figure out who to chat with about a certain topic? They’ve got you covered.

Your First Week

Get Set Up
We’ll make sure you have all the hardware, software, and accounts you need from day one. We’ll give you a handy checklist so you can get everything in place without the guesswork. Of course, your onboa buddy is always there to help you with everything.
Meet the Team
You’ll be given a chance to schedule 1:1 with every team member to get to know them better. Regardless of being remote-friendly company, we value real connections and friendly relationships, and make sure that everyone feels valued and supported.
Learn About Our Product and Users
We’re a high-touch SaaS company, and our product is complex and full of internal terms and abstractions. It might feel overwhelming in the beginning, but don't worry, we've got you. You will be given lots of resources like recordings of product demos and docs about different topics about epilot. No rush—just learn at your own pace and ask all the questions you have.
Get a Feel for Your Team’s Culture
Every team at epilot has its own rhythm and habits. Hop into Slack conversations, daily stand-ups, and team meetings to get a sense of what’s going on and how decisions get made. And feel free to share your ideas and suggestions - we are always eager to improve.
Start Contributing
We think the best way to learn is by doing. Early on, you’ll probably tackle a small assignment to get familiar with our systems and processes. Consider it your first real taste of epilot in action.

Getting to Know the Wider Company
Throughout your onboarding, you’ll also have chats with:

Founders: Hear the backstory behind epilot and our long-term vision.
Department Heads: Whether it’s Sales, Marketing, Engineering, or Product, each leader will fill you in on how their team supports our bigger goals. The idea is to see how all the pieces fit together and create the vibe.
Engineering & Product Leads: If you love diving into tech details, these sessions will give you insights into our architecture, tools, and future product plans.

Seeing the Product in Action
Our platform is built around microservices, but don’t worry if that’s new to you. We’ll walk you through the basics. We also encourage you to check out how our customers actually use epilot—like checking live customer feedbacks. It’s a great way to see what’s working and where we can improve.

The Balance Between Work and Collaboration
At epilot, we keep things productive but also supportive:

Team Events: You’ll get invites to company-wide announcements, product demos, company events, and more.
Open Communication: Slack, shared docs, and frequent check-ins mean you’ll never be left guessing.
Culture Matters: We appreciate everyone’s contribution, whether it’s project-related or just sharing something fun. We are the team, and this is what matters.

Looking Ahead
After a few weeks, you’ll have a good handle on how things work here—and you’ll know who to reach out to when you need help. We’ll likely ask for your thoughts on onboarding so we can keep improving the process for the future.

If this relaxed but purposeful approach resonates with you, we look forward to hearing from you. At epilot, we want every new hire to find their footing, make meaningful contributions, and grow in their role—without all the usual corporate fluff.

Happy to have you on board ✨.

Have you heard about the anterior midcingulate cortex?

kate astrid — Sun, 07 Jan 2024 20:45:07 +0000

The anterior midcingulate cortex (aMCC) is an amazing area in the human brain that plays a vital role in decision-making, emotional processing, and even pain perception. More interestingly, it acts as a crucial network hub for those tough cost/benefit calculations that fuel our perseverance, willpower, and tenacity.

Let's talk about facing challenges. Whether it's cracking complex equations or gearing up for a marathon, we all respond differently. Some might find the effort too overwhelming and step back, while others dig in their heels and push through without immediate rewards. This trait of persistence, increasingly spotlighted in research of the aCMM, correlates with better outcomes in health, academics, and career success.

Now, here's where it gets really cool: when programming, especially during those head-scratching moments that we might not particularly enjoy, our aMCC gets super active. Ever found yourself in a coding conundrum, feeling frustrated to the point of wanting to quit? That's your aMCC in action, getting stronger. It's akin to facing a steep climb while running; challenging, maybe not enjoyable, but incredibly effective in building mental strength and resilience.

So, remember, pushing through a tough coding problem does more than solve an issue on your screen. It's an aMCC workout, enhancing your brain's capacity to navigate complex tasks and manage emotions. It's a double win - improving your coding skills and boosting brain power, even when it feels tough at the moment =).

Nice to know, right?

Common Cognitive Biases That May Affect Us As Developers

kate astrid — Sat, 16 Sep 2023 10:38:14 +0000

As developers, we need to think straight to create solid, clean code. But hey, we're all human, and sometimes our brains make errors that can muddle up our decisions. Scientists call these errors cognitive biases. They can lead us down the wrong path, but they're actually part of how our brains handle the crazy amount of information we get all the time. Without these biases, it would be super tough to process everything logically.

Still, it's important to keep these biases in check, as they can twist our view of reality and lead to not-so-great decisions. So, I thought I'd share some common biases that we, as developers, can bump into:

Confirmation Bias: We might lean towards solutions or tech that fit with what we already know or believe. This can stop us from picking up something that could be even better.
Anchoring Bias: We sometimes stick too much to the first piece of info we get (the "anchor") when we're making decisions. For instance, we might guess how complex a task is based on something similar we've done before, even if it's not really the same thing.
Dunning-Kruger Effect: If we're not that experienced, we might think we're better at coding than we really are. This can make us too confident and cause mistakes.
Survivorship Bias: We might only focus on the projects or tech that did well and ignore the ones that flopped. This can make us too optimistic about how likely something is to succeed.
Not Invented Here (NIH) Syndrome: Sometimes we might dismiss solutions made by others and end up making new tools or frameworks when we could just use what's already there.
Recency Bias: We might pay too much attention to things that happened recently, like a bug we just ran into. This could skew our view of how reliable a project or tech really is.

So there you have it, folks – a quick rundown of some of the mental trip-ups we might face as developers. It's essential to remember that we're all susceptible to these biases, no matter how skilled or experienced we are. By being aware of them, we can work smarter, make better decisions, and create code that really shines. Keep coding, stay aware, and let's build great stuff together!

Ten Red Flags That Obstruct Systems Thinking

kate astrid — Sat, 16 Sep 2023 10:33:59 +0000

Hey cool people! 👋

Today I want to share with you a piece of useful knowledge about systems thinking that helps me analyze systems and their connection to each other and allows me to improve my understanding of any process I interact with, be it companies, code bases, or even human bodies.

In general, systems thinking is an approach to understanding and solving complex problems by looking at the bigger picture. Instead of focusing on individual parts or events, systems thinking considers how those parts are interconnected and how they impact each other. This approach helps to identify the root causes of problems and create long-lasting solutions, rather than just addressing the symptoms. In simple terms, systems thinking is like looking at a whole forest rather than just individual trees, recognizing how everything is connected and influences each other.

There are ten statements — red flags — that act as obstacles to systems thinking:

“Let’s fix it quick!” While systems thinking doesn't demand slow problem-solving, hastily jumping into solutions without understanding the problem is counterproductive.
“Just put a Band-Aid on it.” Temporary fixes can hide symptoms while the underlying issue continues to harm the organization.
“We need the budget finalized!” Focusing on budgets and deadlines promotes linear thinking, moving away from systems thinking principles.
“We must respond right away!” Rushing to address problems encourages linear thinking, while calmly analyzing the situation fosters systematic thinking.
“Who cares?” Apathy hinders creativity and problem-solving, preventing organizational growth and effective solutions.
“We need more information.” Collecting data is important, but linear thinking arises when expecting data alone to solve problems without proper analysis and action.
“You are overthinking things.” Disagreements may be seen as overthinking. Systems thinking requires stretching beyond comfort zones and embracing complex solutions.
“Forget the rest of the organization.” Linear thinkers prioritize personal needs with win-lose solutions. Systems thinking seeks win-win solutions that benefit everyone.
“We don’t want any conflict.” Avoiding conflict at all costs can prevent addressing real problems. Confronting conflicts is necessary for effective problem-solving.
“We will do it this way.” Imposing one's will stifles creativity, innovation, and collaboration, hindering effective problem-solving and growth within the organization.

I truly believe that systems thinking can introduce new perspectives, reveal hidden problems if they exist, and help existing processes to thrive and prosper 💃 .
Lets's discuss it. Have you tried this approach? 👀

How to Maintain the Performance of a React Application on a Daily Basis

kate astrid — Wed, 06 Sep 2023 07:42:59 +0000

I'm a fast-paced person: I eat quickly, walk briskly, and make decisions in a snap. What I can't stand, though, is a slow app — especially one I'm working on. So, I always find myself compelled to scrutinise its performance: examining how many times it re-renders, the size of the DOM, and the speed of user interactions, among other things. Armed with this data, I incrementally improve the app's performance by refining the codebase in a targeted way.

Now, I'd like to share some strategies that could help enhance your app's performance:

Be Mindful of the Hooks You Use in Each Component: From my perspective, this is crucial. useState and useEffect are the most commonly used hooks, but sometimes they can be eliminated with a bit of refactoring, without sacrificing functionality. Fewer hooks mean fewer re-renders, which in turn means a faster app. Other noteworthy hooks are useCallback and useMemo, which memoize values, storing them in memory. On a larger scale, this can have an impact on performance. The same goes for React.memo().

Simple example:

Imagine you have a component that tracks a user's first name, last name, and age. A naive approach could be to declare three separate useState hooks:

const UserProfile = () => {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');
  const [age, setAge] = useState(0);

  // Multiple function calls to update the user profile
  const updateUserProfile = () => {
    setFirstName('John');
    setLastName('Doe');
    setAge(30);
  };

  return (
    <div>
      <h1>{`${firstName} ${lastName}`}</h1>
      <p>Age: {age}</p>
      <button onClick={updateUserProfile}>Update Profile</button>
    </div>
  );
};

Every time each of those hooks is called, the component will re-render, even if it happens simultaneously. We could condense this into a single useState by using an object:

const UserProfile = () => {
  const [user, setUser] = useState({
    firstName: '',
    lastName: '',
    age: 0,
  });

  // Single function call to update the user profile
  const updateUserProfile = () => {
    setUser({
      firstName: 'John',
      lastName: 'Doe',
      age: 30,
    });
  };

  return (
    <div>
      <h1>{`${user.firstName} ${user.lastName}`}</h1>
      <p>Age: {user.age}</p>
      <button onClick={updateUserProfile}>Update Profile</button>
    </div>
  );
};

Now, we have only one hook, and only one re-render when the hook is called. Bingo.

Minimise the Number of DOM Nodes: I always ask myself, "Can this HTML tag be safely removed?" If the answer is yes, I remove it. Fewer nodes lead to better performance.

Simple example:

If you find the code using empty divs solely for styling purposes, consider using CSS Grid or Flexbox to achieve the same layout, thus reducing the number of DOM nodes.

// Before
<div className="wrapper">
  <div className="innerWrapper">
    <Component />
  </div>
</div>

// After
<div className="optimizedWrapper">
  <Component />
</div>

Favor Class-Based Styling Over Inline Styles: Inline styles are considered new objects on each render, which can make React think something has changed, triggering unnecessary re-renders and affecting performance. It's also worth noting that maintaining styles in separate files helps keep the styling consistent.

Simple example:

// Before
<div style={{ display: 'flex' }}>

// After
<div className='container'>

// In a separate css file: 
.container: {
  display: flex
}

Prefer Simple divs to Box from Material UI or Similar UI Libraries: Native HTML elements generally offer better performance because they don't carry the overhead of additional React components, including lifecycle methods and context consumption.

Simple example:

// Before
<Box p={2}>

// After
<div className="container">

// In a separate css file: 
.container: {
  padding: '2px'
}

Prefer Conditional Classes to Conditional Styles in makeStyles from Material UI or Similar UI Libraries: Using predefined classes that are toggled based on conditions can be more performant, as it doesn't generate new classes at runtime.

Simple example:

// Before
const useStyles = makeStyles({
  root: {
    backgroundColor: props => props.isActive ? 'blue' : 'white',
  },
});

// After
const className = isActive ? 'active' : 'inactive';

Opt for Functional Components: There are several compelling reasons for this. First, functional components are easier for build tools like Webpack to optimize through "tree shaking," which only includes the code that's actually being used in the final bundle. Second, functional components often result in a smaller component tree and fewer lifecycle methods, allowing React's diffing algorithm to make quicker updates to the DOM. Lastly, functional components use less memory than class components, which is especially beneficial in environments where memory is limited.

Simple example:

// Before
class MyComponent extends React.Component {
  state = { /* ... */ };
  componentDidMount() { /* ... */ }
  render() { /* ... */ }
}

// After
const MyComponent = () => {
  const [state, setState] = useState(/* ... */);
  useEffect(() => { /* ... */ }, []);
  return (/* ... */);
};

By giving these tips a go and making them a regular part of your coding routine, you're not just on the path to a speedier React app, but you're also gonna make things a whole lot smoother for your users.
Let's create better apps together =).

DEV Community: kate astrid

The Wrong Question: Why Blameless Culture Builds Better Engineering Teams

What Blameless Culture Actually Means

Why Blame Feels Right (And Why That’s a Trap)

1. It Teaches People to Hide Things

2. It Optimizes for the Wrong Outcome

3. It Selects Against the People You Most Want to Keep

4. It Misunderstands How Complex Systems Fail

What Changes When Blame Leaves the Room

Postmortems Become Useful

Near-Misses Get Reported

Incident Response Gets Faster

Junior Engineers Ramp Faster

Systemic Fixes Actually Get Built

What Blameless Culture Is Not

It’s Not Consequence-Free

It’s Not the Absence of Standards

It’s Not “Everything Is the Company’s Fault”

It’s Not Infinitely Patient With Repeated Mistakes

How To Actually Do It

Write Postmortems in the Second-Person Plural

Ask “How?” Before “Who?”

Separate Incident Reviews From Performance Reviews

Reward Engineers Who Surface Their Own Mistakes

Fix the System, Every Time

Make Leaders Go First

The Deeper Point

Further Reading

How We Halved Our Playwright E2E Suite

The Before / After

Pattern 1: Programmatic Auth

Pattern 2: API-Driven Setup

The Tradeoff

Pattern 3: State Assertions, Not Fixed Waits

Pattern 4: For “Was This Persisted?” — Ask the API, Not the DOM

Pattern 5: Audit for Redundancy

Symmetric Mirror Tests

Cleanup Tests Duplicating Hooks

Generic Component Smoke Tests

What We Didn't Do

Parallelizing Tests That Shared Accounts

Reusing Auth Sessions Across Browser Contexts

Using Short Retry Budgets for Permission Assertions

Takeaways

From Chaos to Clarity: Fixing Our Monorepo

Introduction: Why This Story Might Save You Some Headaches

So why did we bother?

Journey-Monorepo in a Nutshell

The “BEFORE” Setup

How We Tackled It

After the Restructuring: What We Learned

Final Thoughts

What To Expect When You Join Epilot

Have you heard about the anterior midcingulate cortex?

Common Cognitive Biases That May Affect Us As Developers

Ten Red Flags That Obstruct Systems Thinking

How to Maintain the Performance of a React Application on a Daily Basis