AI coding agents have changed the way software engineers work.

I can ask an AI to investigate a bug while I work on another task.
I can have another agent write tests.
Another can review a PR.
Another can explore an unfamiliar codebase.

That sounds amazing. And it is.

But there’s a problem.
While AI can work on multiple things at once, I still have only one brain.

And that can create a lot of context switching.

Personal Update

For years, I kept telling myself that I’d start a YouTube channel when the time was right.

I kept waiting. Planning. Overthinking. Eventually, I realized I needed to take my own advice.

Sometimes you have to walk away from perfection too. So I finally created and have also published 2 videos

If you find value in things I share, do consider subscribing :D

Subscribe Here

What is AI context switching?

Before AI, I might spend two hours working on one problem.

• Read the code.

• Understand the issue.

• Write the fix.

• Run tests.

• Done.

With AI, the flow can look more like:

Write prompt → wait → review → give feedback → wait → review again

Now add multiple agents:

Agent 1 is doing a bug fix.

Agent 2 is writing tests.

Agent 3 is reviewing a PR.

Suddenly, I’m checking three different things every few minutes.

The agents are working in parallel.

My brain is not.

The goal isn’t to use fewer AI agents

The obvious solution is:

“I’ll just use one agent at a time.”

But then you’re leaving a lot of AI’s power on the table.

The better solution is:

Let AI multitask. Don’t multitask yourself.

Think of AI agents like engineers on your team.

You might give three engineers three different tasks.
You don’t need to sit with all three every minute.
You give them the context they need.

They work.

Then you review their work later.

AI should work the same way.

Batch your AI work

Instead of checking an agent every few minutes, create specific times to review AI work.

For example:

9:00–11:00
Deep work. Agents work in the background.

11:00–11:30
Check agent results. Answer questions. Give new instructions.

11:30–1:00
Back to deep work.

2:00–2:30
Second AI review session.

Now your day isn’t:

Code → AI → Slack → Agent → PR → Agent → Code

It is:

Deep work → AI review → Deep work → AI review

Much easier on your brain.

Use AI work as a queue

This was a useful mental shift for me.

When an agent finishes, I don’t need to look at it immediately.

Its result can simply wait in a queue.
I finish what I’m doing.
Then I pick up the next result.

So instead of:

“My agent finished! I need to check it!”

Think:

“Great. I’ll check it when I’m ready.”

This puts you in control of your attention.

Not the AI.

Make the handoff better

Another way to reduce context switching is to give the AI more responsibility.

Don’t just say:

“Fix this bug.”

Say something like:

“Investigate the bug, implement the fix, add tests, run the test suite, and tell me what you changed and anything you’re unsure about.”

Now the AI can do more before coming back to you.

And when it does come back, you have a much clearer result to review.

A good handoff should answer:

What did you change?
Did it work?
What did you test?
What still needs my attention?

The fewer questions you have to ask, the better.

The context matters too

Running five agents doesn’t mean you should work on five completely different things.

For example:

Good:

• Agent 1 → investigate a bug in the payments service

• Agent 2 → write tests for the same service

• Agent 3 → review a PR for the same service

You’re doing three things, but you’re still in one mental context.

Bad:

• Agent 1 → payments

• Agent 2 → hiring

• Agent 3 → database migration

• Agent 4 → mobile app

Now you’re constantly rebuilding your understanding of completely different systems.

That’s where things get exhausting.

So ask yourself:

Can these tasks share the same mental context?

If yes, parallelize.

If not, be more careful.

AI shouldn’t decide when you switch

This is probably the biggest lesson.

An agent finishes.

A notification pops up.

You immediately open it.

Then another agent finishes.

You switch again.

Before you know it, you’ve spent the morning jumping between tasks.
The agent finishing is not a reason for you to switch.

Your priorities should decide when you switch.
The AI can wait.

The real skill is becoming better at delegation

As engineers become more senior, the job changes.

It’s not just:

“How quickly can I write this code?”

It becomes:

“How effectively can I get this work done?”

AI is pushing us even further in that direction.

The best engineers won’t necessarily be the ones who write the most prompts.
They’ll be the ones who know:

• What to delegate

• What context to give

• What to run in parallel

• What needs human judgment

• When to review the results

AI is making delegation a technical skill.

Protect your attention

We often talk about AI making us 10x more productive.

