Episode transcript

Ryan Burgess
All right. Welcome to a brand new episode of the front end happier Podcast. Today we are going to be talking about an interesting topic. Have anyone ever estimated a project on time perfectly? If you have I'm super impressed. Estimating Software Development is never easy. In this episode, we will be talking about how we approach it, and hopefully have gotten better at it maybe worse. I don't know. But we're going to talk about estimating today. Let's go round and give introductions of our panelists. Do you want to start it off?

Stacy London
Sure. I'm Stacy London. I'm a senior front end engineer on Trello.

Augustus Yuan
My name is ECOSYS here, and I'm a software engineer at Twitch.

Shirley Wu
Hi, my name is Shirley. And I'm an independent creator of data visualizations.

Ryan Burgess
And I'm Ryan Burgess. I'm a software engineering manager at Netflix. In each episode of the front end happier podcast, we like to choose a keyword that if it's mentioned at all, in the episode, we will all take a drink. And what do we decide today's keyword is Scott's go scope. So if we talk about scope, scope creep, I'm sure this word is going to come up, we will all take a drink. Alright, I'm curious to start with? How do each of your teams approach project estimating?

Augustus Yuan
Excellent question. I can start off, it's actually funny because at my previous company, Evernote, and at Twitch, we go about it this a similar way. So generally what happens is, let's say we get some project that comes to us. We we follow what Agile does. So there's this concept called story points. And what for those who aren't really familiar with the term, it's basically, when you're assigning a feature, you have certain number of points that you associate, which kind of represents an amount of work. There's like a whole whole like theory about this and how this is like an effective way of estimating. And the team itself kind of develops this idea of what is a baseline story. So how much time it would take and, and effectively what you do is like in a given sprint, you can kind of have an estimate of how long it takes all of your engineers to finish a certain amount of story points. And then when people estimate features, they can kind of assign individual features a certain amount of story points, and then you can figure out based on how long your Sprint's are, how long a project will take. That's kind of like high level and we can probably dig in deeper, later. But kind of curious how others

Ryan Burgess
do it. One thing I want to ask to as a follow up and maybe to others, if you're doing Agile, is there a scrum master? Is there someone who that's their role?

Augustus Yuan
Yeah, like for us, our team, we kind of have not someone who is a dedicated Scrum Master, we have technical PMS, who sometimes serve that role. But honestly, we even have teams where engineers will serve as the Scrum Master, I think the Scrum Master does not necessarily have to be a dead dedicated role. I think it's nice to have one. But it shouldn't be something that is like, confined to like, like, oh, there's no Scrum Master, we need to hire someone, you know, I think anybody can pick up the torch and do it

Stacy London
Atlassian as a whole, I think, you know, I mean, they've been, you know, pushing sort of Agile software development practices for for quite a long time. And they built, you know, tooling around it. And juror, I think was kind of built around, you know, how you track your practice, your project, and your development lifecycle and keep track on things. And then each of the teams, I think, kind of do things, not necessarily a completely different way or their own way. But I think there's some freedom for like the teams to kind of pick like what works best for them. So like, if you want to, you know, do a more Kanban style of, of managing your your feature work and product work, where that comes from, I think Toyota and factory, it's kind of atmosphere where you're, like, show how much work is like in progress. You can do that kind of style, if you'd like. There's also like, you know, I guess just mentioned scrum sort of style, where you have story pointing, I think story pointing came from the scrum methodology actually don't know the original, I have to look up if that was the first sort of like methodology that was that define that. But the idea of like complexity based estimating, where you're not saying like, I'm going to get an exactly this feature done with exactly these people on exactly the state, which is kind of a really, really, really, really old way of doing project management, which is like waterfall methodology where you kind of locked in all those three things. And then, you know, a year later, you're still working on the thing that's late and you've you've not, actually that didn't work. Anyways, so like that. Agile Manifesto came about. And that was not even that didn't prescribe any of these like specific things that we're talking about, like, agile is more like philosophy. It's like people over process and those kinds of things. So the philosophy of that then like, I think Scrum took that and said, oh, people still want more definition. Like that's like, and I think a lot of companies probably still wanted more definition because they, they still want dates. Everybody wants dates, once it's finished, when's the project gonna ship so like, Scrum tried to fill that with with some more process. And so Trello as an example, I just moved on to that team. And so like, they each each feature team I think does their own those their own thing. Like I'm the particular team that I'm on, we kind of follow like a scrum inspired kind of thing. We have Sprint's that are a couple of weeks we do stories, we have size based estimating or complexity based estimating of points. So we do a lot of those kinds of things. But it was it isn't so much like, there's there isn't like a culture of sort of like, this deadline comes and if you don't hit it, people are going to be like penalized. There isn't like that kind of cultural aspect to it. Like you're all striving to finish the thing. But it's not the end of the world. If you don't you want to ship quality work, you want to make sure that the thing that goes out is the right thing. So the date maybe doesn't matter as much as the thing being really well done. So there's like trade offs there. I could have been talking for a long time I can I'll stop. I love

