Forem: Dan Fletcher

TypeScript: Using any in Generic Constraints

Dan Fletcher — Fri, 27 Jan 2023 19:35:09 +0000

Why any is bad

They any type in TypeScript is usually considered unsafe 99.99% of the time. This is why any is so dangerous:

const str: any = 'I am a string'
const num: number = str
num // 'I am a string'

Even though we're telling TS that num must be of type number, because the type of str is any it can easily be assigned to num even if the value is not a number.

Like I said, 99.99% of the time, any is bad. But there is one case in TypeScript where it's completely type safe to use any!

Generic constraints

When we are working with generics in TS we can constrain the generic using the extends keyword.

For example I might have a PetOwner type that has a list of pets, but I want it to be generic so that I can make the array contain only cats, or only dogs.

type PetOwner<T extends Array> = {
  pets: T
}

This type will currently cause a type error because the Array type requires a type argument. So lets give it one:

type PetOwner<T extends Array<any> = {
  pets: T
}

Now at first you may think that this is dangerous. We're using any! But lets look at what actually happens when we use this type:

const dogLover: PetOwner<Dog[]>

What is the type of dogLover here? If you gessed {pets: Array<Dog>} you're correct!

This is because when any is used in a generic constraint, TypeScript discards it and replaces it with whatever the type argument was, assuming that it matches the constraint. Dog[] matches the constraint of Array<any> so T gets the type Dog[].

⚠ any is still dangerous if you use it as a type argument. If I instead used PetOwner<any[]> it would have all the same pitfalls as using any in any other context outside of a generic constraint.

A note on unknown

unknown behaves exactly the same way as any in this context, so it may be preferable to use unknown but it’s totally up to preference.

For myself, I think any reads better. It describes the intent of the type code more clearly. T must be an array, but it can be an array of anything. Using unknown doesn't convey that message as well in my opinion.

How To Handle This Type Error

Dan Fletcher — Sat, 14 Jan 2023 02:52:40 +0000

Can you spot the Type Error?

function getProperty<T>(obj: T, propertyName: string) {
  return obj[propertyName];
}

I posed this question on Twitter recently and it received some interesting responses:

// Detect dark theme var iframe = document.getElementById('tweet-1613536297850929153-697'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1613536297850929153&theme=dark" }

The solution was intended to be rather simple, and in a way it is.

However there is some interesting nuance to this problem that I hadn't considered until people started commenting. Which then took me on a journey for a much more complicated solution.

For example, this comment, pointed out a flaw in my simplified version:

// Detect dark theme var iframe = document.getElementById('tweet-1613601410586648577-449'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1613601410586648577&theme=dark" }

I thought it would be easier to unpack all of this in longform rather than a series of tweets.

What is the Type Error?

I hope you tried to figure it out for yourself first, but here's the answer:

Element implicitly has an 'any' type because expression of type 'string' can't be used to index type 'unknown'.
No index signature with a parameter of type 'string' was found on type 'unknown'.

What this error is saying, is that you can't index the obj parameter using propertyName. Essentially TypeScript is helping you avoid a few mistakes.

Mistake 1

obj might not be an object (remember arrays are objects in JavaScript too) which would cause a runtime error when we try to do obj[propertyName].

For example, what would prevent getProperty(123, 'name')? Nothing. But TS prevents it with a Type Error, thankfully 🙏

Mistake 2

Even if obj is an object, it might not have the key that we pass as the propertyName argument.

For example:

const prop = getProperty({name: 'Dan'}, 'age')

In this case, prop would end up undefined, since 'age' isn't a property of {name: 'Dan'} (and TS would infer any as the return type from the function by the way -- also not good!)

The Fix

Now that we can spot the error, and why it's an issue, how can we fix this?

One approach might be to:

Narrow the type of T

function getProperty<T extends {}>(obj: T, propertyName: string) {
  return obj[propertyName];
}

What we've done is narrowed the type of T so that it's more specific. Now it has to be of type object.