But there’s another question we should ask:

What happens to our attention?

If AI lets me complete 10 tasks but I spend the whole day jumping between them, did I really become more productive?

I’d rather have:

AI working on 10 things
while
I focus on 1 thing.

That’s the sweet spot.

My simple rule for AI-assisted engineering

Let AI run in parallel.
Keep your attention focused.
Batch your AI reviews.
Give agents enough context to work independently.
Don’t let notifications decide what you work on next.

Because the biggest advantage of AI isn’t that it can multitask.

It’s that it can work while you don’t.

How can I help?

• Join my cohort
  “Break Into Senior Engineering Roles,” a live cohort course to help you prepare better and position yourself right for tech interviews and senior engineering roles. [Check Details Here]

• Be a Paid Subscriber
  You can get maximum benefit of the high-performer community by being a paid subscriber here. Here are the benefits you get

• Sponsor this newsletter
  Want to reach 24,000+ senior engineers and tech leaders? [See sponsorship options]

• Digital Products

  Check out my digital products to help you grow better as a Software Engineer and Leader in Tech

Stay in touch

Find me on

• LinkedIn

• Youtube

• X

• Instagram

• Threads

• Join WhatsApp Community

Any questions? Just email me at hemant.pandey17@gmail.com

One of the worst career advice I ever followed was this:

“Never quit.”

Keep trying. Work harder. Stay patient. Things will eventually get better.

As software engineers, we are taught to debug problems instead of walking away from them.

That is a great mindset when you are fixing code. It is not always a great mindset for your career.

Over the last 8 years, I’ve worked across SAP, Salesforce, Meta and now LinkedIn. Looking back, some of the biggest leaps in my career did not happen because I stayed.

They happened because I knew when it was time to leave. I will be talking about these in this newsletter, but before that I have a personal update

Personal Update

For years, I kept telling myself that I’d start a YouTube channel when the time was right.

I kept waiting. Planning. Overthinking. Eventually, I realized I needed to take my own advice.

Sometimes you have to walk away from perfection too. So I finally published my first YouTube video.

It is about my journey - from growing up in India, moving to the US for my Master’s, working at Meta and LinkedIn, and why I’m building content for software engineers.

If you’ve enjoyed reading these newsletters, I am sure you will enjoy the videos too.

And if you find it useful, I’d really appreciate you subscribing. Every subscriber helps when you are just getting started.

Subscribe to Youtube

Back to the topic,

1. Walk Away When You’re No Longer Learning

There iss a difference between being comfortable and being stagnant.

If you’ve been solving the same problems for two years, working on the same service, using the same tech stack and attending the same kind of meetings

You might be getting better at your current job but you may not be becoming a better engineer.

One question I ask myself every few months is:

Am I learning something today that will make me more valuable two years from now?

If the answer keeps being “no”, it is probably time to look for a new challenge.

2. Walk Away From Managers Who Stop Investing in You

Not every bad manager is toxic. Some are simply checked out.

They don’t give feedback. They don’t help you grow. They don’t advocate for your promotion.

If every 1:1 feels like a status update instead of a coaching session, that is a big problem.

A great manager can accelerate your career but wrong one can quietly slow it down for years.

3. Walk Away From Needing Everyone’s Approval

Early in my career, every code review comment felt personal. If someone rejected my design, I felt like they were rejecting me.

Over time I realized something.

Good engineers critique code. Not people.

If your PR gets 30 comments, that’s not a sign you’re a bad engineer. It usually means someone took the time to make your code and you better.

Take the feedback. Improve the code. Then move on.

Don’t carry every comment home with you.

4. Walk Away From Comparing Yourself to Everyone Else

One friend joins Google. Another gets promoted to Staff Engineer.

Someone else posts their ₹1 crore compensation package. It is easy to feel like you’re falling behind.

I’ve been there. But here’s what I’ve learned.

You’re comparing your entire journey to someone else’s highlight reel.

Your career isn’t late, it is just different and everyone has their own timeline

5. Walk Away Before Burnout Walks You Out

I’ve seen engineers wear burnout like a badge of honor.

Late nights. Weekend deployments. Being online all the time.

It looks like dedication initially but after a while, it becomes exhaustion.

The truth is, nobody gives you a medal for burning yourself out.

Take your vacation. Log off. Spend time with your family.

The best engineers I know are never the ones who work the longest hours.