Ryan Burgess
it. I loved it the way you described it, it really it hit a lot of like how I've thought about it or even working at Netflix is I think that not every team is exactly the same. And I do like that. Because then you do get into that point what you said Stacey is like process for the sake of process. Like if it's like, well, this is just how we do it, like follow it. And it that doesn't. To me, that doesn't work. Well, it's like you need to figure out what works best for you and your team. And that might change over time, too. And so I think that, to me, that's what I really liked hearing, I've totally worked in environments where it was very like Agile to the tee and like following all the like having a dedicated scrum master and point system, I think it was two weeks sprints where I feel like now at Netflix, in my experience in both the teams that I've been in, it's been more flexible and more almost iterative. It's not waterfall. And it's not necessarily like that extreme agile case, it's more what works best for us and figure out how that works. And, and it's iterative, because we're constantly evaluating what worked, what worked and what didn't work, and to try and improve that and how we work and estimate, surprise, I don't think anyone's gotten estimating perfect, as I alluded to, as we started, but I think there are ways that you can start to get better at it.

Shirley Wu
Yeah, I'm just gonna, I guess add in my experience with it, which is that like, when I was at a full time job, at my last startup, we did have, we very much followed agile means very much has story points. And we actually had a dedicated scrum master, because we had a dedicated project manager and was really nice. And I think I took a lot of that with me, when I went freelance and I went independent, I did not take any of the task writing or the story writing with me, was the bar that I honestly dislike the most. I think all of those years of estimating how long like I think the practice of dividing a project into features or stories, and then dividing those features slash stories into tasks. That kind of practice, I think, is what I've taken with me. And that's something I still do in when I work with clients. And so, for me, it's a little bit different. Because usually, when I work with clients, they come to me with a data site. And then there's up to three different parts that I'm trying to estimate for in my project. And that's the data analysis side, the design side, and then the, and then the coding slash implementation side. And then sometimes it's just the design and the code. And sometimes it's all three. And it's always that the data and the design, I have no idea how to estimate like it literally it's like you either like you know, hit like gold within the first day because we just happen to have the right hypothesis and like it just happened to work. And either that or I just I like we spent months trying to like explore and figure out like what our angle is and what we're trying to do and what the design should be. So I always think of like design as that kind of like gray mass that I have no idea how to estimate by this point. I've gotten quite actually decent at estimating the coding side, because I think maybe I don't know if this is true for many people. But for me when clients come to me for projects, they're usually coming to me For a skill I already have. And so that means that oftentimes the projects I'm building for them is things that I've actually coded before. And so even if it's like, you know, something that's kind of a little bit different from before, like I generally know, because it's I've solved, you know, 50% of the problem, or like, you know, 70% of the problem before that, I have a pretty good idea of estimating the word. Um, but I still do like 1.5x or 2x. The time I think it's going to be, and that's kind of like the kind of the ballpark number of hours I give my client. And we were mentioning this earlier that like, for me, estimating is so so crucial, because I still build by project. And so roughly how much I estimate the project to be like, I have an internal hourly slash day rate, that like, if I estimate way incorrectly, that means I'm losing money. If I estimate, well, then that means I'm making what I should be making.

Ryan Burgess
Yeah, I love that you brought that up to because I think there are times where, like, Stacey, I think it said, like, we're not going to be worried so much about the estimate, if it starts to creep, where you need like an extra week or two, because you still want to ship a quality product. And it's not that surely is not shipping something quality, it's the fact is, is like she's quoted a client and said, like, this is how much it costs. And she can't really come back to them and say, like, Well, I kind of mixed up, you know, it's actually gonna, it's gonna cost you this much more, I mean, you can do that, but then they start to lose trust in you. And so I think that it's interesting, because I know, when I worked at an agency, when you have clients, it's like, that was so critical to get those estimates as close as right as possible. And it still was really, really hard to do. And so yeah, when you were going over time, it was the client wasn't paying you extra. None of that was happening, it was eating into your own budget. And so you have to be really thoughtful about that and take different approaches. And so sometimes you do pad your estimates or think about that, because there's so many different unknowns. And even surely, I'm assuming, and I thought you would say this, but like with the data sets, I'm sure some people are giving you data, and you don't know exactly what that data is going to look like, or how you integrate with it. Because like that, to me is even caused us problems, like at Netflix, or any companies that I've worked on too is I may know my space and have a really good idea of what's going to happen or be able to estimate. But then there's all these unknowns and other dependencies and the dependencies are always what's I find kind of come and bite you later. Oh, yeah,

