Episode transcript

Edit transcript

Ryan Burgess
Welcome to a new episode of the front end happier podcast. So clearly, I haven't figured out how to perfectly estimate my work not even close. This is actually our second time that we're going to be discussing estimating back in 2021. We spoke how to provide more accurate estimates. I'm not sure exactly how deep we went on this or what exactly we covered. But in this episode, we're going to really dive into how to estimate better and come up with more accurate estimates. So hopefully we give more information or do a better job than episode 124. But hey, we'll see what happens. Let's give introductions of today's panelists. Stacy want to start it off? Sure. Stacy, London,

Stacy London
Principal Engineer at Atlassian,

Jem Young
Jem young engineering manager at Netflix.

Augustus Yuan
Yeah, I guess this year in software engineer at Twitch.

Ryan Burgess
And I'm Ryan Burgess. I'm a engineering manager at Netflix. In each episode, the front end happier podcast, we like to choose a keyword that if it's mentioned at all, in the episode, we'll all take a drink. What did we decide today's keyword is planning? Planning. All right, so let's plan to take some drinks.

Jem Young
I don't know. Sounds good.

Ryan Burgess
So bad. All right. I'd be curious how each of you approach estimates for your work. Do you

Jem Young
remember those things from the 80s? You know, those magic April's? Shake them? Yep. And they give you? Right? Yeah. Sounds like how long is it gonna take Jem? I'm like, see if the eight ball says and I shake it? And it's like, not sure. So I usually give him I'm not sure. If it's really important, I'll come back and ask me again.

Ryan Burgess
I was gonna say how long does that not sure. Last, right, like it might hold up for? Okay, I'll give Jim some time to think about this. But I'm going to come back and ask and so you got to shake that eight ball the second time, right?

Jem Young
Well, now. So I have a whole escalating series of events that goes on estimates. So if they come back a second time after I give them the April, I say, oh, okay, well, why don't you file a JIRA for that, here's the link to my JIRA board. And then, you know, I wait. And if they file a JIRA, and I wait some more for them to follow up again. So this could be a couple of weeks later, and they're like, Hey, you get that Jeremy, like, yeah, we're really pruning the backlog, but we'll get right to it. So you know, maybe a month or two later, I might get a good estimate. And by that time, it's probably already done. And that way, I've impressed everybody. Like, oh, that thing you want an estimate, and it's already done. Right? Like, cool. Wow, Jim. So good. And that's how I do it. End of Episode goodbye.

Ryan Burgess
I know all you're joking here. But there is actually one thing that I really like that you said, there's not so much about estimating. But oftentimes people ask you for something or to do something. I really like the like, put it in a JIRA ticket, or can you write something up for it? Because I think sometimes people, it's really easy to say something right? It's really easy to go, Hey, Jim, can you just like build this component? And you're like, Yeah, sure, whatever, I'll go do that. Instead of hey, what are all the requirements? How are you thinking about this? You're putting a little bit of work on that person. Now, it's not helping with your estimates? Maybe, maybe it's, you know, buying you a little bit of time, Jim. So, hey, it's not a bad piece of advice.

Jem Young
That's not actually I do estimates. But I would say, at least for me, as an engineering manager on a platform team, the way I estimate is probably different from the way other people probably different from Augusta, Stacy and Ryan, you all do estimates on maybe more product oriented teams. It's on a platform team. I don't necessarily report to anybody, like if there's no pm saying like, once you get this done, let's do this. And then we'll do this and like there's a whole year planned out. We are the ones that drive we our own PMS, we drive our own planning, chairs, chairs, and we we drive our own roadmaps and milestones and everything along with that. So occasionally, they'll be actually not occasionally about half the time there's we spend our time doing external asks or so. But those are usually pretty broad, because I that's how it is across all platform teams is there's a long curve of understanding to understand what the problem is first, and then there's the execution phase. Maybe later, I'll talk about Hill charts if I haven't already. I do love Hill charts for platform estimations. But generally like a platform, we're working like quarters, because the size of the work we have to do in the amount of technical debt we have to unwind is so great that there's no like, oh, this will take two weeks or we'll do sprints because it just wouldn't work for our case. But I'm curious how the rest of you do estimates.

Stacy London
Do you do the do you do the swag method?

Ryan Burgess
Do you want to explain the swag method CAC scientific wild ass guess? that works, right?

Stacy London
Yeah. Just just just just pick a number. Go with it.

Ryan Burgess
You know, it's really funny to like Jim, you mentioned like the quarter based estimates, which, like I'm very familiar with, which is funny, too, is like, you and I are both in platform teams. My org actually does have PMS. And so you do orient around like, yes. What are we doing for the quarter and trying to plan around that? And and I do agree with you that a lot of platform work is often fairly long time. Like it's not just like, a few weeks or a month. But sometimes it can be and I think that going to the quarter, I'm not a fan of because I think there are points where you're like, it's really easy to say, oh, yeah, we're gonna get that in q1. When and q1 is going to come in q1, or you know what I mean? Like, it's not a clear date to people. And even Jim, you mentioned, like having stakeholders, right? Like, people, they do need to know some of these things. And I'm assuming at that point, you're like, Yeah, you'll you'll get it in q2, or it'll be done in q1. But it doesn't really tell them a lot. And so if you could say, hey, expect it for sometime in March, like that would be a lot clearer. So I think sometimes estimates can get used more than just like the quarter,