This solves the first issue mentioned above, however it only changes the message of the Type Error to be:

Element implicitly has an 'any' type because expression of type 'string' can't be used to index type '{}'.
No index signature with a parameter of type 'string' was found on type '{}'.

So instead what you could do is:

function getProperty<T extends Record<string, any>(obj: T, propertyName: string) {
  return obj[propertyName];
}

Record<string, any> is basically saying that T is an object, where the keys are strings, but the values can be anything.

This will eliminate the Type Error and now the code will compile!

But this has a major problem...

function getProperty<T extends Record<string, any>>(obj: T, propertyName: string) {
  return obj[propertyName];
} 

// prop is now `any`
const prop = getProperty({name: 'Dan'}, 'age')

// Oops! prop is undefined, but no Type Error 😬
const shouldBeString: string = prop

As you can see we still have the second issue mentioned above, which is that the getProperty method doesn't guarantee that the property we pass exists on the object.

A much better approach is to use unknown instead of any:

function getProperty<T extends Record<string, unknown>>(obj: T, propertyName: string) {
  return obj[propertyName];
} 

// prop is now `unknown`
const prop = getProperty({name: 'Dan'}, 'age')

// Prop is still undefined
// But now, TypeScript will force us
// to narrow it's type before we use it.
// So this is a Type Error!
const shouldBeString: string = prop

By using unknown instead of any TS will force us to narrow the type before we use it.

The snippet above will be a Type Error since unknown can't be assigned to type string, so now you have to write a predicate or assertion to check that thing actually is of type string.

💡Tip: In general if you feel the need to use any in TypeScript, you should almost always use unknown instead.

This is useful to have, and I want to come back to this approach but there's another, simpler way to fix the issue.

Use keyof

The solution that I was trying to tease out of people on Twitter was to use keyof T as the type constraint for propertyName instead of using string.

Here is what that looks like:

function getProperty<T>(obj: T, propertyName: keyof T) {
  return obj[propertyName];
}

Quick refresher on the keyof operator:

In layman's terms, keyof is simply saying that a type must have a property of the type on the right hand side of the operator.

So for example if T is {name: 'Dan', age: 32} then keyof T is really just a union of string literals like this:

'name' | 'age'

Remember that a string literal such as 'name' can be a type in TypeScript.

So by constraining propertyName to be keyof T we're saying that propertyName must match one of the keys on the given obj.

This solves both of the issues mentioned above!

function getProperty<T>(obj: T, propertyName: keyof T) {
  return obj[propertyName];
} 

// Now the Type Error is here, where we want it
// 'age' does not exist on type `{name: 'Dan'}`
const prop = getProperty({name: 'Dan'}, 'age')

The nice thing about the solution above, is that it also allows the return type to be inferred properly.

Here's a couple examples:

// type will be 'string' | 'number'
getProperty({name: 'Dan', age: 32}, 'name') 

// type will be 'string' | 'number'
getProperty({name: 'Dan', age: 32}, 'age')

That's pretty neat right!?

This has problems too!

First of all, it would be nice if we received a more specific type back. Rather than 'string' | 'number' it would be nice if we got the actual type of the property we're pulling out of the object, right?

But that's not the only problem. There's a another issue here too.

This response from Twitter explains it well:
// Detect dark theme var iframe = document.getElementById('tweet-1613601410586648577-374'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1613601410586648577&theme=dark" }

So with keyof T alone, this function doesn't always cause Type Errors when we might expect it too.

Here are a few examples where it works as expected, and others where it doesn't:

Why? Because JS is weird and everything that's not an object still kind of acts like one.

For example, try this stuff in your JS console:

'123'['charAt'] // f charAt() { [native code] }
123['toExponential'] // f toExponential() { [native code] }
true['valueOf'] // f toValueOf() { [native code] }

So this implementation still has some weird behaviour.

But what if we combined the two approaches?

Use both extends and keyof

We're almost at the final solution!