They are the ones who can perform consistently for years.

Walking Away Doesn’t Mean Giving Up

Walking away doesn’t mean you’re weak.

It means you’ve decided your time is valuable.

Your energy is limited and your career deserves better.

Sometimes the bravest decision isn’t staying and hoping things change.

It is accepting that they probably won’t.

Final Thoughts

If there’s one lesson I’d give every software engineer, it’s this:

Be patient with difficult problems but don’t be patient with situations that stop you from growing.

Your career is too long to spend years in the wrong place.

Sometimes the best promotion, the best learning opportunity or even the best version of yourself is waiting on the other side of a decision you have been afraid to make.

How can I help?

• Join my cohort
  “Break Into Senior Engineering Roles,” a live cohort course to help you prepare better and position yourself right for tech interviews and senior engineering roles. [Check Details Here]

• Be a Paid Subscriber
  You can get maximum benefit of the high-performer community by being a paid subscriber here. Here are the benefits you get

• Sponsor this newsletter
  Want to reach 24,000+ senior engineers and tech leaders? [See sponsorship options]

• Digital Products

  Check out my digital products to help you grow better as a Software Engineer and Leader in Tech

Stay in touch

Find me on

• LinkedIn

• X

• Instagram

• Threads

• Join WhatsApp Community

Any questions? Just email me at hemant.pandey17@gmail.com

Learn System Design the Right Way (Educative.io)

I used to watch random System Design videos and memorize architectures. It helped... until I got a new interview question.

What actually worked was learning a repeatable framework.

That’s why I like Educative’s Grokking the Modern System Design Interview course. One thing I found especially useful is that every problem starts with clarifying requirements before jumping into architecture, exactly how strong candidates approach real interviews.

Check Here

I run a cohort for senior software engineers. 60+ software engineers have participated in it and this experience taught me things I never expected

As a part of the multiple batches of the cohort, I got to work with multiple software engineers - mid level till Senior Engineering Managers. It taught me that career growth at all these level is rarely about learning more things or earning another certification.

The harder problems are usually less obvious:

• Making good technical decisions with incomplete information.

• Explaining trade-offs clearly.

• Influencing people without relying on authority.

• Giving and receiving feedback.

• Moving from solving problems yourself to helping the team solve problems better.

I also learned that senior engineers often do not need more general advice. They need a structured environment where they can work through real situations, compare ideas with peers, and receive useful feedback.

That is one of the main reasons I had to improvise my cohort for first four batches. I realised what things I have been missing.

The most valuable part has been watching participants learn from one another. Someone shares how they handled a difficult conversation with a stakeholder. Another person explains how they approached a system design trade-off. Together, these diverse stories from different folks create a set of practical examples that no textbook could provide.

A few moments from the cohort changed how I think about growth at the senior level. What worked for me may work or many not work for others

1. The engineer preparing for their first senior role

One participant was technically strong but kept getting stuck in senior-level interviews.

They could solve the coding problems.

They knew their systems well.

But when asked a question like:

“Tell me about a time you influenced a team.”

their answer usually became a list of things they personally built. That was the problem.

They were still thinking like an individual contributor trying to prove that they could solve hard problems.

For a senior role, the interviewer was looking for something different.

Could they identify an ambiguous problem?

Could they bring people together?

Could they make a decision without having all the information?

Could they get other engineers to move in the same direction?

We spent time breaking down one of their projects and looking at it from that perspective.

The work hadn’t changed. The way they explained the work did. That’s something I see quite often.

You may already be doing senior-level work. You just haven’t learned how to recognize and communicate it yet.

2. A strong coder kept failing behavioral interviews

Another engineer was excellent at DSA.

They could solve most of the problems.

But when the interviews moved to behavioral questions, things changed.

“Tell me about a conflict with a teammate.”

They mentioned a very generic story

That’s technically an answer. But there’s nothing memorable about it.

We went deeper.

What was the disagreement? What did you do? What did the other person want? What did you get wrong? What was the outcome?

After a few iterations, the same story became much stronger.

The interesting part was that the engineer hadn’t suddenly gained more experience.

They already had the story. They just hadn’t learned how to tell it.

3. An experienced engineer was overcomplicating everything

I expected less experienced engineers to struggle with complexity.

Instead, one of the more experienced engineers kept giving extremely complicated answers.