Augustus Yuan
I guess I'll add my perspectives, because I've had to provide us some it's for a few projects at Twitch and at Evernote. And and yeah, I think it really does depend on the project. Because I think you too, I think a few of you kind of alluded to it, like, depending on let's say, the project had a deadline, like for whatever reason, like some, some other team made some promise to some stakeholder and they now need to hit the state. Like, then that's when we we try to brainstorm, okay, we understand whether the requirements, let's estimate how much work that is. And that, you know, that's a lot of coordination with engineering. So like I will, I would partner with, like a product manager, to understand what the requirements are for the project, try to break it out into technical tasks, so that they can be divvied out. And if let's say didn't hit the date that they needed. That's, that's when I feel real bad. But the product manager really has to make some choices of can we cut scope? Like, what are some hacky? Should I maybe I'll come with some hacky shortcuts we can do. And here's some incurred tech debt that we'll have that we'd like to resolve as a fast follow for the project. So yeah, I feel like it really depends. Depending on the project. Like for some projects, I do not have like a strict deadline, you know, they're like, hey, here are the requirements, we don't really mind. We just kind of need to know when it will be done. So we can kind of help with the planning. You don't necessarily have to go through that phase of like, what are the hacky shortcuts? What are the what are the things we need to cut scope, you might actually even as an engineer, sometimes it's on we like try to encourage for engineering to push product managers to talk about, well, what's the future of this product look like? And we can kind of anticipate, like, what future work items we'll need to do. And maybe we can just do those things up front. So yeah, that at least that's how that's been my experience. So far. We also we do do sprints, but I'll be honest, like, when I break it out into technical tasks, maybe I'll put some story point estimates and we'll figure out how many Sprint's that will take. And that's how we get to the final date. I would say from my experience, still very date heavy,

Stacy London
I'd say. So for quite a long time. Now, I haven't had to do like deadline driven development or date based development, which has been, I think, pretty healthy. I think Jake based development is really unhealthy, or at least and a lot of orgs that do it that way can be really unhealthy. It pushes people to like, maybe work crazy long hours and put out shitty work because they're tired. And I'm not sure that it's like a healthy way to do software development. I understand why people want dates, I think it's very natural. It's like we're trying to plan we're trying to figure out what we can do and accomplish as a team. So like, I think there's a lot of good reasons why people want dates. For a long time I've worked though more of like, in either like Kanban or scrum sort of methodologies where you're kind of you're doing like complexity based estimates or size based estimates things where you're having like a whole team talk about, you know, we're working on building a new feature for a product and we just want to talk about, oh, that seems really complex or like maybe that's a large T shirt, t shirt size. And then you can kind of based on maybe the makeup of your team, what the skills are. You might have like a certain velocity like you might be able to get a certain amount of story point. It's done any kind of like, watch that over time. And as the team gels and works together and learn about, like people's strengths and weaknesses and, and all of those things like it's a very, it's not a science, it's like always very kind of specific to the makeup of the team. And then if you build something similar again, maybe you'll have a better idea of like, oh, that took us like four Sprint's last time or that took us to, maybe this time, it'll take about that. So like, there's ways of doing kind of quote estimation, that way where you're kind of narrowing that scope of uncertainty as you as you get closer to the thing. And I think the whole idea behind it was like, you don't try and estimate out a six month or a year long project when like, so many variables change in those six months. And the idea was like, Oh, well, if you break it down into tiny pieces, and you ship a little piece, and you get feedback from customers, and then you iterate, like, the idea is you build the right thing over time, and iteratively. And then that whole, figuring out like, yes, six months from now, on this date, we will deliver this very big piece of software that we're not quite sure it works or not like, you kind of throw that way out, and you just go this other direction. And there's a million blogs online about waterfall versus Scrum versus Kanban. versus, like, all these different techniques and why they're good or bad. And really, I think it just, it all comes down to the team. And the makeup of the team and the people, how well they work together their skills, those kinds of things.

Ryan Burgess
I'm definitely a big fan of iterating and learning because like, you're right, there's so many things that change and you're you're not quite sure if that feature is going to land with your customers or not, to your points on the data driven piece. Stacey, I definitely agree with you, it can cause some negative like culture, if you're orienting around a date, but I think it really depends on how you're approaching those dates. Like, I have definitely been a fan of it when you're striving towards a date. But being somewhat realistic, but even maybe striving to like, be Oh to to hit some milestone, right. Like you're you're aiming for that. And I think it's okay, if it slips, right. In that sense, like, it's maybe a point where Augustus mentioned, it could be where you're like, we're like a month out, and I thought I was gonna deliver this, but I ran into, you know, three dependencies that I didn't really think of, and that's actually not, it's gonna, it's gonna push me out two or three weeks, or whatever that is, you and the pm or the rest of your team can have a discussion of like, alright, well, we could just push out the date, and land that feature or whatever you're doing a month later? Or do we start to cut some scope or trick like there's trade offs, and I think that it can also help produce some of those healthy conversations. Now, where I don't think date driven has been effective, or, for me, personally, I found it very unhealthy is when I worked in agencies, because you've put a date to a client, really, I mean, you I'm sure, you could go back and ask for more time. But that's like not a great look for your company or agency that you're working for. And so that's when it really becomes an unhealthy environment, because people are working long hours to still land on that date. They're not cutting scope, because they promised X, Y and Z. And you can't cut something out of that. And so that has been my most unfortunate time with data driven pieces there. But I know at Netflix, we've done dates where even when we worked in the product, Jevon, you and I worked on the same team, where we would be like, Yeah, I think we can launch that August 15. And so you would you would kind of rally around that, just so that you had to put that out there and you're like, cool, we can get that out there and plan around it. But then you would have those conversations if the date was going to slip or something needed to change. So I think it's like it can be good in some ways. So there's not just like this open ended quarterly date, but it's tough.