Let's try combining both approaches from above and see what happens. But first lets clean this function up a bit. The types are becoming a bit unruly:

// Start by extracting the type definition to a new type alias
type GetProperty = <T>(obj: T, propertyName: keyof T) 
  => typeof obj[keyof T]

// Then update the function declaration to use the type
const getProperty: GetProperty = (obj, propertyName) => {
  return obj[propertyName];
}

Ok great, now we can focus on just the types without the noise of the function itself getting in the way.

So lets add that <T extends Record<string, unknown>> bit to this implementation and see what we get:

type GetProperty = <T extends Record<string, unknown>>
  (obj: T, propertyName: keyof T) 
    => typeof obj[keyof T]

const getProperty: GetProperty = (obj, propertyName) => {
  return obj[propertyName];
}

// These now cause type errors!
getProperty('123', 'charAt')
getProperty(123, 'toExponential')
getProperty(true, 'valueOf')

// works as it did above but type is still 'string' | 'number'
const age = getProperty({name: 'Dan', age: 32}, 'age')

Now we've addressed every issue that's been pointed out except for one!

It would be nice if when we used the getProperty function that the result would be the type of the property on the original object.

For example I would expect that:

let age = getProperty({name: 'Dan', age: 32, admin: true}, 'age')

Would actually return a type number and not 'string' | 'number' | 'boolean'.

In order to do that, we can add a second type parameter to our generic called K which can extends the keyof T - meaning that K must be a type in the key of T.

Like this:

type GetProperty = <T extends Record<string, unknown>, K extends keyof T>
  (obj: T, propertyName: keyof T) => typeof obj[keyof T]

Ok, so this hasn't really changed anything yet. We have to actually make use of K!

We want the second argument to this function to be K and the return to be T[K], like this:

type GetProperty = <T extends Record<string, unknown>, K extends keyof T>
  (obj: T, propertyName: K) => T[K]

So now when we use this function it has none of the issues discussed above, plus we get a return type that's been narrowed to it's most specific type (like number for example):

type GetProperty = <T extends Record<string, unknown>, K extends keyof T>
  (obj: T, propertyName: K) => T[K]

const getProperty: GetProperty = (obj, propertyName) => {
  return obj[propertyName];
}

// works as it did above but now, type is a number!!
let age = getProperty({name: 'Dan', age: 32, admin: true}, 'age')

Conclusion

I've been on a mission to level up my competence in TypeScript lately. So learn and practice something new every morning before work (doing the #100DaysOfCode challenge).

But sharing this journey in public and posing questions like the original Tweet it's really helped bring a lot of depth to my learning.

I honestly thought that the answer to my question was an easy one, and it turned out to have a way deeper answer than I anticipated.

I hope you enjoyed this little journey that I went on, and maybe even deepened your understanding of TypeScript too!

I couldn't have written this article alone so kudos to these gems:

https://twitter.com/Nartc1410 (for the insights and poking holes in my logic)
https://twitter.com/bitknight (for proof reading, insights and suggestions)
https://twitter.com/rgolea (suggesting solutions)

Like what you read? Want to support me?

A cup of coffee goes a long way 🙏

Why not buy me one? https://ko-fi.com/danjfletcher

Type Widening Is Kinda Weird

Dan Fletcher — Thu, 29 Dec 2022 16:51:15 +0000

Do you notice how in TypeScript that when you initialize a variable to a boolean, string or number, that TypeScript infers the type to be exactly that? A boolean, string or number.

For example:

let a = 4
a = 5
a // is 5 since type is number not 4

💡 Keep in mind, if you use const it prefers the more specific type 4

This is a huge feature of TypeScript! Type Inference is essential to writing easy to read, and maintainable TS codebases. It removes a lot of verbosity as well as reduces the amount of type code that has to be updated when a type upstream changes.

However there are some times, where this can cause weird errors. For example, I didn’t guess at first glance that the below code would cause a type error:

type User = {
  kind: 'user'
  name: string
};

function userName(user: User) {
  return user.name;
}

