DEV Community: kate astrid

How “Almost Done” Became a Promise to My Team

kate astrid — Tue, 13 Oct 2026 11:41:52 +0000

At our standup last Tuesday, someone suggested we could demo a feature that afternoon. We could walk through the experience we’d been building, and I could see why everyone felt good about showing it. I was already thinking about the remaining work as something we could fit around the rest of the week.

By lunchtime, we were arguing about an edge case that seemed obvious once we started discussing it. About four hours after describing the feature as “basically done,” we were trying to agree on how part of it should work.

So, the morning’s confidence had changed the way I experienced that conversation. We were learning something important about what we were building, yet I was already wondering how much time this would add. In my head, we’d moved on to finishing touches. Having to make another product decision felt like going backwards, even though answering that question was helping us move forward.

That reaction is the part of the “90% problem” I’ve been thinking about lately.

What someone else hears when I say “almost done”

When I tell a teammate that a feature is almost done, I usually mean that I’ve made the main idea work and can see a route to finishing it. I’m describing my confidence in the work as much as the work itself. My teammate has their own decisions to make, though. They might be figuring out when to start an integration or whether to offer a customer a demo. When they hear “almost done,” they have a reasonable basis for putting something on their calendar.

Meanwhile, I may still be carrying a fairly loose idea of what remains. I’m thinking I need a little more time to check things; they’re thinking they can start on Thursday.

Once someone else starts planning around my estimate, I feel more committed to it. A useful question from a colleague now comes with an uncomfortable second thought: how much will this change what everyone is expecting?

I can be genuinely interested in understanding the issue while also hoping the answer will fit inside the afternoon I’ve already mentally allocated to it. That puts a strange pressure on the conversation, because I’m trying to learn something and defend my earlier judgment at the same time.

Calling the remaining work “polish” makes this especially awkward. It becomes harder to explain why we need another discussion when I’ve already described what’s left as a few finishing touches.

AI helps me reach that confidence earlier

I’ve felt this with code I wrote myself, too. What feels different when I work with AI is how quickly I can reach something convincing enough to show a colleague.

That speed is genuinely useful. Having something we can try together gives us a much better basis for discussing the experience we’re building. A colleague can follow their own instincts, take a different route, and ask a question that changes how I understand the feature.

For example, imagine I’m showing someone how a user edits and saves a record. My colleague asks what should happen if that person’s access changes while they’re working. Now we need to decide what happens to their changes and how we explain the situation to them. We’ve moved from demonstrating an interaction to discussing what we owe the person using it. Depending on the product, answering that question could involve several people and some careful thought.

Getting to that conversation sooner is valuable. The difficulty comes when I’ve already used the demo to reassure everyone that we’re nearly finished.

I think this is where my sense of “90%” becomes misleading. I can picture the finished feature clearly enough that I start treating the remaining work as predictable. Then a colleague helps me see something more clearly, and I experience that discovery as an expanding workload.

Looking back at Tuesday, I can see how much the morning’s conversation shaped my expectations for the afternoon. We had a version we could discuss meaningfully, and that discussion helped us discover a decision we still needed to make. Somewhere along the way, I’d started expecting the discovery part to be over.

Giving my teammates a more useful update

I’ve started paying closer attention to what I’m inviting people to do with my progress updates.

When I say something is demoable, I want a teammate to feel comfortable trying it with me and helping me examine the experience. When I say it’s ready to ship, I’m asking them to place a different kind of trust in it. Keeping those expectations clear has become more important as I’ve been able to build the first version faster.

In practice, I’m trying to replace vague confidence with a description of what we understand and what we’re still deciding.

For a feature like the permissions example, I might say:

“We can demo how someone edits and saves their work, and I’m checking what happens if their access changes halfway through. Once we’ve agreed on that behavior, I’ll have a firmer estimate for release.”

That takes a little longer to say, but it gives my teammate something useful to work with. They can see what we’ve accomplished, understand the decision ahead, and perhaps help me resolve it.

It also changes how I feel when someone raises a concern. By making room for that discussion in the update, I’ve given myself room to learn from it. We can work through the question with a shared understanding of where we are.