Augustus Yuan
I just want to like, I love how you bring that up, Brian, like, I think it's so important to have good communication with your stakeholders, your manager, like, Yeah, cuz some people really, and you know, we go off of dates for many reasons that Twitch slash Amazon. And like, it's sometimes it can be intimidating to tell, hey, I know I said this is the date. But, you know, maybe a requirement was missed, or maybe there was just unforeseen complexity that no one really could have caught. I hope people like have the courage to bring that up. Because in your you know, your manager, your Pm, like they're, they're there to help you in those kinds of situations. seems to help kind of gauge how important is this requirement that we missed? Like, is it something that we actually need to move dates around? Like communication is just so important when it comes to project planning and execution? Because you it's like, there's a reason why it's called an estimate, right? Like did in this perfect world of, yeah, there's nothing else and we just code this for loop. Everything can be good. But then oh, wait, you have to handle this dependency that's 20, like 20 years old or something? And, yeah, just all these things can happen. We also

Stacy London
have like optimism bias, like that's a thing with humans is we always think we're gonna finish something faster than you're, we're overly optimistic about our capabilities and our abilities to work on things. And to your point, Augustus like not, you can't know like, it's not like we're building the same thing over and over and over and over again, like if they did, they'd automate our jobs away, we wouldn't be here. So like, it is an estimate meeting, like, we can't exactly predict it, because there are these things that pop up, and you just need to talk through it with everybody.

Ryan Burgess
Yeah, that's a good point is like our jobs do a lot of similar things. But it's never exactly the same exact problem that you're solving. And so it's really hard to, to estimate around that too. Yeah, I think this is hard. But I love that you Augustus brought up the communication, because I think that is an important factor that people don't necessarily say anything, like, they'll just be like, alright, I'll I'll bet my entire weekend because I said I would get this done, rather than having a conversation on what's realistic. And, you know, thinking about that. I'm also a big fan for like, when I've approached estimates, specially coding is not giving an answer right away, right? Like, sometimes people give you ask you that, take some time, you know, go dig in, look at some of the things like, you know, enemy and communicate that to is like, Hey, let me get back to you. But like, do some of that investigating? And planning. Cheers,

Jem Young
cheers, right? Yes, splits are helpful for prioritization. I think that's really kind of what we're coming down to is. Do I have three engineers work on this? Do I have one? Do I have five? And that's thinking, as an engineering manager, like, those are the things I care about, I don't, unless there's some sort of marketing driven date, which happens a lot with products where we're saying, like, Hey, we're doing a big marketing push on this day, we've already told the press, we're gonna launch on this day, we need to get it done, then, you know, it's all hands on deck. But again, it's about prioritization. That means like, Hey, I gotta pull people off of this project to work on this. And that's where that's what I think about when I'm doing estimates is, who are the stakeholders here? Is this internally driven? Or is this externally driven? Are we part of a cross, broader effort? Where we need to coordinate with other people? Or is it something that, you know, if we get it done this quarter? It's fine. If not, it's fine, too, because no one else knows. And like, we're the ones driving it. So it's a lot that goes into estimates. But they are useful. Otherwise, there's no accountability for anything. And like, I don't, I don't have this problem on my team. Obviously, I've got a team of great engineers. But there are instances where an engineer is like, Hey, are you done with that project? Yeah. They're like, Oh, no, you know, still working on it. You're like, okay, okay. We said to get it done. And if you don't like hold them to something, and then like, you're saying, Ryan, make them communicate, like what's going on each step of the way, then there's a problem there. And that's what we need to address. What we really try to avoid is the not the right word for it. But you know, the engineer in a corner engineers, we'd love to go into a corner and solve this problem and come back with it all solved, and presents everybody and everybody Ooh, look at them go. But in reality, like, that's really bad for a team for it to operate like that. You need to have like, constant transparency, like, Hey, how's it going? You said that you get this done in q1? It's now March, the end of March. Where's that? Like, Oh, we didn't, we didn't deliver it. Like, we need to know these things ahead of time. So that's, to me, that's what estimates are all about. And I agree with you, Stacy, I'm not a fan of date driven estimates. And less, like I said, there's some external dependencies otherwise just puts needless pressure on on people. And if there is a date, it needs to be justifiable. It's like, why, why is it this date? Because the CEO said, so like, and I've definitely worked places where the CEO, you know, kind of forced our hand in those places and or is it just an arbitrary day that we can push back if we don't want to incur more technical debt by moving too fast on this particular problem? I like that.