Shirley Wu
definitely. So I think it's taken me years to kind of build into my contracts. And that anything that goes over the time, because of not just kind of because of unexpected things like unforeseen things in the estimate, and what and I will, I will build my daily rate for that. And that includes, so that includes, you know, scope creep, cheers, cheers. Cheers. Like if a client wants extra features that we didn't talk about, like, maybe it's in the middle of the project, where like, we both agree that this extra feature is actually like really crucial to the project. And so I'll be like, Hey, this is gonna cost this much extra. But sometimes it's exactly like you said, Ryan, it's like, either, you know, the data set, it wasn't in the shape that I was expecting, or like, we need extra work cleaning it or maybe it's even that like, it takes longer to explore it, then we thought it would. And so I kind of actually this is so specifically niche to like my work but like now I kind of separate it, I try my best to separate my projects into like two phases, the first phase being the data and the design and that I kind of build. And so like i i build by like day or hour, and then the second phase where it's like purely the coding that I have a good estimate for and I like Bill as a project.

Stacy London
Oh, interesting.

Augustus Yuan
I think it's interesting. I actually don't think it's like crazy niche. I actually love how you go through all phases of that project lifecycle, because I think a lot of people tend to forget like know how you estimate for design problem is very different from how you estimate like coding and engineering work right. And you know, especially if your task is to implement some front end feature that is dependent on the design and the designer needs to do design explorations of mood boarding of like, try to try to define maybe new UI patterns like, I think that tends to get overlooked a lot. And you know, it takes time, it takes time. And it takes a lot of effort to explore and maybe pave new. Try new things. I'm just

Shirley Wu
gonna go on a brief tangent soapbox, which is for every person that ever has, like, been condescending to a designer, and thought a designer's job is easy. Like I'm speaking. Like, as a software engineer, I am too intimidated to like claim that I'm a designer, no designers, jobs are so hard. Because I think with engineering, there's, there's kind of like a right answer. Like, even if estimating is really hard. There's like a, you know, it's either It either works or it doesn't, it either has some bugs or it doesn't. And so like, there is kind of like an end to the estimation, right? Whereas like design, I think it's so hard because it's so subjective. And literally anybody that can see can have an opinion on the design and can rip a design to shreds and then like, it is such a hard feel. Okay, that is that is my soapbox on design.

Stacy London
Plus one two, that yeah, it's creativity, how do you estimate creativity, you wouldn't ask a painter to say, Oh, I'm definitely going to be done with this in a week, like, the inspiration comes in different ways. It's it, it's not something necessarily that you can put time on not to say that software development is like a painting or art, but there is like an element of creativity to it. And it's not like building a repetitive thing, that's exactly the same on an assembly line, that you can get really finite answers to like how long a thing will take because it's the same thing every time, like, even building, you know, I don't know, an example. But something seemingly simple. You know, maybe there's the new framework that you have to learn to apply the thing. Or maybe you have a mix of team with different skills. And some of those folks don't have, they've never built that thing before, even though lots of other people have built it before. But they have it. So like, all these variables go into it. And it becomes this is why it's hard to estimate this kind of stuff. And even more difficult, I found, then say like, you know, build this feature for this screen has been the most difficult thing in my career so far has been working on this. Build something that's never been built before? No, there is no industry examples of it. It's highly experimental, and tell us when you're going to be done. That to me, was I I struggled with that so hard, because I was like, Well, I have I honestly have zero idea when will be done. No one's ever built this before. Like, how do you estimate that the none of these frameworks help you scrum doesn't help you with that, like that, that means still a big open question.

Shirley Wu
Now that you mentioned it in my previous job, I have had those experiences. And looking back now, I think that, um, I am so grateful that mine, I think we had a really great project manager, she's still one of my favorite people to this day. And she would intentionally, like urge us to break out an exploration, like take one sprint for exploration. And then from that learning, figure out, like, come back, you know, presented to everyone and then figure out, like, what the estimates may be or like, if it needs more exploration, I can kind of see the parallel to or approach and like how I work with my clients. Now the thing a lot of things I do with my clients is like, it hasn't been built before we need to explore and I think

Ryan Burgess
it is taking that time is sometimes you need to investigate oftentimes even all encourage that with my my team is you don't have to give an estimate right on the spot like so, if a pm or even if I asked like how long do you think it's going to take an answer, maybe give me a couple days to investigate and to really understand, because there are all those dependencies that I mentioned earlier that you're having to deal with, or there's a lot of unknowns, that it may take some time upfront to kind of do a bit of research to learn that another thing for in the agency world which Stacey I think you hit it well for me is like even talking about learning new framework is there was times when I would be in on like an engagement where it was working with some framework or tool that I'd never used before. And it's like, Okay, I'm gonna have to do a little bit investigating it. Like I remember things like the JavaScript framework, Dojo or like, I just remember been thrown into that, like, yeah, I've never written this before. But sure, I'll figure it out. But it took me maybe building POC or just something that's very small to get a sense of that to just help me and even then I for sure did not estimate correctly. But it's sometimes taking a bit of step back and saying like, I need a little bit of time to research. And I think that that's one approach for that because I think that's a great question, Stacey