Ask a coding question. They’d immediately start discussing edge cases.

Ask a system design question. They’d jump into scaling problems that weren’t relevant to the prompt.

Ask a behavioral question. They’d give a 10-minute answer.

Their experience was actually getting in the way.

We worked on a simple rule:

Answer the question you’re asked.

Don’t try to prove everything you know. In interviews, more information doesn’t always mean a better answer.

Sometimes the strongest answer is the simplest one

4. One engineer knew the answer but wasn’t confident

This was probably my favorite.

There was a participant who would often say:

“I’m not sure if this is right…”

And then give a perfectly reasonable answer.

They knew the material. But they constantly second-guessed themselves.

We started practicing with one rule:

Think out loud.

Instead of worrying about whether the final answer was perfect, explain your reasoning.

“I’d start with this approach because…”

“I see one problem with it…”

“I’d change this because…”

That changed their interviews quite a bit.

Interviewers don’t expect you to know everything. They want to see how you handle uncertainty.

5. Another engineer was solving problems too quickly

This sounds like a good problem to have.

It wasn’t.

They would see a familiar coding problem and immediately start typing.

Sometimes they were right. Sometimes they missed a requirement.

Sometimes they didn’t explain their approach at all.

We started forcing a pause before coding.

• Clarify the problem.

• Walk through an example.

• Explain the approach.

• Then code.

It felt slower.

But their interviews got better.

That’s another thing I’ve learned:

The fastest person isn’t necessarily the strongest candidate.

The person who makes their thinking easy to follow often does better.

Final Thoughts

Running these interviews made me realize something.

A lot of engineers prepare by learning more.

More LeetCode. More system design. More frameworks. More interview questions.

That’s useful.

But at some point, you need to practice performing.

Can you solve a problem while someone is watching?

Can you explain your design clearly?

Can you recover when the interviewer pushes back?

Can you tell a good story about a difficult project?

Can you admit that you don’t know something without panicking?

These are interview skills too.

And you don’t build them by watching another 50 interview videos.

You build them by actually interviewing.

Getting feedback.

Making mistakes.

And doing it again.

That’s a big part of what we do in the cohort.

You can check details below.

Senior Software Engineer Async Mentorship Cohort

My next Senior Software Engineer Async Mentorship Cohort is starting soon

We’ll work together to help you 2x your compensation:

✅ Resume that gets interviews
✅ System Design & HLD session
✅ Behavioral interviews session
✅ Career strategy & salary negotiation session
✅ Whatsapp support and 1:1

If you’re aiming for Senior, Staff, or higher-paying software engineering roles, I’d love to work with you.

Apply Here

I personally review every application, so seats are intentionally limited.

Read more

Read more

When people talk about becoming a better software engineer, the conversation usually revolves around technical skills.

Learn System Design. Master AI. Grind LeetCode. Understand distributed systems.

All of these matter.

But there’s one skill that has a much bigger impact on your career than most people realize.

Can people enjoy working with you?

I’ve worked with engineers who were incredibly smart. They could solve problems faster than anyone else on the team.
But if a new project came up, people would quietly hope they weren’t assigned to work with them.

Why?

Because software engineering isn’t an individual sport.
You spend more time discussing ideas, reviewing code, debugging together, and helping teammates than actually writing code.

Your technical skills might help you land the job. Your behavior decides whether people want to work with you again.

Learn System Design the Right Way (Educative.io)

I used to watch random System Design videos and memorize architectures. It helped... until I got a new interview question.

What actually worked was learning a repeatable framework.

That’s why I like Educative’s Grokking the Modern System Design Interview course. One thing I found especially useful is that every problem starts with clarifying requirements before jumping into architecture, exactly how strong candidates approach real interviews.

Check Here

Here are five behaviors I’ve seen hurt otherwise talented engineers.

1. The Know-It-All

What they do

They always have an answer. Every discussion becomes a debate.

Instead of trying to understand another perspective, they’re busy proving why they’re right.

After a while, people stop sharing ideas. Meetings become quieter, and good suggestions never get voiced because everyone already knows how the conversation will end.

What to do instead

Remember that being the smartest person in the room isn’t the goal. Getting to the best solution is.

Ask questions before giving opinions.

Be willing to say, “I hadn’t thought about it that way.” People respect confidence, but they trust humility.

If you work with one

Don’t turn it into an argument. Share your opinion with data and examples.