const user = {
  kind: 'user',
  name: 'Jane',
};

Can you spot the error?

If you caught it, great! If not, here's the issue you'll see from TypeScript:

Argument of type '{ kind: string; name: string; }' is not assignable to parameter of type 'User'.
  Types of property 'kind' are incompatible.
    Type 'string' is not assignable to type '"user"'.

Essentially what's happening is kind gets widened to type string when creating the user object, but the function expects kind to be type 'user'.

Solution

So what's the solution?

Use as const:

const user = {
  kind: 'user' as const,
  name: 'Jane',
};

When we use as const it tells TypeScript that we don't want the inference to prefer the wider type of string but instead use the more narrow type 'user'. And in this case, our error above goes away!

Like what you read? Want to support me?

A cup of coffee goes a long way 🙏

Why not buy me one? https://ko-fi.com/danjfletcher

Handling Exceptions In TypeScript

Dan Fletcher — Fri, 23 Dec 2022 14:55:36 +0000

TypeScript is all about type safety. But there are a number of situations that TypeScript can't properly guard against without a little help.

Take Exceptions for example. When we wrap a try .. catch around some code to handle a potential exception we probably want to do something like this:

try {
  await this.userService.all();
} catch (e: Error) {
  this.errorService.handle(e);
}

Unfortunately TypeScript won't allow you to do this!

The issue is that in JavaScript (and TypeScript) anything can be thrown as an "error". You can throw any arbitrary type; a number, a string, even null.

This is totally valid JavaScript and TypeScript:

throw 42;

Which means that our try .. catch only has two options for the type hint here. any or unknown.

The any type is the escape hatch out of TypeScript's type safety so we generally want to avoid that if we can help it.

So we're left with unknown.

The unknown type in TS is a way to force users of the type, to narrow the type down to something specific. It's not valid to use something when the type is unknown so we're forced to write a Type Guard.

Here is the try .. catch from above rewritten to use unknown:

try {
  await this.userService.all();
} catch (e: unknown) {
  if (e instanceof Error) {
    // guaranteed to be an Error now!
    this.errorService.handle(e);
  } else {
    throw Error("Can't handle this error!");
  }
}

There is a cleaner way to do this though. What if the handle method dealt with the unknown type instead?

class ErrorService {
  handle(e: unknown) {
    let message: string;

    if (e instanceof Error) {
      message = e.message;
    } else if (typeof e === 'string') {
      message = e;
    } else {
      message = "We don't know what the heck happened -- sorry!"
    }

    // handle the error message here
  }
}

This way the try..catch outside can just pass the unknown error through like this:

try {
  await this.userService.all();
} catch (e: unknown) {
  this.errorService.handle(e);
}

Like what you read? Want to support me?

A cup of coffee goes a long way 🙏

Why not buy me one? https://ko-fi.com/danjfletcher

Communication Tips For New Developers

Dan Fletcher — Wed, 09 Jun 2021 00:56:39 +0000

A user on the freeCodeCamp forums shared how they lost their first dev job due to lacking communication skills. I shared some of my ideas and that reply got quite a few likes so I figured it was content worth sharing here too. Here's my reply verbatim.

So sorry to hear about your termination.

Unfortunately it's a skill that's often not talked about much when people are presenting these "roadmaps" to becoming a developer.

It's hard to give you specific advice as I don't know what project management was like or what communication channels were available to you but I can give you a few pointers.

Break up tasks

The first and most important thing is to split any tasks assigned to you into small goals that you can achieve in a very small amount of time. When someone asks you what you're working on, the answer should be different than the answer was yesterday.

If your company uses Jira this may mean adding sub-tasks to the ticket you've been assigned, or it could just be writing your own notes about how you'd like to split up your work.

Whether it's for a customer, a user or a project manager, splitting work up into small units makes it easier for people (including yourself) to understand the progress you've made as well as open up more opportunities for feedback before you've spent too much time on something.

Plan your day