Shirley Wu
Ryan, I really also appreciate what you said about how even if you're asked on the spot, like how long will it take that like there is the freedom to say, Hey, let me get back to you on that because I think Like, especially as a more junior developer. And I keep saying this because I think when I was at full time jobs, I was a more junior developer. I remember being so stressed out, maybe I think, in a like scrum meeting where if we're working on that, then I think I'm not as blindsided by Remember, there will be some times when like, I, somebody would just approach me as I'm working on something else and be like, hey, we need to do this new thing. How long do you think that take? And I'm like, what? And so I think just that knowledge of reminder, because I think, you know, 24, I like felt the pressure and the stress to answer right away. But just that reminder to be like, No, this is, this is a really hard task, like, we should be able to just be like, Hey, let me get back to you on that, like after I think about it for a few days. So I really appreciate that. Yeah,

Ryan Burgess
I also think like putting it doing that, taking a step back, and then breaking it up into chunks to that it's so hard, say the one whole project or feature. It's like, here's, here's the random estimate, I like to like, pull it apart, like, how long is it going to take for this? Or like, what am I going to need in talking to another team just kind of breaking those things down. But sometimes even throwing it, I know, our last episode we talked about documentation is like maybe throwing it in a dock or some sort of a write up and sharing it with your team to get feedback on to write like that can also harden an estimate more to is like talking through that with your peers, rather than doing it just a loan. And they might say, well, I don't know that one actually, I think is going to take a lot longer because of XY and Z. And you might actually catch some unknowns that you had, that they're now surfacing to. So I think that that's another reason to take a bit of a step back.

Stacy London
Yeah, I think that's why like, in all the years of doing software development, even though scrum as a as a as a methodology has its flaws, and nothing is perfect. It's the one thing that I found that gets you the most input into understanding the complexity of the problem. So that because like to build a feature, let's say you're on a team, it's, it's the team, it's like the people on it at that moment in time and how long they've worked together, and what their skill sets are, that will determine like, how fast or slow something can be, can be built. And that team is the unit and and so like you alone as one person trying to say, Oh, I think it's gonna take us 10 days. But you can't say that because you're not the only person working on it. And so when you start to do like, they call it backlog refinement, or where you talk about a feature, and you talk about the broken down subtasks as as a group, then you get all that input, and you can better understand its complexity. So like, you know, if you have QA person, if you have that on your team, that's awesome. And that person can be like, Oh, you're forgetting that, you know, we need to make it work in, you know, these platforms are this, this You're forgetting, like, if we don't do mobile, maybe it won't work, right, or they give you input, and then it helps you have more more information, I guess, to like, make make that decision. And so like the complexity stuff, to me makes a lot more sense. That way, it's, it's more accurate. Again, though, like over time, the team might change, you know, if someone leaves, well, then your vote, whatever your velocity had been, would change because now you have a new person and new skills, new things that they bring to the table. And that's why software is so hard because it is about humans and working together as a unit if you have like that, that setup and structure. I love

Shirley Wu
both of your insights Stacy and Ryan about um, I think, coming into this episode, I only really considered the kind of the, like technical side of estimating like the engineering technical side of estimating. And I love the Insight you're giving about how human the, the like task is, or like how much of it is communication and, and I think I came into it because as like just one person, for me just how quickly I can do something. But looking back to like when I was at a full time job. Certainly I feel like a lot of the extra time that I had to spend was in terms of like communicating with my teammates or communicating with other teams, like a lot of times it was like running back and forth between design and pm to be like, hey, like this design I got, it actually is missing this edge case. And like I think those kinds of communications is what really added up the hours for me, where I'm like, Oh, I estimated this, like I underestimated this. And so I really appreciate that insight. It's like very eye opening for me.

Augustus Yuan
I just like really want to highlight like some of the things that Stacy said, which I'm just like, oh my god, like I resonate so well with what you're saying. Because, yeah, when we practice Scrum, and I just like I think know how many people are familiar with Scrum, but like there are dedicated, they'll say rituals, but like dedicated meetings that you dedicate, like part of the calendar sprint, where you will go through tickets, and you'll estimate them together as a team. And that is like one of my favorite things, because so much knowledge sharing happens in those meetings. And you do feel like a team, right? Like, like, people bring in different perspectives of like, you know, how much work it will take, and they consider different things. So it's like so important. And I also want to highlight one of the other things, Stacy mentioned, is moving away from time and focusing more on complexity, when it comes to story pointing, like, that's such an important thing, because because if you think about it, like if some, like, a problem might not be more complex, like it's just the same amount of complexity, but somebody who starts new in your team versus, and they could be like a very senior senior engineer, it might take them longer, you know, even though it's a simple thing, because they might need to get their dev environment set up, they might have to do a bunch of prerequisite things. And you know, you're not going to make them, like, take it out each of those individual items and block that, right. So it's like moving away from this obsession for time and really focusing on complexity. I just, I think that's like such a critical part of understanding