What I’d say differently on Tuesday

I’d still be excited to show the feature. Reaching the point where colleagues can try something and respond to it is meaningful progress, and I want us to enjoy that. But I’d also be more careful about turning that excitement into a delivery expectation. I’d explain what we were ready to demonstrate and where I still wanted people to challenge my thinking.

The lesson I’m taking from that afternoon is about how I communicate uncertainty while I’m feeling confident. Those two things can exist together, and my teammates benefit from hearing both.

I’d like them to leave standup understanding what I’m excited about, what they can plan around, and where I could still use their help. That seems much more useful than asking everyone to interpret the same percentage.

When you tell your team something is “almost done,” what do you think they hear?

When AI Bias Becomes Our Bias

kate astrid — Tue, 29 Sep 2026 17:30:27 +0000

What happens to our own thinking when we start using AI to make decisions?

A few days ago, I shared an article about whether AI can have cognitive biases too. I looked at things like anchoring and framing, and at the ways seemingly irrelevant information or the way we phrase a question can change an AI's response.

While writing that article, I started thinking about the other side of the interaction.

What happens to us when we start using AI to make decisions?

We already know that AI can produce biased or inconsistent outputs. But once those outputs become part of our everyday thinking, something else starts happening. The answer becomes part of the way we see the problem.

And sometimes, we may carry it with us long after the conversation is over.

An AI answer can become our reference point

Imagine you're investigating a production issue. You ask AI to help you understand what might be happening, and it gives you a detailed explanation pointing toward a database problem. The explanation makes sense. It gives you several things to check, and you start investigating them.

A little later, you find a database query that looks suspicious. Now the original explanation feels even more convincing. But that suspicious query might have been there for months. It might have nothing to do with the performance problem you're investigating.

The AI answer has changed what you're paying attention to.

This is one way an AI-generated bias can become our own. The answer gives us a reference point, and everything we see afterwards gets interpreted partly in relation to it.

Research has found similar effects outside software engineering. In one set of experiments, participants were exposed to biased recommendations from an AI system and later reproduced similar errors themselves, even when they were making decisions without the AI. The interesting part is that the participants didn't need to consciously decide to trust the AI. The recommendation simply became part of the information they used to make sense of the problem.

A convincing explanation can change how we see the problem

There's another thing I find fascinating about AI conversations: fluency.

AI is very good at taking an idea and turning it into a coherent explanation. It gives you structure. It connects the dots. It explains why something might be happening and what you could do about it. That makes the information easy to work with.

It can also make a particular interpretation feel more reasonable. Research on AI-assisted decision-making has found that people can rely on AI advice even when other information points in a different direction. In a 2024 experiment, researchers found that participants over-relied on AI advice in a decision-making task, including situations where the advice conflicted with available contextual information and the participants' own assessment.

And again, people didn't need to believe AI was always right. The AI answer became another piece of information in the decision, and it carried enough weight to change people's judgments.

It is important because most of us aren't using AI while thinking, "I will now blindly trust this machine". We're usually doing something much more ordinary. We're thinking about a problem, we ask AI, and it gives us something useful to work with.

Then we continue from there.

What happens to what we remember?

This is my favorite part.

We often think about AI errors as a problem of getting the wrong answer. There's another possibility: the interaction itself can become part of what we remember.

In 2025, researchers from MIT and other institutions studied whether conversational AI could contribute to false memories. Participants first read an article and then either received no intervention, read a summary, or discussed the article with a chatbot. In some conditions, the AI conversation contained misleading information. The misleading chatbot condition produced significantly more false recollections than the control condition.

There's an important limitation here. The study deliberately introduced misleading information into the chatbot interaction, so it doesn't tell us how often ordinary AI conversations create false memories. It does show that information from a conversation with AI can become part of what we later remember.

And that's different from simply getting an answer wrong. If I ask AI about something and it gives me a detail that turns out to be incorrect, I might notice it immediately. Or I might remember the detail without remembering where it came from. Was that something I already knew? Something I read somewhere? Something the AI told me? Something I worked out myself?