Schedule time at the beginning of your day to make a plan for yourself. Where I work we love splitting our day up into two parts; good day and great day.

Every morning my team lays out what we want to accomplish today. We account for meetings and personal development time. A good rule of thumb is that for most people the average time you get to sit and be productive writing code is about 4 hours.

I ask myself, if I had a good day today what would I get done? If things go really well (or great) what else might I get done on top of that?

Plans can change, and so I take note of unplanned work as it comes up throughout the day. If I don't get as much as I wanted done I can either attribute that to unplanned work that came up which I had to task switch for, or it's because I underestimated how long a task would take which happens all the time.

Create visibility

Some companies have daily check-ins often called "stand up". If your company doesn't do this, do it anyway. Every morning through whatever communication channel is available to you make sure that people on your team including your manager knows what you were working on yesterday, what you plan to work on today, and if you need any help.

It's important that this information actually changes day-to-day. A bad progress report sounds like:

"Yesterday I was working on ticket ACME-1234, it's going good, today just working on that more. No blockers."

A good one:

"Yesterday I finished the styles for the new contact form, today I'll be adding the frontend validation. I'm not sure if or what package I want to use for that yet so if anyone wants to give me suggestions later that would be awesome. No other blockers.

"Stand up" meetings aren't supposed to be "progress reports" but in reality this is what they turn into at most companies.

Either way, you want this information conveyed in one form or another and you want it to change day-to-day. The way you achieve that is breaking work up into smaller tasks.

Ask for help

Do not hesitate to ask for help! It's so important. If you're stuck and can't figure something out it's better to ask for help than to spin your wheels for hours making no progress.

Same rules apply when asking for help at your company as when asking questions on the freeCodeCamp forum or Stackoverflow.

Make sure you've thought about your problem before asking for help. What did you try? What are you expecting to see happen? What's actually happening? etc.

Or sometimes you might need feedback on how to approach a solution. Should you do it this way, or that way? Is there a better way that you didn't think of? If you've broken your work up small enough it should be easy to include someone in the discussion and go over pros and cons.

Under promise and over deliver

Estimating is so hard. When building software or websites things just take longer than we think they should. Developers can be the worst at thinking something is easy and just a quick change here or there only to have the thing be a bit more nuanced or complicated than they first thought.

Whenever you can, err on the side of caution. When someone asks how long something will take they will always be happier to see you get it done faster than you said it would, instead of longer than you said it would.

Some managers have a way of pressuring you into over promising. Don't do it! Let them be disappointed in your estimate. It's not their estimate it's yours. They'll be a lot more upset if you appease them by giving them the estimate they want when it's not true rather than the estimate they needed which may not have been what they wanted to hear.

Demo regularly

This comes back to splitting up your work into small pieces. You want to be able to show people what you've been working on as often as possible not just tell them.

Quick boring demos that happen often are far better than over the moon mind blowing demos that never happen.

Show people what you're working on and show it often. Doesn't have to be daily but think weekly or bi-weekly.

If there is no proper channel for doing this, you can record short screen casts and share the links in Slack or whatever communication tool you use. You don't even need voice over if you're not comfortable with that. Just a quick 10-30 second demo that shows one small thing you did. You can group them together at the end of the week into one Slack post or stitch them together into one video -- whatever makes sense to you.

If people are interested in seeing it, they'll look, if not, they won't. But people will definitely appreciate it and may even start following in your footsteps. I've done this for clients before and they loved it so much they started making it a part of their own internal process.

Take notes

I highly recommend developers keep a daily log. It's so helpful if someone ever questions what you've been working on and they're asking you to go back more than a day. I don't know about you, but I don't actually remember what I worked on two days ago. I have to go look at my notes.

This helps you cover yourself if a manager or customer asks, but it also gives you a place to jot quick notes about problems you've solved.

I love to add a TIL (Today I Learned) section to my daily log where I write at least one thing a day that I learned. Sometimes it's something about the company, or something about the business domain of the client I'm working for, or something about the code base or just a cool tool or CLI I found out about. Sometimes I catch myself getting stuck on a very similar thing over and over, and if I write it down it helps me remember what I'm supposed to do in that situation going forward.