Stacy London
I like that idea of like, using the estimate is just a way to have like, good conversations about prioritization. Like, even if you don't do like a date, estimate, you can still have those prioritization conversations with like, complexity estimates or size based like I've had good Congress. It's rare said like, oh, this, I think is like kinda like an extra large amount of work. And this is why like, there's these pieces of it that make it complex. And then like talking to a product manager or the designer and the team to be like, well, could we chip away at that? Like, maybe we don't need to do this part, this like part of it that makes it more complex? Can we reduce the complexity this way? And then you start having those, like, good conversations with your team?

Ryan Burgess
Yeah, I'm a fan of the t shirt sizing, especially right off the bat of like, Hey, we're gonna go look at this effort, because you are having that conversation. If, say, it is a product manager who's, you know, typically running the strategy of like, what types of features are invested in, you know, we're talking a lot about a product here. And they see, oh, that's an extra large, you know, for that piece, they might be like, that's not worth it, right. And so right then in there, you can start to have a conversation. And I'm a huge fan of that, or, Oh, that's really small. And like, we could absolutely get that done quickly. You just kind of get everyone on an equal footing or thinking about those and having those conversations, and you had no dates there, you had no like, Hey, we're starting tomorrow, or quarters or anything. It's just literally, if we were to do this effort, it's an extra large, it's a small, it's, you know, medium, whatever. And it gives people a little bit of understanding of that, because we've

Stacy London
I've had it like where the team would end up like talking even like sight, size base, like doing the Fibonacci sequence stuff for like Scrum. You know, like, Oh, it's a one, it's a five, it's an eight. I've had teams where we end up talking so much about the number. That's really not the important conversation. It's like, the important conversation is more about the feature and like, how we're going to build it, and what's the hard parts? Or how are we going to test it, though, like, that's the better conversation. So at one point, like we've moved away from even the Fibonacci stuff, because people are obsessing over numbers too much. And we went to like, the t shirt size, because then we got into better discussions about the product that feature itself. And so I thought that was interesting.

Jem Young
I'm a big fan of T shirt sizing as well, because it's, it's a flexible measurement that's relative to your team. So like, as a platform team, if I say something's XL, that means it's probably gonna take more than one quarter probably need two engineers on it. There's a lot of investigation we need to do ahead of time to discover like, how long is this actually going to take? Hence, it's an XML because I know roughly, it's going to be a hefty project. And that's relative to me, and like the systems that I work on. Whereas if I come up with the small, I know, that's less than two weeks, it's a well, scoped project. We know exactly what the problem is, we know exactly how long it's going to take. Those are pretty rare. We end up more in medium large categories where we're like, we're not sure. But we don't think it's gonna take more than a quarter. But yeah, plus one on T shirt sizing it plus plus 10 on spending too much time planning to plan. It can just, it seems like you're being productive, but you're really not. And it's like a trap. You follow until you're like, oh, but we're planning we'll have such a clean, well, polished roadmap, which that never happens. Yeah. I do not believe in well, polished roadmaps, if you're doing things correctly, because things are gonna go wrong. Like, I think what my favorite quotes is Mike Tyson, which is like, everybody has a plan until they get hit in the face. Which is true. Like, it's, it's a beautiful plan, until the CEO has some good idea, or the pm comes in, or marketing changes directions and said, like, hey, we need this. And, you know, that's just how it goes. And you have to kind of build that into your planning where it's loose enough to have to give the team an idea about what they should be doing next and what their priority is. But flexible enough that things don't collapse if you suddenly have to pull this project because some other priority came in.

Ryan Burgess
Yeah, flexibility is key. I agree with you, Jim. Like the full roadmap. That's like all perfectly planned. spent months planning doesn't make sense to me at all. It's it ends up being really confusing to you, or you've spent so much time doing it, instead of executing and learning as you go like, because to your point, you need to be flexible to pivot. It doesn't even have to be a request from anyone. It can literally be, you know, learning something in your product that like customers aren't even, they're not even down with this feature. Or they're like they're not using it or it's not the right thing. And it may might still be the right thing, but you have to pivot a little bit in how you approach that. But if you have this perfectly curated roadmap like that doesn't really leave room for any iterations or thinking outside because you just didn't you can account for those things that you learn as you go. We kind of touched on this a little bit too, but like we mentioned that it helps with planning cheers. Why why is it helpful to estimate your work?

Augustus Yuan
I think I think we touched on it in terms of prioritization. But I'll speak to a practical example that I've seen in companies, especially like my organization, which is very money focused, you know, we're part of the monetization or, you know, your project, that time you spent working on that project could be working on another project that makes money. And there's there's an actual trade off there now, right? Where if I come back, and this is why sometimes there's pressure, even on engineering to say, hey, we really need to, like figure this out for quarterly planning, like whether this project is like, Can we do it within a quarter? Or does it look like a whole year kind of thing, or, or two quarters or whatever. Because if you're going to, if that's the case, we might not want to do this project right now. Because there's these other projects that can be done in less than a quarter. And they'll make like, maybe less, but more than half of what that project would make. And so it might be within the company's best interest. So let's just focus on that first. So yeah, definitely, definitely, it's super important for your stakeholders to be aware of the estimates.