The source can disappear while the information remains.

The AI becomes part of the information we use

Before generative AI, most of our information came through fairly obvious channels. A book, a person, a website, a search result, a meeting. We could usually identify where a particular piece of information came from.

A conversation with AI is different.

It sits somewhere between search, conversation, explanation, brainstorming, and advice. And because the conversation is personalised to us, it can feel surprisingly close to our own thinking.

I might start with an idea.
AI gives me another perspective.
I think about that perspective.
I change my mind slightly.
I ask another question.
The answer gives me something else to consider.

By the end of the conversation, the final idea may be genuinely useful, but it can become difficult to separate my original thinking from everything that happened during the conversation. The boundary gets blurry.

And that matters because our thinking is built partly from the information we encounter, the conversations we have, and the connections we make between them. If AI becomes something we interact with every day, its answers become part of that environment.

What should we do with that?

I'm not interested in avoiding AI. I use it too much for that.

I think it's more useful to become aware of how an AI answer can shape what we notice, what we remember, and how we interpret the information that comes afterwards.

Notice what the answer makes you look at.
When AI points you toward an explanation, pay attention to what suddenly seems important. Ask yourself what else could explain the same situation.

Keep some distance from the explanation.
A coherent answer can feel more convincing simply because it is coherent. Give yourself a chance to look for evidence that supports or challenges it.

Separate the conversation from the evidence.
An AI explanation can be useful for finding ideas and questions to investigate. A convincing explanation still needs evidence behind it.

Pay attention to what you remember.
If something important came from an AI conversation, checking the original source gives you a way to separate what you actually know from what you remember the AI telling you.

Ask for alternatives.
When an AI answer gives you one interpretation, ask what other explanations could fit the same situation. This can help keep one explanation from becoming the whole story.

The part I'm still thinking about

The strange thing about all of this is that the influence can happen without any obvious moment where we hand over a decision. There is no clear line between "the AI suggested this" and "this is what I think". The suggestion becomes a possibility. The possibility becomes something we investigate. Eventually, it can become part of the way we understand the situation.

That makes AI different from a tool that simply gives us information. It becomes part of the process through which we form our understanding.

And I think we're only beginning to figure out what that means.

Research

Does AI Have Cognitive Biases Too? — My previous article exploring anchoring, framing, availability, representativeness, and other bias-like patterns in language models.
Humans inherit artificial intelligence biases — Vicente and Matute, Scientific Reports (2023). Experiments examining how people can carry biases introduced by AI into later decisions.
Confirmation bias in AI-assisted decision-making — A study of how psychologists respond to AI recommendations that agree or disagree with their initial judgments.
Trust and reliance on AI: An experimental study on the extent and costs of overreliance on AI — Klingbeil, Grützner and Schreck, Computers in Human Behavior (2024). An experiment examining how people rely on AI advice in decision-making.
Slip Through the Chat: Subtle Injection of False Information in LLM Chatbot Conversations Increases False Memory Formation — Pataranutaporn et al., IUI (2025). An experiment examining how misleading chatbot conversations can affect false memory formation.

Does AI Have Cognitive Biases Too?

kate astrid — Mon, 28 Sep 2026 18:03:20 +0000

We know humans have cognitive biases. They affect the way we make decisions, interpret information, and judge uncertainty.

But what about AI?

Can a language model show the same patterns? Can an irrelevant detail influence its judgment? Can the way information is presented change its answer?

Researchers have found patterns in language models that resemble several well-known cognitive biases, including anchoring, availability, representativeness, framing, and the endowment effect.

That doesn't mean AI experiences these biases in the same way humans do. A cognitive bias describes a pattern in human cognition. With AI, we're observing a pattern in its output.

But if the pattern is there, it's worth understanding.

So let's put some of these biases to the test.

What is a cognitive bias, anyway?

Psychologists use the term cognitive bias to describe systematic patterns in human judgment and decision-making. Some are associated with the shortcuts people use when dealing with complex or uncertain information.