Stacy London
totally well put, it's, it's hard. It's hard for the human brain to do it, though. And I've seen this, like everyone struggles with it. Everyone's like, oh, the story points and our velocity as a team, like if we get if we say we got 30 Story Points done, which is a complexity based estimate, in a two week sprint, everyone starts to try like your to say, Oh, well, that means we get X number of Story Points done per day. And that means you know, and there's sort of this idea of translating them to hours, if you go that direction, you start you've moved away from the the benefit and the value of the fact that you're doing the complexity stuff, project managers will struggle with it or people that want to make, you know, project, Gantt charts and all the things they'll struggle with that. But so then the idea is you have to start talking about cones, the cone of uncertainty and extrapolating the story points over time. So you can say if I if the team averages about this many in we have gone through the backlog, we've put complexity based estimates and everything we can say like, we think we can probably get this done in you know, two months. But the cone of uncertainty is wide, though it's very uncertain, that that we can definitely do that. Because things can change. And so as you near that date, the cone becomes narrower and you and you can be more certain. But all of these things are just like we're not built with that we live in time we have all of our days are based on time. So it is still I think, a hard concept for people to

Ryan Burgess
grasp. So that kind of leads brings up something I was thinking about too, is what happens when you don't eat the estimate. You've agreed to that scope. Cheers, cheers ring, a

Augustus Yuan
ding ding,

Ryan Burgess
but there's something came up there's complexity. How do you approach that with maybe it's your stakeholders, business partners, maybe it's whatever it is, like surely, obviously a client? What do you do in that scenario?

Shirley Wu
I'm I'm very upfront about it. It's interesting, because I'll talk to some my, some of my friends that aren't independent, that are designers, right. And I think that sometimes they're taken aback at like, how soft and wiggly of a deadline I have. Because I think that and I don't know why this is. And maybe, I don't know, maybe this is just me. But oftentimes, I find that sometimes I'm able to meet deadlines. And I think those are when, like, you know, the goals are extremely clear, the designs are extremely clear, we've like, everything, everything, but then there are actually a lot of oftentimes when just a lot of things come up, and then it's very clear, we're not going to be anywhere close to the dumb deadline. And for me, it's all about being extremely clear, and communicating. And why we're not meeting that deadline of like, hey, we decided to do this. And that's why we can't quite make this deadline or like, hey, like, you know, this actually turned out to be much more complex than, you know, we thought it would be and that's why we're not meeting this deadline. And I feel like that maybe it is this expectation that like so far is kind of actually hard like it is, you know, it is like clear cut in that it either works or doesn't work. But like it also is really hard because there's a lot of like bugs and edge cases. And I think because of that at people that I've worked with are very understanding I've also self selected for not assholes. So I think that's also why they're also very understanding. And so I don't think I've ever had a client being like really upset with me for missing like deadline do anything because I think I've communicated and they're also very understanding.

Ryan Burgess
I think a key there too, is you're communicating it to like I've definitely We've seen this happen throughout my career and people aren't being upfront about those things, we run into these issues. It's typically it's not at the end, like it's not when that deadline is at the very end. It's not like, oh, it's due today. Yeah, I ran into all these issues, that's rare, there's usually something that you came into an issue that you didn't account for, you know, three weeks before the deadline, or whatever it is. And I think it's so important to raise that early and like talk about that with your team with your clients figure that out together, because that's where you may be cut back on scope, or you cheers, cheers. Or you stretch out the timeline to write like, that's another thing is like, you might just say, well, it's gonna take an extra week, like, like Stacy said, it's like, Alright, cool, then then we just move the deadline. By a

Shirley Wu
week, I feel like I should give a disclaimer that I feel like I'm being pretty clear and communicative. And I don't think I'm upset and your clients, but maybe I just don't know. So that's my disclaimer.

Augustus Yuan
This kind of inspired something. So I really appreciate it when managers will pad at or managers and even fellow co workers will pad estimates just a little, you know, just in case. And I don't know if Ryan remembers. So when Ryan was my manager, there is this. When I first started working on your team, I don't know if you remember this, Ryan. It was like my first web page that was working on Evernote. And you were like, oh, you know, so like, based on these requirements, how long do you think it takes? And I was like, super energetic. Super, like. Yeah, I just like, went from intern to full time. And I was like, super like, oh, I can get that done in two days to three days. You're like, and I remember Ryan was like, Okay, Okay, interesting. And then three days came up. And I was like, geez, Ryan, there's like a lot of stuff. I didn't. You're like, don't tell anyone. You're doing it three days. So that was like,