Closing thoughts

Communication is probably the most important skill a developer can have. Being technically proficient is only the base requirement. I strongly believe the differentiator between successful developers and those who struggle throughout their career is communication.

You have to constantly work on it and as it turns out, most developers are not as good as they could be. If you make your focus to improve on the skill at all, chances are that you'll quickly become a better communicator than most of your colleagues and rather than getting canned for being bad at it you'll find yourself getting more promotions than others for being so good at it.

I also know that it could be said that good managers wouldn't let this happen in the first place which I agree. However where I work, a consultancy, we try to teach our teams to "not invite management". If you're communicating well people don't feel like they need to manage you. They also know what you're working on and when they can expect to see something. They learn to trust you because you communicate well.

I really hope you find all of this helpful and good luck getting back in the game!

Like what you read? Want to support me?

A cup of coffee goes a long way 🙏

Why not buy me one? https://ko-fi.com/danjfletcher

Originally published here: https://technicallyfletch.com/communication-tips-for-new-developers/

You can find the forum thread here: https://forum.freecodecamp.org/t/i-am-being-fired-after-one-month/447660

Day in the life of a Scrum team

Dan Fletcher — Thu, 03 Jun 2021 13:29:10 +0000

Preface

This isn't intended to be an attack on SCRUM. Just a thought experiment of a team trying to be agile and lets assume practicing continuous improvement. There are lots of problems with how they're working and they'll no doubt be brought up during the next retrospective.

Think of it as a snapshot in time on any agile team. There will always be flaws in the process as they constantly experiment and improve on ideas.

Personally I've seen this scenario play out a lot during my career and I think it highlights some pretty common problems that arise while we try our best to build software.

I'll follow up with another article but my goal here is to highlight the inefficiencies that exist while trying to distribute work to individuals rather than working together as a group (mob programming).

Let's build an app!

So you're building some software and it's pretty involved so you make sure that there's at least 3 or 4 engineers on the project (maybe much more).

You do a bit of planning and break up all the work into small deliverables. Everyone knows what they need to work on for the next two weeks and they start the sprint.

So you go to Jira and grab a ticket with your name on it and it's estimated with 3 story points. You're not supposed to map story points to time, but you know from experience 3 points means you can probably get the task done in about half a day.

Takes you about an hour to complete the task and submit a PR. Great! Ahead of schedule 😊 Good start to the sprint right? So you go look at your assigned tickets and grab the next one. This ticket is also a 3 pointer so you think the same amount of time (an hour to half a day or so).

You're team doesn't like to have long living branches and likes to keep PR's small and concise so the normal thing to do here is to cut a new feature branch off main rather than cutting a new branch off the one you submitted for code review. This works for you because your next ticket has no dependency on your previous work.

So you cut a new branch off main and begin your work. About an hour in, you're still not done but there's some feedback on your PR. Normally you'd wait to go look at the review because you know the cost of task switching but your PR is actually blocking another team member from getting their work in. Usually your team tries to avoid this from happening but you missed a detail during Sprint Planning.

Like a good team player you decide unblocking one of your teammates is worth the cost of task switching.

So now you need to switch back to the other branch. But there's a difference in migrations plus you were playing around with some data locally that you don't want to lose. So you back that up, switch branches, rebuild your containers and reinstall dependencies and rerun migrations etc...

You make the requested change from the code review and push up your work for review. The person who requested the change is now in a meeting so they can't check your updates right now. So now you don't want to just sit idle because that would be unproductive right?

You make the context switch again to your other task and rebuild containers, reinstall deps, rerun migrations and import your data backup etc. By the time you remember what you were even doing the other SWE gets out of their meeting and approves your PR. Which is great!

But now your PR is out of sync with the main branch and you have to rebase. But there's merge conflicts... so now you have to switch branches again to do the rebase and resolve conflicts. You rebuild, reinstall, run migrations etc...