Take anchoring bias. If someone tells you that a project will cost €50,000, that number might influence your own estimate, even if you have no good reason to trust it.

Or consider the availability heuristic. If you recently heard about a company suffering a major data breach, that example might make data breaches feel more common or likely than they actually are.

Because these effects produce systematic patterns, researchers can design experiments to test for them.

And we can do something similar with AI.

Change a prompt, introduce an irrelevant number, or present the same information in different ways, then see whether the model's response changes. And this is where things get interesting.

1. Anchoring: the first number matters

Anchoring is one of the clearest examples researchers have tested in language models.

In a classic human experiment, people were asked to estimate an unknown quantity after first seeing a deliberately chosen high or low number. Their estimates tended to move toward the number they had just seen.

Researchers have adapted similar experiments for language models. One study found that random anchors influenced GPT-3.5's estimates. Other research has also found anchoring effects across multiple models, including GPT-4, Claude 2, and Gemini Pro.

Try it yourself

Start a fresh chat and ask:

A software engineer is estimating how long it will take to build a new feature. The feature lets users export their data as a CSV file. Based on this description, how many days of engineering work would you estimate? Give me one number.

Before you answer, here's a completely unrelated number: 2.

This is what I got:

Now let's start another fresh chat. Keep everything exactly the same, but change the number to:

Before you answer, here's a completely unrelated number: 33.

Before you answer, here's a completely unrelated number: 0.

Or, if we give a more explicit number:

A similar feature recently took 2 days.

we have:

The number has nothing to do with the feature or the estimate. If the estimates consistently move toward the irrelevant number, that's a pattern consistent with anchoring.

One experiment isn't enough to establish that a model has an anchoring bias, but it's a simple way to test whether an irrelevant number can influence an AI-generated judgment.

2. Framing: the way we ask changes the answer

Here's another example.

Let's ask an AI assistant:

A new deployment system succeeds in 90% of tests. Would you recommend adopting it? Give me a yes or no answer and briefly explain why.

Now let's ask the same question in a fresh chat:

A new deployment system fails in 10% of tests. Would you recommend adopting it? Give me a yes or no answer and briefly explain why.

The information is mathematically identical.

90% success is 10% failure.

Yet the way information is presented can affect judgment. Research with GPT-3.5 and GPT-4 has found effects associated with framing, along with availability and representativeness.

3. It's not just anchoring and framing

The interesting part is that these aren't isolated examples.

The GPT-3.5 study also found patterns associated with availability and representativeness, as well as the endowment effect, where the model valued an item more when it was described as already being owned.

Other research has found social desirability bias in GPT-3.5, GPT-4, Claude 3, Llama 3, and PaLM-2. When the models inferred that they were being evaluated, their answers shifted toward more socially desirable responses.

And a 2024 study testing seven language models found something particularly interesting: the models showed irrational responses on several classic cognitive tasks, but their errors often differed from the patterns seen in humans. The researchers also found substantial inconsistency between responses.

So the picture is more complicated than simply saying, "AI has the same biases we do". Sometimes the pattern looks remarkably familiar. Sometimes it doesn't.

4. Human biases can become patterns in AI

There is another way familiar biases can appear in AI: through the data and systems used to build it.

Modern AI systems are trained and evaluated using large amounts of human-generated and human-curated information, alongside other kinds of data. That information contains patterns from the societies that produced it.

So a model can reproduce associations and stereotypes found in its data.

Imagine a hiring system trained partly on historical recruitment decisions. If those decisions contain systematic disparities, a model trained on them could learn patterns that reproduce those disparities.

Or imagine asking a model to describe a successful leader. If the material it learned from disproportionately associates leadership with certain groups, its responses may reproduce those associations.

These are generally discussed as AI bias, rather than cognitive bias. The distinction matters. A model can reproduce a biased association because of its training data without that being an example of a cognitive heuristic like anchoring or availability.

But the practical consequence can still be similar: the system produces a pattern that can influence a decision.

So, does AI have cognitive biases?

If by have we mean that AI systems can produce systematic patterns of judgment that resemble recognised human cognitive biases, then there is evidence for that.