Ryan Burgess
a big I remember that. Do you remember this? Okay. Yeah, no, I do. And I remember my thinking behind it, too, is like, I could have told you in the moment crushed your dreams and said like, it's not happening in three days. But I was like, Yeah, I'm gonna let them like figure that one out a little bit on him on his own. But also Yeah, not thrown to the wolves and say, like, hey, he said, three days i Where is it? It's like, no, like, but because I think there's there is learning because like you you do learn as you go on how to estimate

Stacy London
this is such a great segue. And that's psychology. You're, you're over exuberance, and you're like your confidence. And like, all of that is it's part of psychology, there's this is gonna this was going to be one of my picks, but I'll just mention it now is like, there's a there's a Freakonomics podcast episode, which I thought was phenomenal, called, here's why all your projects are always late, and what you can do about it, it's from 2018. And it's not about just software, it's about like, across the across all things, you know, construction projects, etc. Like, why they're always really late. The summary of it is kind of like people plant they kind of suffer from this idea of like the planning fallacy. We have optimism, bias, overconfidence, etc. And so, the planning fallacy is like you, you tend to like underestimate the time it will take, even if you've worked on something similar, you're still under estimating it because there's this app, you're just optimistic about your you know, your abilities and the brain defaults that way. I think it was, you know, for survival and evolution, so that we, you know, are optimistic about surviving, etc. I would love to have a psychologist explain that more correctly.

Ryan Burgess
Yeah. I'm excited to go listen to that episode. Yeah.

Shirley Wu
Thanks for that. What

Ryan Burgess
a great pick for this episode. So

Augustus Yuan
good.

Shirley Wu
I was I was gonna actually ask on top of that, oh, I was also gonna say the only exception is when you work as a freelancer and you have to estimate and if you estimate under, then you you'd like lose money. And that's the only time when you're not over. optimistic. You're, like, very pessimistic. I'm like, It's gonna take me a very long time. Sorry, that's not here. Neither here nor there. No, I actually love both. What you said, both Augustus and Cece, and I actually was gonna follow up on that. I think it's so interesting of like, when you're enthusiastic about estimating, and then like, what if you actually managed to hit it, but not in a healthy sustainable way? And, and this is me, going back to my junior Dev Days. I like a startup of like, I'm, I'm young, I'm new. I'm eager to please like, I want to, you know, like, build a good reputation. And so like, I'm like, I can do it in a week. And like, obviously, I couldn't do it in a week, but I did it in a week because I was working evenings and weekends. And then like, I start building that reputation of like, I can be fast but only because I'm sacrificing like my evenings and weekends afterward. Thankfully, I had good mentors and co workers that were like, hey, surely you can take a break? Like you can you can, it's okay if you don't meet your estimates, but I guess it's kind of like a, I guess I'm seeking advice for my 24 year old self of like, what do you do when you do kind of get into that situation of like, you're kind of just burning yourself out? Because you are estimating and you can meet those estimates, but not in a very healthy way?

Stacy London
That's a great question.

Augustus Yuan
Well, yeah, I just want to say that's a phenomenal question. My initial reaction is because I've also done that, and I still still, I still see people do it. In fact, I think a lot of the tech culture even kind of encourages it. Yeah, I don't want to speak on behalf of people. But I think a lot of PMS are people who are expected to live deliver by a certain deadline. Like they, they try to, like pretend they don't even like they will acknowledge it, they'll be like, Oh, thank you so much for working so hard on that. And but they'll kind of pretend that isn't like a problem, you know, unless you speak up about it. So that's why that's why I actually, I'm really excited about this episode, because I think that's why estimating is so important. You need to estimate where you're working on a reasonable amount of time, like your typical work hours, right? Like, don't estimate, like a week. It's saying, Yeah,

Ryan Burgess
I guess if I didn't know, it's my work hours.

Augustus Yuan
Yeah, I work out, right. Like, work hours, like don't think, I guess if I stayed up all night, and I included the weekends, you know, I don't need to walk my dog, or something like that. Like, don't don't do that, you know, you need to use sane hours. Yeah. When estimating. Yeah.

Stacy London
And even if, let's say you're using the complexity based estimates, and the story pointing, and you're not doing hours, that complexity, let's say, you you finish your sprint, you're like we finished 120 points amazing when then but you know, that everybody worked like nights and weekends to do that. Hopefully, you have someone on the team with influence, like whether it's, maybe it's not the manager, but maybe it's like a senior person on the team or, or your Pm or somebody that's like, speaks up and says, you know, that's great, we got this velocity, but it seems like everyone, you know, worked way too many hours. Like that's not sustainable. And like, you know, for next sprint, let me be let's pull in a lot less story points. Because you know, this is, this isn't the way that we're going to sustain. Everybody. That's one way to do it is like, speak up about it and acknowledge it. Maybe in a retro meeting. Like if you have a retro as part of your scrum stuff, you can in that to say like, what can we do better? What did we learn? You could say, hey, we everyone killed themselves this last sprint during all this extra, all these extra hours? Let's not do that again. How can we be more healthy? And then ask that that junior person that said, like, I can do it in a day, dig into it, dig into it, and say like, Hey, what did you when you we thought you could get it done in a day? What were the what were the things ended up making it take a lot longer, what were the things you discovered, and that will help that person kind of like learn to take that into account, the next time that they do a complexity based estimate to be like, Oh, I also need to remember to do X, Y, and Z.