Ryan Burgess
Yeah, I think it's like, even to your point, Augustus, like gears is definitely monetary. So it's, like, easy to kind of measure that. But I think at the end of the day, even if it's not monetary, it's like, what's the impact, and I think, sometimes a, you know, a small effort could be really large impact. And maybe that large, extra large estimate could still be very impactful. But you're like trading off against your portfolio of work like there, you can't get it all done. I don't think that teams are getting all the work done. You have to prioritize. So I like that you call that out? Do you all use tools that help you? I gotta admit, I've tried so many different tools for prioritizing or for estimates, but I'm curious what you all use.

Augustus Yuan
Okay, I want to, I swear, Stacy didn't pay me to say this, but I I personally. So I know t shirt sizing is amazing. And plus one to what Stacey said, you know, whatever the team feels most comfortable in. That's what you should use. You know, there's so many different ways. My team uses story points. And we we learned that Jira, I don't know when they launched it, but they have this thing called Agile poker. Or this basically, it's a way for you to like get into virtually on the JIRA board, and you can estimate. And that feature was really, really helpful during COVID When we were all remote, because someone who's like the moderator can select the ticket that they're estimating. And people who put the estimate that they think it is, JIRA will auto populate, hey, here are all these other tickets you've estimated with that story point value. And it kind of gives that person like a quick glance at Oh, wait, is this the same amount of work? Is that other ticket or these other tickets? And can I just kind of level sets them and put some accountability on like, understanding? Is this the right estimate? So So that's been such a awesome tool that we've used?

Stacy London
Yeah, definitely. I don't use JIRA at the moment. But I have quite a bit. And yes, we've done all those kinds of like, strict scrum very, like Fibonacci sequences, story points. We've done the t shirt sizing thing. Right now, the team, my mind, we were using Trello, just because we're building Trello. So it's good to like, quote, dog food or use the thing that you're building. So we were using more sort of that Kanban style approach with the Trello board. And then we actually had an agile tools power up that the community, someone in the community built, which added stuff to Trello cards, so you could put story points on them. And you could see you can get some reporting and stuff out of it, like, make it a little bit more robust, I guess, than what you get out of the box with Trello. But I might be switching TV soon. And I might be back in JIRA, we might be doing some more sophisticated tooling to do that process.

Ryan Burgess
dogfooding Jira, right. Yeah, exactly.

Jem Young
I guess as you said it best use whatever the team is comfortable with. So we don't know we kind of mix it up. I used to use Google Docs and I make a big table. And I estimate it and then it's up to the individual informed captains of the project to track things the way they want, as long as it's progressing in a way and there's like evidence there, they're moving towards these like, well, well formed milestones then I don't have a problem with it. We collectively do not like Jira, I I think it's just like you really have to as a team like all buy in or not. And if like one person is doing it, no one else's it's kind of a waste and I don't know um, up, I'm fine with it if we were all gonna do it, right, but I don't know Jared does not have a lot of love in my part of the world. I think

Ryan Burgess
JIRA across the board is no one's like loves loves Jira, but I think you've said it well, in the sense that it is a very powerful tool when everyone is using it. It's great. I've worked in Agile environments that are you using it for story points. And, and this is, this is a long time ago that I think of when we are really following JIRA. And so I'm sure there's even a lot of new features that I couldn't even speak to, but I've still used it at my time at Netflix, but I find that not every team uses it at Netflix like some teams do. Some some people do. It's like a mix. But I think the power is when you're all using a tool and understanding it. And I think that's where JIRA really works well. Similar, Jim, I've I've seen it all in like the last few years I've seen like spreadsheets, Google Docs, what else? We've definitely seen Trello boards, air table, air table. Yeah, that was another one. Yes. Kota.

Jem Young
Monday, we have like the spread across Netflix on like, what people want to use.

Ryan Burgess
And I think I'm all for it. It's like don't don't fight on what we're, you know, what's best for the team, like Augustus said, I think you all have to understand it, though, too. Because sometimes, I have seen it where someone's spins up their own version of a spreadsheet or a Google Doc that you're like, but we kind of already have that it was just because they didn't fully understand it or like, oh, I needed more of a Gantt chart, and you're like, okay, but now we have to have two moments of truth. And like, that's not good either. So I think that's one thing I would say is like, pick one Don't Don't try and do multiple tools. I'd be curious, like, we maybe touch this a little bit. Why is estimating so hard? Like, you know, we I don't think I've ever given a perfect estimate. There's always something that comes up or there's something there's always something that I didn't account for. But I'm curious, do you all have this problem, or it's just me,