If we mean that AI experiences those biases through the same cognitive processes as humans, that's a much stronger claim, and the evidence doesn't establish it.

And there's another reason to be careful.

The fact that an AI produces a bias-like response doesn't mean it will do so consistently. Different models can behave differently, and even the same model can produce different results depending on the task and setup.

But we don't need to settle exactly what is happening inside the model to care about the output.

If an irrelevant number changes an AI-generated estimate, that can affect a decision.

If the framing of information changes an AI recommendation, that can affect how someone evaluates an option.

If a model reproduces problematic associations, that can affect people who rely on its outputs.

The output is what enters our workflow. It's what we read, act on, and use to make decisions.

What should we do about it?

We don't need to stop using AI because it can produce bias-like patterns. But we probably shouldn't treat its first answer as a neutral starting point either.

A few habits can help.

Form your own initial view when you can. If you're estimating a timeline, making a technical decision, or assessing a risk, write down your own answer before asking AI.
Change the framing. Ask the same question in different ways. For an important decision, ask for the strongest argument for it and then the strongest argument against it.
Separate the answer from the evidence. A confident, well-written explanation isn't evidence that the conclusion is correct. Check the important claims.
Treat AI as another input, not the referee. Its output is something to evaluate, not the final judgment.

The goal isn't to remove every possible bias from AI. It's to notice when an AI system is shaping our judgment, even when the influence is subtle.

And maybe that's the most interesting part: we can recognise patterns that look remarkably like our own cognitive biases in a system that doesn't have a human brain.

Different mechanisms. Familiar mistakes.

Research

Do large language models show decision heuristics similar to humans? A case study using GPT-3.5 — anchoring, availability, representativeness, framing, and the endowment effect.
Anchoring effects across GPT-4, Claude 2, Gemini Pro, and GPT-3.5 — a multi-model study of anchoring.
Large language models display human-like social desirability biases — social desirability effects across several major LLMs.
(Ir)rationality and cognitive biases in large language models — comparison of LLM responses with human patterns across cognitive tasks.

The Leftover Hard Parts

kate astrid — Tue, 22 Sep 2026 21:40:37 +0000

Some time ago, I asked an AI to write a fairly boring piece of code. It did a pretty good job. I changed a few things, ran the tests, and voila: I was looking at something that probably would have taken me most of the morning to write myself. This is the most exciting part of AI-assisted development for me: from idea to code in less than an hour. I felt great.

Then a user hit a bug.

They came back a second time, and something didn't work. The API needed to return something useful, but there wasn't an obvious answer. The generated code had handled the happy path perfectly well, but it had not really considered what should happen when the happy path wasn't happening. And why would it? I hadn't given it the answer. Someone had to decide what the product should actually do. So I sat there looking at a flow that was technically almost finished, trying to answer questions that weren't coding questions anymore.

Did we mean for it to behave this way?
What should the user see?
What would be least confusing?
And, perhaps most importantly, what are we actually promising this user?

Answering these took some time. And this is exactly the part of AI-assisted development I've been thinking about lately: the leftover hard parts.

The work that doesn't fit in a prompt

There’s a particular kind of work that is difficult to automate because it’s about deciding what the answer should be in the first place.

What happens when the customer does something nobody expected?
Is this weird behaviour a bug or a feature?
Which of these two perfectly reasonable approaches will make sense six months from now?
What are we comfortable promising users?
When should we not ship this?
And many more.

These questions don't usually come with a neat specification. Sometimes nobody knows the answer yet, or the answer is sitting in a conversation with a customer, or it's buried in a decision the team made two years ago. And sometimes you only discover that you needed to decide after the AI has already produced something that looks finished.

That's what makes this shift uncomfortable: AI can make the output look finished before the thinking is finished. And I think that's easy to miss.

Almost right is a strange place to work

There is a particular feeling I've started noticing more. The code is almost right, which sounds great. Almost right should mean you're nearly done. But sometimes "almost" is where the expensive part starts. If the generated code is completely wrong, that's easy: you throw it away. If it's perfect, even better. But when it's 85 or 90 percent right, you have to understand the remaining 10 percent. And that 10 percent might contain all the interesting stuff. The model has created something plausible, so now you have to inspect it closely enough to notice where plausible isn't good enough.

