 Okay, I guess everyone's here So So why am I giving this presentation? So I guess people might have noticed that some of us have gotten like more involved in your projects and you know getting Giving advice through new steering even certain directions and I just want to kind of give some background on like why We're doing this and like what my vision is on how You know how we should be organizing things differently what we should be changing and So hopefully out of this, you know get a better understanding of how we like to work and maybe you know organize things better so Just basically, you know, everyone knows this sort of agile process, right? That's supposed to make you work efficiently and deliver great products and everything I'm not here to sell you on like any specific, you know agile scrum or whatever the specific methodology, but there's a general sort of thing where You know the way you want to work is you make a design first you break it down into tasks and then You make a first prototypes and first implementation you get feedback and Then you start iterating right you update the design on task based on the feedback you implement And you document more you get more feedback and at some point, you know, everyone's happy ideally and then you're done I think even this is if you were just working for yourself on something solving a problem This is probably how you would work like if you were actually care about solving it quickly You would make something That you know is an additional approximation of what you want to solve and then you iterate on it Then you just get it done, right? It's sort of the natural thing even a way of working and it's only When you're starting in what long timelines or you know working in some more formal process that maybe you move away from this and you have to be careful and So in practice, unfortunately, it doesn't always work this way like the first step You might think oh, I'll just get something in a few weeks But then somehow it takes months or like later on in the project you're some point You're sort of always continuously a few weeks or a few months away from it being done But then you're a few weeks and a few months later, and it's still not done So what what happens and then unfortunately the number of iterations it can go to zero one Which means that you have like an MVP that's done, but you haven't actually made it, you know, really good like you haven't really You know got it to really fully solve the problem and you move on to something else because everyone's tired of the thing or you know and Then unfortunately the quality suffers and it's unfortunate So why does this happen? I mean the obvious thing is you have too much other stuff to do and that's I mean that's valid Or you know, maybe you just don't have enough time within whatever time span you were planning You know many people here have multiple responsibilities that you might get distracted and that's like 100% valid like you know That's not the point to criticize thing. It's like but the thing is that within the time that we do have for the project I think we still make mistakes and Yeah, I just want to like talk about some of them and how we can address them and so Here's a list of common stakes that I have all made like the point is not to say like I'm you know I've never made these because I've made all of them multiple times probably different times so Let's go over some of them like One one mistake is that you think well the design is done and now we just do the implementation, right? That's like your classic waterfall thinking for people who are familiar with that. It's like you just think you can design up front and then implemented and then unfortunately the real world doesn't agree with your design and You know really you have to be prepared to change your design as you're working The other thing is that It might think your project will be done when everything your plan is done But unfortunately everyone's bad at planning software projects. That's just a reality And so you have to understand that your plans will change and there will be things in your list that you didn't anticipate and Yeah, that's that's a problem Another thing is that you might underestimate the difficulty of what you're doing You might not fully understand the problem like a common one Is you think I have x and I have y and I just need to combine them and integrate them and then you know We're done right but often like integrating things is actually the hard part like the beautifully isolated things They're fine, but then when you put everything together it like There might be additional requirements or the integration might actually be the hard part rather than like the individual parts Another common mistake is that you think well, I'm just gonna like refactor everything I'm gonna make my code beautiful and like it's gonna be like perfectly prepared to implement the thing and then everything after is gonna go smoothly, but what often happens is that actually You didn't understand the problem well enough So you might actually be refactoring the wrong thing or you might be for refactoring something that's not even necessary Or maybe refactoring doesn't actually help make you develop more things faster Afterwards like the benefit might not actually be worth it and then you run the risk of like getting you know stuck Doing this refactoring or other things rather than actually finishing the project Another temptation is to think well I work on this thing and then I noticed this other thing is bad so let's fix that as well, or let's rewrite that or let's refactor it or whatever and You know you might just get stuck doing all kinds of things which are not really essential to the project and And things just you know spiral out of control and take too long Another common thing is you just kind of get tunnel vision You know you might be facing like this one difficult thing that you're working on and you just think well I just got to get through this one thing and if I get that out of the way then You know everything else will go smoothly, but then you know, maybe you need some advice from other people Maybe you need to work on something else for a while and come back to it or do like a first iteration on it because maybe it's not actually that big a problem or maybe you know Maybe we'll find out there's a different way of doing things or whatever but That's not a thing to look out for and then another thing is thinking well I didn't get it done this week But like somehow in the future next week next month. I'm just gonna be extra productive and just you know That's somehow I didn't get done this week But next week I'm gonna have the time or the energy or whatever to do it and sometimes you do because like productivity it changes like One week you're more productive than the other. That's true, but you cannot really count on that as like a project planning strategy So yeah, so these are some common mistakes And so how do you solve this? Well, I don't have a magic solution But like the first thing is to just acknowledge like all these things can happen right like if you're working on something Like no one here is a machine. So everyone has like it's dealing with these kinds of questions all the time and it's just hard like it's really hard to to You know develop software and do to you know, it's always difficult and unpredictable So the first thing is obviously acknowledging that these things are problems and then having them in the back of your mind and knowing that you know They can happen and being able to talk, you know Be aware of them in a project and just you know being able to talk to them To talk about them with other people I Think it's helpful and that's kind of part of the point of this presentation And so I'll now give some more concrete sort of advice On what to do with again, not a magic bullet, but sort of how I like to think about things So one thing is When you think about like the time spent on like particular things It's important to you know, you can sort of break things down into multiple levels And here I'm just these are sort of conservative estimates like it can be This long but maybe it's even better if you take less time or you make your steps even smaller so that it doesn't take so long But just serve one way of different levels of thinking about it It's like for yourself say you're working on something you're working on a specific commit or some you know some specific thing A bug that you're fixing or whatever If whatever you're working on like by yourself at that in that day if it takes longer than a day it's probably too big like you've probably taken too too big you're trying to do too much at once because You can't really keep that many things in your head at the same time You know you might forget or you might get distracted doing something else it's it's important to like try to like finish things frequently and Like a day it feel I feel it's like a decent unit even less if you can but and Then when you're not working by itself, but you want to get feedback from other developers I feel like you should Every week at least try to get something you know out there in terms of the code that you're working on Like if something's on your computer like some codes on your computer For more than a week and no one else has looked at it It's probably that you're working on it for too long or you haven't like Split it up into something that's small enough for other developers to look at and maybe give advice or Or to even force yourself to you know make something. That's okay. This is actually something that's ready for other people to look at and then the next level is When you talk about feedback from users Is that ideally you want to have something tangible like within a month or something like something that? Some first situation of your project. That's real in a way that you know, it's a thing That's running that you can test even if it does very little Just having something it really helps even if you're trying it yourself It really makes things real and helps you understand the problem better That's ideally get feedback from users, but even if you know yourself testing it or someone else in the company or whatever Getting towards something real very quickly within like a month ideally then I think that really helps to Yeah Help to get to move things along and then for release like if any project that we're working on It's not planned for this or the next release I feel like it's too big and needs to be broken up like if you're planning over going to do this and truly releases from now Then we probably haven't done a good job of like figuring out how to break down the project into smaller steps So yeah And so how do you break things down into smaller steps? I mean there's no single recipe But one is you know, just make an honest turf complete list of things that need to be done Even things that are you know challenging that you don't know how to do yet like just just try to be like complete then like Identify what's actually important and what you can eliminate or at least postpone and Then as you break it down into steps I think it's really helpful to or important to break things down into steps where you go from working state to working state because What can happen is that at every step you kind of introduce more bugs and and things begin You serve work yourself deeper into a hole where later on you have to work yourself out of it and fix all those bugs the remaining dangling issues It can be a problem because fixing something that you broke yesterday or you know an hour ago It's usually very quick. You might just know immediately but break fixing something you broke like three months ago You might have to start might have to start bisecting or you might have to you know Spend so much time debugging and trying to remember how this thing worked that it's just not efficient to fix something that you broke Three months ago like that's it's not great The other thing is like if you talk about refactors You want to make them part of the iterative process like if you do something before if you refactor beforehand You might just be refactoring the wrong thing if you do it after it's probably just not gonna happen so So you want to make it part of the process and not you know part of the iterations The other thing is like when you're deciding whether you're going to Rewrite something or or change it like you I think it's really important to serve value like the implicit knowledge and year of refinement That's an existing code Like you might have a piece of code and you think well this looks terrible like what is this crap? But actually there's a bunch of assumptions in there that you might think you know But actually you don't because it integrates with things in unexpected ways or it works in a particular way that You might need not be aware of so whenever you want to like You know replace something it's important to think well Maybe we can do it in an incremental way that preserves the logic or in a way that you know That's less risk of like breaking a bunch of stuff And the last one I think we should probably Be better at like giving advice of how to break things down Like often I hear people say well, it's not possible to do this in smaller steps But I usually think I think it is usually and Yeah, just talk about it with other people if you don't know how to do it and You have to be more proactive about it as well, of course, but So yeah Then there's keeping track of what's going on so I mean people have obviously I want no one likes like all the all the overhead and Bookkeeping and all this stuff But I think it's still important for yourself or for others to have a complete list of You know where you are of what remains to be done. That's realistic and And for that reason I think it's important to remember that it's important to have a list that's brief and complete rather than something That's detailed and outdated Right, you might it often happens that people make this really beautiful design document Or you make this beautiful Kanban board or whatever and you organize it and then after two weeks No one's looking at it anymore like the actual state of things is in your head instead of on the thing And so for that reason I think it's important that you just make it convenient But whatever a list of tasks that you have that it's easy to update And so if a Kanban board or if whatever methodology choose if it works for you great if it doesn't Try to pick something simpler Even if it's just a little a simple issue with like a task list or whatever You know pick something. That's real instead of something. That's Yeah, maybe looks nice at the beginning, but doesn't really reflect where you are Because it can be really difficult for other people to see where the project really is if you're not doing this and Just having like a real list means that also People can better understand like if you take long on something like why did it takes a long while if there's a long list of things to be done It's it's more clear I guess And so another thing is that people might be hesitant to like write down a task because then suddenly feel responsible for doing it Or it's like oh, I'm added more work for myself But you can also think about it the in the other way around like you might think well It's actually I'm just offloading this mental thing onto a task And now I might later decide just not to do it But at least it's not just like something I have to keep in my head. I worry about later It's I would rather think of it like yeah, just offloading it rather than Giving yourself work because it's it's there anyway like it's not going away whether it's in your head or it's in the task list Um some practical things So one is you know when you're working on like a pull request or commit I like to like keep a list of things that That I need to do like I might for example Like where the bunch of code and like at some point I need to open a file and check for errors or something But I don't want to break my flow and I just want to keep going so I might add a small to-do comment Saying like check this later and later fixing is probably easy But like being diligent about those kinds of things I think it helps because you forget that you needed to check this error or that you needed to do this And then that might lead to a bug later on that you spend hours debugging rather than something that you could have just Fixed right away Again update your task list if you've learned the pull request like you you know keep your task list up to date I think it also helps to track what you don't know how to solve yet or what you suspect might become a problem Even if it's like a one-liner just just so that it's there and you know about it and we know about it and Yeah, then at least It's not something that you remember like two weeks before the release like oh, yeah, there's this this thing Because that kind of thing can happen track reflectors as well like I mean, it's It's important thing a thing to do as well. So like Plan for them to take time as well. And then yeah, just try to split essential and optional tasks. I think Like try to like keep Make it clear like what you're actually really have to solve and what's optional So, yeah, these are some practical tips for people this is Kind of what I think we should do as sort of the More of the leadership and some of the stuff We've basically been doing and for the last two months or been trying to do So one is I think we should not over plan or over announce things like It's tracked the next three months. You can sort of plan beyond that It becomes sort of a vague indication of yeah, I would like to work on this or that but we're not really sure of it And past the next six months It tends to become complete fiction like in reality like you can have this in your mind But it's probably not gonna Really gonna happen. Um, so You know, you have to be sort of expecting that and and I'll try to Over announce like what we're gonna do all this this year. And then maybe we don't actually do it I would rather us announce like every three months Uh to the community like this is what we're working on rather than like at the beginning of the year and try to Tell them at what we're going to do for the entire year. I mean, this that's what I feel How I feel about obviously there's you balance it with like Getting attention for the development fund and everything like obviously, but it's uh, I would rather be more frequently post updates on what we're planning then um, yeah, try to announce things very far in advance and so The way I see this that like the modules they track all your long-term goals beyond the three months And there something might be somewhere on the workboard But then when we're actually planning and announcing like we're mostly thinking about the next three months more or less So other thing is that we have to be more closely involved in the various projects. I mean Uh, when everything runs by itself like it's great. That's what we all want No one wants to manage and no one wants to be managed ideally. I guess or maybe some people enjoy it. I don't know but Reality is that uh, we just have to do better at this and just be more closely involved in the various things that are going on Um And that that's what we've been trying to do in the in the past few months and Probably will continue to do um, obviously on the other hand It's like if people learn how better how to manage and organize projects and we need less of that so But for now, I think there's just going to be more involvement on that site and then trying to help everyone Keep the projects on track and sort of learning how to organize things um by doing it um so that's One thing, uh, the other thing is that yeah by just being organized I think we can adjust the scope or even cancel projects in some case early. We almost never cancel anything um But maybe sometimes you you know, you work on something for a month and you see well, this is not just going to be Too painful. That's not going to be worth it. So I feel like we should be Realistically considering those things and the goal is to make, you know Blender as good as possible for people not to stick to a predefined timeline, right? So you just want to be working on the important things and sometimes that means not doing something or doing something smaller or whatever um Again, we should push for people to make like a complete task list and get early user feedback I know it can be annoying to get a reminder. Please do this or that But I think it's important to uh, sort of face the reality at some point and uh, that's a bit of a job I think to make people face the reality of like Uh, where they really are and what it means for users to use it I think we also have to be better at sort of anticipating risks of various projects Like you can't think well, maybe this is going to be a problem But you know, let's not worry about it for now, but we should probably Do a bit better at sort of anticipating those the kinds of things that come go wrong and uh And not like you know deal with them too late Um So, yeah, that's that's actually it. Um Thank you