Jem Young
Stacy said it best earlier in the episode where Stacey, I believe you said, if we can get a perfect estimate on something, then we could just automate it, we wouldn't need engineers, or just be we just be a service or a tool we use and make thing and we're all done. That's why I spending targets. We live in imperfect worlds with imperfect systems with imperfect people who have a different idea of coding and naming and the right patterns or the wrong patterns and how to communicate it and all sorts of variables that go into software engineering. Hence, you know, estimating is difficult. You're You're guessing at best, and no one's ever got this right. I think people have tried many, many times. But the fact is, at the end of the day, we're all humans with our, you know, our flaws, which which make us beautiful, but also make it difficult to put us in a box that is easy to understand. So I can say personally, on my side, some things that go into what make estimating difficult on a platform team is a technical debt. Every platform team carries some version of technical debt, some some amount of it, it's never a zero, it'll never be zero. If platform team had zero technical debt, I'd question if they're spending their time correctly. It's kind of just a trade off we make. But part of that technical debt is discovery. And I mentioned this earlier in the episode and a good friend of ours, Aaron, Aaron lurch who also works in Netflix, he introduced me to the concept of a hill chart. And a hill chart is essentially when you have a really big projects, there's a it's a hill, so picture a hill in your head, and then picture a dividing line at the apex of that hill. So at the top. So you think in a perfect world, there's a hill and then in the middle, you climb up to the top, and then at the on the other side is the execution. So the first part of the hill climbing up the hill is discovery. The second part going down the hill is the execution. So in your mind, you're like, Oh, it's a perfect, beautiful, rounded Hill, everything makes sense, we can perfectly estimate how long it's going to take to get there. But in the real world, especially on a working platform where you're dealing with these really massive systems, sometimes the hill is skewed, sometimes the hill is goes all the way to the left or all the way to the right. Sometimes the discovery phase, like finding out what the problem is, can take entire quarter. And then the execution is actually really short. You're like, oh, really, it's just a library change or something like that. Sometimes it's really, really short, like the discoveries like, here's the problem, we need to fix it. But the execution, it turns out, it's really complicated because everybody using your platform had some sort of different implementation which you now have to standardize. So that's why I like the visualization of a hill chart and I tell it, I share it to my team to let them know like I understand discovery part is really difficult like trying to find out what the actual problem is you need to solve can take a long time to, but that's part of the work. And we have to estimate that as well. The other one is support, we we spend a good portion of our time supporting the engineers using our platform. So we can't tell you week to week how much that support is going to cost or what it's gonna take. And estimating is really difficult. And that's just me and my one corner of the universe. On why estimating is difficult. I am sure everybody has their own stories, and maybe bad stories of why estimating can be difficult.

Augustus Yuan
I'll call out two that come to mind. One is cross team dependencies or initiatives that may come up. So you and it depends, you know, maybe if you're a startup, this doesn't happen as often, but definitely at big companies, if you're working on a feature that may touch or involve multiple teams, like coordinating with those teams on their different parts, and you know, all the different discussions of like, what can what can get done by their team, what can get done by your team? Does your team need to pick it up? Then all of a sudden, your engineers have to absorb? How do I work in this new code base. Sometimes the other team might have some initiative, oh, we're going to refactor this entire flow that you were very dependent on. And we are hoping to hit this date of finishing the migration. So that that it's like, it's interesting, because you know, maybe you're not estimating those exact pieces of work, but effects timelines, which is what a lot of people care about. So that's definitely made things hard. So I'll be honest, I've even been on projects where sometimes the team is so busy, that you have to estimate the work that is on their side, and you have to pair with an engineer there really understand what's going on. So that's a huge leap of complexity. The other thing, actually, Ryan, a little bit you said about when you commented to Jim, about having people write a formal intake of or ticket of what they want, you would be surprised how many times requirements get missed. And it can be such a nightmare to not to, like, untangle what the what the correct requirements are. And that is like such an important part of the estimation process working with the stakeholders, the product manager, like what do they really want. There have been so many times I've worked with the PM, and you know, not blaming, not blaming anyone, but I've worked with so many PMS that have said, Oh, we want to like redesign this feature. We want everything that it does today. And then we want these new set of features. And they kind of think everything that it does today is the requirement. And that is good enough. But I'll just speak for as an engineer, there's a lot to unpack in that requirement. There's might be all these different things that it's done today, that I have to kind of dig and chase and might be things that can't be supported in the new in the near future, it might conflict with the new feature that you're requesting. So that's like sometimes a bunch of stuff that has to be unpacked.

Ryan Burgess
And I'm so glad you called out dependencies Augustus, like I think that that is oftentimes one of the hardest things is you're working with other teams or other engineers, or even just working microsystems man that like, you just you understand yours, but you don't understand the one next to you, but you rely on it. And something may need to change on that. And then there's contracts and there's all these things that it just becomes very complicated. And it's you know, gets back to No project is the same. It's always very unique. So I'm really glad to call that one out. Because I feel like anytime it is outside of your own team, or own code base, it just becomes a lot more complex. And it's already complex in your own code base. I know that but adding more on to that just makes it even harder.