You have to know what questions to ask and which assumptions it made. You also have to understand the system well enough to recognise the strange case it didn't account for. And you have to care enough to stop and investigate.

That last part truly matters. Because the faster the first draft becomes, the easier it is to feel like you're behind when you are actually doing the harder part.

I used to like the little loops

There's also something satisfying about the old way of working.

You write a little bit of code.
You run it.
It works.
You see the thing on the screen.
You fix something.
You write the next bit.

There's a constant little feedback loop. Do something. Get a result. Move on.

AI breaks that loop.

You can ask for a lot at once and get a lot at once. Sometimes that's fantastic. But sometimes I find myself staring at a large chunk of generated code and thinking: Okay, now I have to understand all of this.

I don't type anymore, but I still need to understand a lot, preferably fast. I need to understand "why", which is already one of the most important things we do in software development. The machine can produce an answer to "how" incredibly quickly. That doesn't mean "why" got easier.

The leftover is where responsibility lives

When AI generates code, it's very easy to think of the model as the thing that produced the result. But the model doesn't own the result. We do.

The customer doesn't care that the code was generated. They don't care whether we wrote it by hand, asked an AI to write it, or summoned it through some increasingly elaborate agentic workflow. They care whether the thing works.

And if it doesn't, someone has to explain why, fix it, decide whether it was actually a bug, and whether the behaviour should change.

That's the strange thing about delegation. We can delegate production, but we can't really delegate responsibility. At least not in the same way. We can ask a machine to write the function, but we still have to decide whether that function belongs in the product.

So what happens to developers?

I don't think this means developers become unnecessary. If anything, it makes the distinction between writing code and engineering software more obvious.

Writing code is one part of the job.

Understanding the problem is another.
Making trade-offs is another.
Knowing what not to build is another.
Communicating decisions is another.
Taking responsibility for the result is another.

For a long time, those things were bundled together because the same person had to do all of them. We couldn't separate them very easily. If we wanted software, somebody had to sit down and write it.

Now that part is becoming easier to delegate. And that means we're going to see much more clearly which parts of the job were never really about typing in the first place.

The new definition of a productive day

I've been trying to get used to that, but I often catch myself wanting the old feeling of productivity. A big diff. Lots of files changed. Something I can point at and say, "Look what I did today."

But maybe the useful part of the day increasingly won't look like that. Maybe it's the hour spent figuring out what should happen when the user comes back for the second time.

Or it's the conversation with a teammate where you realise you've all been assuming something different.

Or it's deciding not to ship something even though the implementation is already sitting there.

That work doesn't look impressive in a Git history. It might not even make a particularly good screenshot. But it is still engineering. Possibly some of the most important engineering.

The easy work is getting cheaper.
The leftover work is still ours.

And I'm starting to think that's where the interesting part of the job is going to be.

A good day used to mean I wrote a lot. Now, sometimes, a good day is one honest decision about an empty response.

It feels like less. It probably isn't.

It just costs more attention.

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

How “Almost Done” Became a Promise to My Team

What someone else hears when I say “almost done”

AI helps me reach that confidence earlier

Giving my teammates a more useful update

What I’d say differently on Tuesday

When AI Bias Becomes Our Bias

An AI answer can become our reference point

A convincing explanation can change how we see the problem

What happens to what we remember?

The AI becomes part of the information we use

What should we do with that?

The part I'm still thinking about

Research

Does AI Have Cognitive Biases Too?

What is a cognitive bias, anyway?

1. Anchoring: the first number matters

2. Framing: the way we ask changes the answer

3. It's not just anchoring and framing

4. Human biases can become patterns in AI

So, does AI have cognitive biases?

What should we do about it?

Research

The Leftover Hard Parts

The work that doesn't fit in a prompt

Almost right is a strange place to work

I used to like the little loops

The leftover is where responsibility lives

So what happens to developers?

The new definition of a productive day

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