Ryan Burgess
He brought up such a good point in the retrospectives. Those are so good and important. Even when a project goes well. If a sprint or project goes really well reflect on it, what went well, what should you repeat? What should you not like if something doesn't feel? Well, I think that's super important to reflect on that. I also think it's super important that there is a whether it be a manager or team lead, or whoever's kind of in charge of the team or thinking about the thing is to be watching out and being an advocate for their team. I'll never forget when I was working for an agency in Toronto, very much the same point that like the pm was like, Oh, happy to get things done. And they you know, they're trying to make their deliverable. I remember, I worked nonstop for like, around the clock, like there was night and day for a few days, I was a lot younger than so maybe that helps. But I was burning out hard. I wanted to meet the deliverable. It was needing to make it to the client. It was bad. And I remember my director ended up being so frustrated at the pm because the pm wasn't discouraging that. He was like, of course Ryan is going to try and deliver that you're needing that he's going to try and do that. But you needed to step in and say something and be like, well, we can't this isn't healthy to keep trying to do this. Like let's figure out either cutting scope or finding more time shares and so I always remember that that one always stuck with me and that's like I will always stand up for my team or be thoughtful on those things where there's no use killing ourselves because you end up not doing your best work. Like I remember trying to write like the simplest function or something like not remember what it was but I do remember that took me like An hour to do this thing that should have been like probably three or four minutes. And it's just because like, my brain was just not working with no sleep, and it just wasn't healthy either. So you're probably still taking longer when you just need to be thoughtful about those approaches. Yeah,

Shirley Wu
I appreciate everything that y'all said. I wouldn't like where was this podcast and you all when I was 24. I also hope that I've been out of full time for a while. But I hope that like the culture is shifting, I think, I mean, like, we touched on this in Silicon Valley, there is, especially at startups, there is a sort of toxic culture of like, you know, you work nights and weekends and because there's, there's a dream that you're trying to work towards. And I do have to say that that first year where I was working nights and weekends, that was that was where I had the realization that like, if I'm going to work nights and weekends, because I'm I'm workaholic anyways, I might as well be working towards my own dream. And that's actually kind of like what fueled going freelancing. And I feel like that actually did feel some sort of like a, like a self discovery. But outside of that, I hope, like, I hope that it's much more sustainable. Now, like, I hope that our priorities at companies are now on like, everybody's physical and mental health. And, and to Ryan's point about, you just don't do your best work when you're overworked. I hope that we're having that shift. I sincerely hope we don't have as many like you know, toxic startup culture as much not not as much the Silicon Valley sitcom TV show that stereotype Watch out do that, Oh, my God, that that that show was so triggering everybody that like so many people were like, Oh, this is hilarious. And I'm like, This is not hilarious. CST please don't make me watch a

Augustus Yuan
shameless plug. We had a podcast episode about burnout that I think everyone you know, you know, definitely listened to, you know, like, it's not a good culture to promote. And we really should move away from it.

Ryan Burgess
Yeah, it was a good discussion. I remember that one too. And like, you know, and we're all guilty of it. It's a good reminder, don't over work. And so on that note, let's hop into fun pick. We like to share things on the front end, Happy Hour of things that we found interesting. Want to share with you all. Augustus you want to start it

Augustus Yuan
off? Yeah, sure. I originally had to, but during that episode, I added one, which was Atlassian has a page about agile, definitely worth checking out. Honestly, Atlassian owns documentation on agile, they have so many resources. I it's just totally worth checking out how know I've become an avid fan of Agile Scrum methodologies. Annika this scrum master that I had before at Evernote, she really converted me so and I a lot of the documentation there is just really solid, so definitely worth checking out. My second pick is Amazon builders library. This is basically a library of tons of different system designs that use cases. So I guess this is kind of what Amazon has, where let's say you wanted to build some system. How would you system design it with AWS products, I think it's just a really great resource if you're studying for system design interviews, because you can kind of walk through like, Okay, here's the use case that they have, here's how you would build it with AWS. And you don't have to use AWS products, you know, you could use GCP, or Azure, Microsoft Azure products if you wanted. But I think it's just like a good thing to kind of read about, like if you're trying to look for more system design stuff. And then my final pick is this game that has been getting a lot more steam, and it's served on Steam. It's called Val Hime. It's early access. And it's just like a really well done game. It's like a survival game. And it's procedurally generated. And I'll just say what my coworkers said, like, I think there's been a lot of games that have been coming out that were kind of disappointing. Like cyber punk has just been kind of a handful of games that just did not meet the bar that people were expecting. And then this indie game comes out early access, and it's just so so well polished. And it's just been rising in the charts. And I think it's worth checking out