If someone else hasn’t spoken, invite them into the discussion. Sometimes the best thing you can do is create space for other voices.

2. The Blame-Shifter

What they do

When something breaks, they immediately start looking for someone to blame.

“It wasn’t my code.”

“QA should have caught it.”

“The requirements weren’t clear.”

The problem is that blame rarely fixes production issues. It only makes people afraid to admit mistakes.

What to do instead

Own your mistakes. Everyone ships bugs and everyone misses edge cases.

What matters is how quickly you acknowledge it, fix it, and learn from it.

People don’t lose trust because you made a mistake. They lose trust when you refuse to own it.

If you work with one

Keep bringing the conversation back to solutions.

Ask, “What can we do differently next time?”

That simple question shifts the focus from blame to learning.

3. The Lone Wolf

What they do

They prefer doing everything themselves. They rarely ask for help.

They don’t document their work. They keep important knowledge in their own head.

It might make them feel productive, but it usually makes the entire team slower.

If one person becomes the only expert, everyone else has to wait for them.

What to do instead

Share what you know.

Write documentation. Review code. Help teammates when you can.

A strong engineer doesn’t create dependencies. They remove them.

If you work with one

Look for opportunities to involve them in design discussions, pair programming, or knowledge-sharing sessions.

Sometimes people don’t realize the value of collaboration until they experience it.

Read more

A few months ago, I was doing a mock interview with an engineer who had more than seven years of experience.

Technically, he was excellent.

Within two minutes of hearing the question, he had already drawn:

• Redis

• Kafka

• Cassandra

• Kubernetes

• CDN

• Load Balancers

Honestly, the architecture looked good BUT

The only problem?

He never asked what problem he was solving.

I se…

Read more

Read more

The difference was not talent or skills
It was clarity, visibility and strategy

Three patterns I see repeatedly.

1) Treating interviews as the bottleneck
Many engineers keep grinding LeetCode when the real issue is re…

Read more

Read more

Read more

Last month I spent 3 hours debugging a service and the bug was not too difficult.

The fix ended up being a 4-line change.

The hard part was figuring out why the system existed in the first place.

Nobody on the team knew. Claude cannot answer it too as it has no context

The engineer who built it had left. The documentation was not there.
The Slack had random…

Read more

Robert C. Martin grouped these 5 principles under the acronym “SOLID” in the early 2000s. The acronym was first mentioned in a 2004 paper, Design Principles and Design Patterns

Let’s dive deep into each of these

1. Single Responsibility Principle (SRP)

Definition
A class should have only one reason to change, meaning it should have only one responsibility or job.

Why It’s Important
If a class has multiple responsibilities, a change in one responsibility might require changes in the other. This can lead to tightly coupled code, making it harder to maintain, test, and understand.

Detailed Example:
Let’s consider an example where a User class handles both authentication and data management.

Initially, it might seem convenient to put everything in one class:

This User class is now responsible for:

• Authentication

• Managing user data.

• Sending notifications.

If you need to change how notifications are sent, you’d have to modify the User class, potentially breaking something else.

To follow SRP, you can split this into three different classes:

Now, each class has a single responsibility:

• Authenticator handles authentication.

• UserDataManager handles user data.

• NotificationService handles notifications.

The code becomes easier to manage, test, and extend.

2. Open/Closed Principle (OCP)

Definition
Software entities like classes, modules, and functions should be open for extension but closed for modification.

Why It’s Important
When a class is closed for modification, you reduce the risk of introducing bugs into existing functionality. Instead of modifying existing code, you add new code, which is easier to test and integrate.

Detailed Example
Consider a scenario where we want to calculate the area of different shapes. Initially, you might write something like this:

This approach violates the OCP because every time a new shape is added, you need to modify the AreaCalculator class, increasing the risk of errors.

A better approach here is

Now, if you want to add a new shape, such as a Triangle, you simply create a new class extending Shape:

The AreaCalculator class doesn’t need to be modified.

This is a paid subscriber exclusive article and rest of the article can only be accessed if you are a paid member.

You can get maximum benefit of the high-performer community by being a paid subscriber here. Here are the benefits you get

Read more

Read more

Read more

Read more

Before we start, do check out

“Break Into Senior Engineering Roles” Async Cohort

I have opened the application form for my next async cohort