Stacy London
Just a couple of things about the estimates, I found hard over my career. And some of them are like we talked a lot about people. But you know, if you put a junior engineer who still may be learning the codebase, and learning patterns and learning libraries and learning frameworks and trying to piece all these things together. If they were to build something out, that estimate is going to be very different from someone who maybe he's already familiar with the codebase has a bunch of experience using the framework already has built something kind of similar before. You know it has that history, like that estimate would be very different. So it's really hard to have an estimate for something that's universal across people's experience. You have to like, come together as a team and figure out like what is your team capable of in a timeframe and that's that that's where they have to like, oh, we need to set up time to make sure we have mentoring or repair program where we do stuff together to move things forward. And all of that is why estimates are hard, because like, how do you estimate how long paring is going to need to happen for someone to become super efficient? Like, that's not a thing you can really estimate because it's humans and learning something about that, that I found. That's something that's been very difficult. And then the other thing I find really difficult. And, Jim, I think this is something I found interesting about your comments about platform stuff. Sometimes, I would imagine, especially at Netflix, you're you're maybe building something that doesn't exist in the industry, like there is no prior art. There's no example that of something someone's built just like this before. So it's total r&d. And how do you estimate how long something's going to take? If you have absolutely no idea? And I think that's where you have to start doing, you know, spikes, or maybe what you're talking about Jim, the discovery thing, maybe you're like doing experiments and trying to figure out how to get your head around the problem. But like, that takes time, too. So that's why it's all I think, quite hard.

Ryan Burgess
Oh, yeah. Like, I think like even sometimes having a deliverable of literally investigating is, is should be part of that, right? Where you're like, Yeah, we have to investigate or evaluate options, right, because maybe it's implementing a new library or something, you should be doing a little bit of that, like r&d, which will help you hopefully tighten up a little bit more on the estimate. But it's, it's never perfect. I love that you almost called out to paired programming, Jeremy called out support a lot of those things, it's really hard to estimate for, you know, support, if you're on support for a week, I would just almost say like, yeah, you're probably not getting much work done like it. Or if it's a day, or I don't know how long support lasts for each team. But you kind of just have to chalk that up as you're like, I'll be lucky to get some work done. But then also accounting for vacations. People aren't really always good about that either, or meeting heavy days. And so you kind of have to throw that into your mix of thinking about is like, how much realistic time do I actually have working on said project? So yeah, I think those are all really good call outs. Before we dive into pics, we've talked a lot about estimates here, which is awesome. But I would love leaving the listeners with one piece of advice. What would you each say to help improve your estimates moving forward?

Jem Young
I'd say Don't forget to bake in time for tests that is so often overlooked, or that I can deliver the project X. I'm like, oh, did you include all the tests you have to write in there? And they're like, no, let's go ahead throw another week or two on there. Just Just in case, in QA in general, people often miss that. So don't forget to include testing and QA in your project estimates.

Stacy London
Yeah. And we kind of joked a little bit about the like buffer, like, take your estimate and double it and padding or whatever. But in some ways, it's not a joke that you do need some wiggle room and some space to account for the things that pop up that you didn't, there were unforeseen you and you weren't sure about until you got into it more. So you do need some of that. So it's like, take your optimism bias and make sure you're put a little pessimism in there just just to give yourself a little space. So you can think and iterate and like handle those unforeseen things.

Augustus Yuan
I'll say, you know, sometimes, when you're given a project to help estimate, you kind of just want to estimate it yourself and go with that. And I think it's really important to make sure that the team is involved in the estimation process. It's not only like a really good thing for like onboarding and helping the team build this shared mental model of like how much effort certain tasks are. But you'd be surprised how often someone will catch something that was missed. This actually recently happened for a project that I was planning. I had the requirement defined. And someone just asked a pretty basic question like, oh, how this requirement get fulfilled if we're doing it this way. And I had a last minute realization like, oh, my gosh, it would it I totally missed this. And it was like, it's better those things are client caught early on, you know,

Stacy London
I guess it's like you're saying, like, not just the happy path, or you know, like, everything's working perfectly. There's, you know, the users doing exactly what we expect them to do. It's like, you have to account for like error states and how people recover from things not going right. Like that kind of stuff you should think about too.

Ryan Burgess
Wow. All great advice. I mean, I got two little points here for you. Don't let your manager estimate for you. I'm gonna call it out as a manager, but like I have been there where managers are making the estimates for the team and I think that that's probably not the best they should be getting input. but from their team, and then when I've ever approached tackling like an estimate, I want to buy myself time to actually look at what I'm trying to solve. But really breaking it down into smaller chunks. I find that that's really useful too is like thinking about a problem not as the deliverable, but like, what are the pieces that get me to that deliverable? So that's always I've found still not perfect, but it's got me closer, or at least I've felt better about how I've broken down the project and been able to estimate it. Cool. Well, let's jump into pics. In each episode, the front end happier podcast, we'd love to share pics of things that we found interesting. And just want to share with all of you, Stacy, you want to start it off?

Stacy London
Sure. To music picks today. The first one is a song called Bala rocky by midnight. Hi, there, percussionists and composers. I think they're partners or spouses together, they kind of create a lot of percussive fee things mixed with contemporary instrumental music and since So, that's a really great, really great song. I'm listening that on repeat. And the second pic is glistering by Alison Lorenzen and midwife. It's actually a cover that was originally written by Gavin Rossdale. And

Ryan Burgess
I was wondering, yes.