Ryan Burgess
ice, surely What do you have?

Shirley Wu
Oh, I actually started the episode with zero and now I have three. So the first one I have is, so d3. JS, which is the JavaScript library that I use in all of my project to do to create my data visualizations just celebrated its 10th birthday on February 17. And very exciting. So we had a whole live stream to celebrate it. It was a fun One there was uncovered, you know, d3 history. Mike Bostock, who's the Creator, He came on and kind of talked about his 10 lessons learned. And so I'm sure what should and will link that in the show notes. And then we're also having a kind of, we were calling it a d3 parade, it's a non competition contest, where we are, you know, it's a, we are wait on it is we are looking for data visualizations, based on d3 data, create a using d3. And we will, and the submissions. were accepting submissions until March 17, I think. And then on April 17, we will have a d3 parade where we'll kind of like, you know, showcase some of the submissions, and then we will kind of do a, we're calling it a recognition award, because we don't, we don't want it to be competitive, we want it to just be fun. So we have like a bunch of like fun categories, like best color palettes used, or like best animation or like, funnest, you know, layout used or something like that. So that's gonna be Yeah, so what I'm sure we'll link everything in the show notes. So that's the first thing. d3 is 10th birthday. The second thing is yesterday, um, my studio mates, um, launched a Discord server called Creative cuties. And I'm so excited about this. And it is a community that's just gathering everybody that's, you know, into, like creative things like whether it's code or illustration, or doodles or DIY eyes, but also with like a cute aesthetic to it. And I love it because it's basically an internet extension of my studio, which I don't expect anybody to know what my studio is like, but we're like a really beautiful studio office in the mission and SF and there's like, you know, beautiful murals by my studio, me, Alice. And, you know, it's a five of us. It's, it's just a really beautiful space. And now there's like, it's kind of like the online extension of this and my studio mates Alice Lee and Amy sailor HG, are doing like an amazing job curating kind of like and leaving the community so highly recommend. It's called Creative creative cuties. That was my second pick. And then my third one is, it is a lenticular hologram, Rainbow gradient puzzle by a group called play play group. So it's play group thought design. And 1000 puzzle pieces, is a remote gradient. But because it's hot, like lenticular hologram, depending on which side that you look at it from the color changes is such a mindfuck. And so if you are either masochistic, or if you're sad, and you want to give this to someone, I highly recommend it. My husband gifted it to our friend who loves puzzles. And then we've been social bubbling in cabin together. So that friend brought this puzzle to the cabin. And basically, our comments spend a week working on this and they say that it is a really great team activity, because because the color changes depending on which angle, you actually need more than two people to complete this puzzle. So that like one person like puts a piece in and the other person like, verifies that it's like the right color. Yeah, I think highly recommend, if you like puzzles and are a slight bit masochistic.

Ryan Burgess
Alright, Stacy already ha.

Stacy London
All right. I have two picks. The first one I mentioned a little bit earlier, which was the that Freakonomics podcast episode about? Here's why all your projects are always late. What you can do about it. I will say within that episode, there's some former members, I think they were at Google and then I think they would take Facebook, but they created Asana based on some of the problems with project management and being able to visualize your work and everything. So all I will say is that you should probably use Trello to help visualize your work. I feel like it's

Ryan Burgess
a pretty good price point for that. I love it.

Stacy London
So that's the first fact and then the second one is the music pick. Can't go without one music pick at least and that is a song called inner gaze by Heidi Sabretooth, and she's a New York based singer, multi instrumentalist, DJ producer. She does a lot of stuff with hardware. So there's a lot of like drum loops and vintage acid and that kind of stuff. In her in her in her stuff. So that particular song is really great baseline really with headphones on. Nice, bounce, bounce your head as you code.

Ryan Burgess
Those are always good for coding like that. Alright, I have two picks. I have one that is a cool series that started during COVID. It's a video series very short segments. It's called rebuild black business, Justin Samuels. He's a software engineer in Atlanta. He also runs render ATL the conference, and he's been putting together these video series where they just interview black owned businesses across the US and it's super interesting. They're just like really small segments and they're really well done like really good quality in the videos. I've watched a few of them haven't watched them all but it's really cool. And then my second pick is the TV series good girls. They're just notice there's a new season season three on Netflix and I'm enjoying it. I thought it'd be kind of an annoying show. I maybe it's even starting to feel a bit annoying like where it's getting repetitive but I'm still enjoying it. So I thought that's been a good show to check out. Thank you all for listening today's episode. You can find us at front end happy hour.com You can subscribe to us on whatever you like to listen to podcasts on you can follow us on Twitter at @frontendhh any last words topia scope creep

Augustus Yuan
Don't be a sculpture. Yours