You resolve the conflicts and push up the changes but you still can't merge because you have a 2 approval requirement. The other SWE who was blocked decides to help you out by reviewing too. While he's doing that you go on to work on your other task.

By the time you switch branches, and switch context all over again it's about time for lunch. After lunch you finally get some progress and you complete the task and submit a PR and add some reviewers.

Meanwhile the other SWE is struggling to get your first PR running on his machine. Some crap with Docker or something... So you decide to pair up and help them sort out the situation so they can do the review.

A couple hours later and after pulling other SWE's in to help you get the problem resolved and the code review continues. While you wait you decide to get some of your own work done. Before picking up a new ticket (creating more WIP) you check the code reviews and you're assigned to one.

So you do some more branch switching and context changing to start a code review but it takes you a bit to get up to speed with what the task even was. By the time you are fully understanding what you're even looking at you have a scheduled 1:1 and right after that there's a design review meeting you're required to attend.

The meetings are done and you have 30 minutes left until the end of the day. You try to wrap up the code review you're in the middle of but you just can't wrap your head around it after the last meeting. And now that you've sat there thinking and trying to switch contexts it's about quarter to and you figure F-it lets just go home 🤷‍♂️

Next morning at standup it gets brought up that there's a lot of code sitting in review so the team decides to focus on code reviews first thing in the morning before continuing on with new work. That's great!

You decide to continue on from you code review the day before since that's the branch you already have checked out. But there's also comments from yesterday sitting there unresolved on your first PR (that ticket that was supposed to take half a day to complete, remember?).

By the time you finish your review and submit your comments it's already a couple hours into the morning but you can finally resolve the comments made on your first PR. Pretty easy changes but you still have to reset your local environment to work on them. And by the time you get the updates pushed up the branch has fallen way out of sync with main.

Now you need to rebase, but yet again, there's more merge conflicts to sift through and you can't resolve these ones on your own. You want to pull another SWE in to your desk to help but they say they're too busy sorting out another issue on another PR and ask if you mind waiting until after lunch.

No more reviews left for you to help with but you still have two PRs waiting to go in. Your second PR is STILL waiting for review because no one has had time to look at it yet. You're feeling pretty blocked on all your tasks and there isn't much you can do until after lunch.

You're reluctant to pull more work into "in progress" with so much in the pipeline but you don't want to sit idle either so you pick up another ticket.

Cut a new branch and get going on that work but then you realise you need some stuff from another branch that's still sitting in code review that you didn't think about during planning. By the time you get that far it's lunch time anyway so you just forget about it for now since it's looking like your afternoon is going to be pretty busy with other stuff anyway.

Get back from lunch and that other SWE helps you resolve those merge conflicts in that first PR and get through them all but then they start taking issue with some of the changes in your work. This becomes a debate that lasts about an hour until you both agree that some of the suggested changes actually do make a lot of sense. "Ok fine." you say to yourself. "These are actually good points".

Before you start the new changes you recall that someone is still blocked by some of this work getting merged in, so you pair up with them and spend a bit of time isolating the changes they need so that they can cherry-pick those changes into their branch.

By this time, there's finally some comments on your 2nd PR and it also needs to be rebased. You decide since you're already in "rebase" mode you might as well just take care of it now. Switch branches, and contexts etc again, resolve the conflicts, resolve the comments, and push the updates...

Now you can finally focus on making those changes to that first PR but there's an all-hands meeting. You get back, you only have 30 minutes left in the day. You try to get as much as you can but it takes you 15 minutes just to fully context switch and by the time you feel productive someone wheels their chair over to your desk and asks for help with something.

Now it's 5 and time to go home and that first 3 point ticket you pulled in yesterday is still incomplete, the second 3 point ticket is still in review, you have another task that you started but haven't touched all day, and your name has been added to 2 more PRs that you haven't looked at yet and every other SWE on the project is complaining that code reviews are taking too long.