If you are a software engineer with 2-10 years of experience and want to get the offer you deserve, you can check the details here and fill out the application form if interested

I handpick folks so that it is a focussed group, and members can get maximum value

Check details and Fill the form

Here’s what we’ll break down:

• Why the same AI feature can cost 10x more overnight

• What actually drives your token bill (hint: not just prompts)

• How different models charge for the same exact usage

• The hidden reason AI costs spiral in production

• What smart teams are doing to stay efficient

Everyone is using AI. Almost no one understands what it actually costs.

We throw around “tokens” like they’re harmless units.

They’re not.

They’re your compute bill in disguise.

And if you’re building anything beyond a weekend demo, this is the layer that decides:

whether your product scales… or silently burns money.

Let’s start from first principles

A “token” is roughly:

• 1 word ≈ 0.75 tokens

• 1 token ≈ 4 characters

So this sentence?

~20 tokens.

Now zoom out.

Every API call includes:

• System prompt

• User input

• Retrieved context (if any)

• Tool outputs

• Model response

You are billed on all of it.

Not just what the user sees.

The real pricing model (simplified, but accurate)

Every provider charges separately for:

• Input tokens (cheaper)

• Output tokens (more expensive)

Typical ratio:

Output tokens cost ~2x to 5x more than input tokens

Why?

Because generating tokens is computationally harder than reading them.

A realistic production request (not the toy examples)

Let’s say you’re building an AI copilot.

One request might look like:

• System prompt: 800 tokens

• Chat history: 1,200 tokens

• Retrieved docs (RAG): 2,000 tokens

• User input: 150 tokens

• Output: 600 tokens

Total: ~4,750 input + 600 output tokens

Now multiply:

• 5 steps per workflow (tool calls, reasoning chains)

• 10K daily active users

You’re easily in the hundreds of millions of tokens per day

And that’s when pricing starts to matter a lot.

Same tokens ≠ same cost

This is where most people get it wrong.

They think:

“I’ll just swap models later”

But pricing differences are massive.

High-end models (top reasoning)

• Examples: GPT-4 class, Claude Opus

• Cost: $$$$

• Strength: deep reasoning, complex code, long chains of thought

Mid-tier models (balanced)

• Examples: GPT-4o, Claude Sonnet

• Cost: $$

• Strength: good enough for most real-world tasks

Small models (high scale)

• Examples: GPT-4o-mini, Claude Haiku, Mistral small

• Cost: $

• Strength: classification, formatting, simple Q&A

What does “expensive” actually mean?

Let’s normalize it.

For the same 1 million tokens:

• Small model → ~$0.1 to $1

• Mid model → ~$2 to $10

• Large model → ~$20 to $60+

(Varies by provider, but the ratios hold)

So yes:

The same workload can be 10x to 100x more expensive depending on model choice

Across companies, it gets even more interesting

Different providers optimize for different things:

OpenAI

• Strong ecosystem, tooling, multimodal

• Competitive mid-tier pricing

• Great latency-performance balance

Anthropic

• Higher cost at top tier

• Strong safety + long context

• Excellent for structured reasoning

Google (Gemini)

• Aggressive pricing in some tiers

• Deep integration with their infra stack

• Strong multimodal capabilities

Open-source (Mistral, LLaMA variants)

• Infra cost instead of per-token pricing

• Cheaper at scale

• More engineering overhead

Important insight:

You’re not choosing a model.
You’re choosing a cost-performance curve.

So far, this sounds manageable.

• Tokens are predictable

• Pricing is understandable

• You can estimate costs

But this is exactly where most teams get it wrong.

Because in real systems:

Costs don’t grow linearly.

They compound quietly.

This is the part that turns a cheap AI feature into your biggest infra bill.

• Context keeps growing

• Requests stack up

• Outputs get longer

• Systems become multi-step

👉 Let’s break down what actually causes this…

Read more

Read more

Reading great whitepapers is one of the most underrated boosters for engineering judgment, especially if you’re moving toward senior/architect level.

These aren’t tutorials.

They’re original thinking that shaped distributed systems as we know them

Read more

Most engineers don’t quit interview prep because they lack motivation.

They quit because their schedule destroys consistency.

And after running my cohort with 60+ engineers across multiple countries, I finally accepted something:

The traditional live cohort model is broken for working professionals.

At least for most people.

When I launched the cohort, I tho…

Read more