Stacy London
No, like 1994 or five. Yeah, super old song. I don't know whether or not you like Bush or not. That's a whole other discussion. But I thought that this was like a slow core cover of it. And it's really chill and kind of sad and lamenting, and, but it's really well done. I liked it a lot. So check it up.

Ryan Burgess
Very cool. Jim, what do you have for us?

Jem Young
I also immediately thought of the bush song when I cuz I was like, that's not a common phrase you ever hear in a song? So I guess we're just seeing here. So let's hear. Yeah. I have two picks. For this episode. The first one is a show on Netflix that I started watching I binged entirely through it's called physical 100. It's a Korean show. And it answers that question that we've all been asking. Who's really more fit a wrestler or a gymnasts? No. It takes a variety of people from a probably the widest backgrounds that I've ever seen, like cyclists, gymnasts, and wrestlers, and CrossFitters and rock climbers, and you name it, there's like someone there, bodybuilders things like that. And it like puts them head to head in competitions. And it's always surprising because you're always like, Oh, I know who's going to win this particular competition. But like, you just you really don't know there are things like endurance and strength and all these other things that go into it. Once you start watching. And you can get over the really, I think it's a it's endemic of like Korean TV that I've noticed where they tend to stretch things out a lot more than American television, squid games, a good example where they like really, really like you could just cut to the chase five minutes earlier. But if you can get past that physical 100 is a great binge, because you're always like, who's gonna win next, this person or this person? Anyways, I really enjoyed that. Probably one of the more enjoyable shows that I've watched. My second pick is Valley silicone picked. And I have to clarify because I was speaking with someone the other day, and they're like, Oh, how did you like that? Uh, that lomi food composter that you made in another episode. And I'm like, wait, you think my valley silicon pics are just reviewing things that I bought? They're like Yeah. I thought that my tone was really clear. But apparently not so dear listeners front and happy our regulars. Time for my valley silicon to pick where I pick things that are ridiculous and too expensive. And they only exist because we hear Silicon Valley get paid too much money. And I have not purchased any of these. So this next valley silicon pick comes courtesy of Andrew from Twitter. Thank you for the heads up on this one. So I have to ask you all like is this Ryan Stacy. Have you ever been like, you know, I've got my water bottle. But I also want to work out or deal with the answer something. How am I gonna record this? Has that ever happened to you? Yes. All the time. Hmm. Well, today's pick for the low low price of $80. You can get the Ringo it is a regular water bottle. But it has a magnetic clamp on the top so you can put your iPhone to record whatever you're doing. And like I know there's that's it there. There's not really more detail to go into there other than it's it's a water bottle with a magnet on it. And it's $80 you can record your next tick tock dance or something like that. I don't know. I don't know why they teach their own. You know, this isn't like super expensive and valid Silicon term. So you know, so it's on you, but I don't know,

Ryan Burgess
I guess you could watch Netflix while you're running or on the treadmill? I don't know, I'm just

Jem Young
like, you could just leave your phone against the water bottle, and it would accomplish the exact same thing. So I don't really understand why this exists. But you know, that's why it's Valley silicone. And those are my picks

Ryan Burgess
right on Augustus. What do you have for us? Oh,

Augustus Yuan
yes, I have two picks. One is a case study of Windows XP. And it's just a quick case study Article of the guy who made the Windows XP logo, and kind of his explorations of like, the old windows logos, and he just talks about some of the design challenges or the field that they were trying to go for. So I always love like, reading these kinds of case studies of how they make the logo of what you eventually see, you know, because there's a lot of thought that goes into it. So yeah, check it out. And then my second pick is web kid blog posts of Web Push being enabled for web apps on iOS and iPad, thinks in 16. For and yeah, the article speaks for itself. But this is just like such a huge update to have notifications available for web apps. Like, I think that was like one of the biggest things that like native apps had. And well, of course, among many other things, but like being able to have notifications for web apps is like such a huge thing. For

Jem Young
those who don't know, Safari was the last holdout on PWA s, progressive web apps, they they've taken forever to implement it. So it's really great that they're finally letting Web Push. But it's like years later, like years later behind everybody else. So oh, so when for the web. Good. Good pick, I guess this.

Ryan Burgess
Alright, I have two picks not related on the topic at all. But we have talked about chat GBT, and quite a few episodes this year already. I found a really great article. I mean, it goes in depth. But it talks about what chat GBT is doing and why it works. It goes into depth. Like I don't even know if I finished the entire article. But it was really interesting. Definitely worth checking out if you want to better understand how the AI is working. And then my second pick is one I don't know that I would normally pick but I realized that everybody's working remote. More and more people are using mics. We use it for the podcast. But I recently switched to an arm that kind of goes from the behind the desk and over. It's the Elgato mic arm LP mic stand. I really am enjoying it. I like it a lot. I can just kind of pull it when I need it. Shove it aside when I don't need it. My hands are still available to type and then I don't have a mic in my face, which is kind of nice. So I'm really liking that. been using that for a couple months now. So that's all I have for this episode. Thank you all for listening to our episode. Hopefully we've helped you estimate a little bit better. It's still hard. If you want to subscribe to our podcast and really find us on whatever you like to listen to podcasts on. Follow us on Twitter at front end H H. Any last words

Augustus Yuan
we should have been planning our last line