Daniel: "So, we might have additional guests on this show today because Mimi and Momo, their food time, their feeding time is in exactly 56 minutes and they usually get a little bit antsy before that and they come up to my desk and are like, hey, are you feeding us? Are you feeding us? And so actually, in fact, I'm being watched right now by a very cute but slightly annoyed cat that's like thinking, why is he talking into the microphone instead of bringing us our precious sustenance because don't you see I'm starving? Yeah, pretty much like they're just looking at me and like when I try to pet them, they're" Dave: "Is it the look where they're, is it the look where they're sat there tapping their imaginary wristwatch as they look at you? Like, come on, don't you know the time? Yep. I've had to barricade myself. I say that sounds dramatic. I've had to make sure the door is properly shut to this room because otherwise I have a similar problem. I've got a cat who will decide that he needs to be in here and on here and into everything." Daniel: "like, no, no, no, no, this is not the thing that I want, yeah, I can't really shut the" Dave: "He's been fed. He just likes to come in and do that." Daniel: "door, I could shut the door but that would just lead to them meowing directly outside the door and trying to open it because they actually do know how to work door hands. I think we talked about this before and usually with a stern talking to and the closed doors, they can do that but for today, I've just decided that if they come in and I'm going" Dave: "Yes, I think we did, but yeah, Monty's the same." Daniel: "to put the microphone into their paws and they can meow a little bit and because that's" Dave: "Mm-hmm. Absolutely. Catastic." Daniel: "the content, that's the content that people have subscribed to this show for." Dave: "And yes, if my door barricading fails, then you'll hear Monty burst his way in and sort of call, KoolAid Man style." Daniel: "How are you doing?" Dave: "Oh, yeah." Daniel: "We can just connect them to each other and they can like complain about their owners." Dave: "They could, they could have their own. Yeah. Yeah. Absolutely. We could have cat, cat hour instead. But you asked how I'm doing Daniel. I'm, I'm doing pretty well to be honest. That's January. We're fresh back after holidays. I've been into all sorts of things over the break. But additionally, if I've been back to work this week and things are sort of starting to get in the groove, you know, you have that sort of January. Oh, where was I after the break of Christmas and anything else? Yeah. Yes, I've been living that life this week, but things are, things are coming together." Daniel: "All right, that's very good, that's really good to hear, I kind of try to work over the" Dave: "How about you, Daniel?" Daniel: "holidays as well and the time between Christmas and New Year but it just wasn't really possible so I did as much as I could but there's so much, just so much going on and just so many things that I need to spend energy on so stuff was really happening slowly but this week, I kind of was finally able to pick up stuff again and to really pick up the pace and get to something that was kind of more or less resembling proper work which leads me actually to a tiny topic suggestion if you want to talk about that because I've been thinking a lot about organising development and like managing tickets, that kind of stuff like agile, quote unquote. So if you're up for that, we can talk a little bit about like what are the different ways you organise or you plan out your development cycles as an indie but also in your team and I could do the same. If you're not into that, I can also tell you about the huge milestone that just passed" Dave: "Wow. I think the milestone needs to be, be talked about first, Daniel, to be honest, this, this sounds interesting to me." Daniel: "for telemetry deck, you've probably seen it. So for the last, I don't know, half year or so, me and Lisa have been talking about what are we going to do when we finally hit one billion signals because we have this counter on the website that basically just goes into the database every second and looks up like" Dave: "So let's leave it that and then let's talk about systems and tickets and managing work because I'm totally up for that." Daniel: "how many signals are actually there and just counts them up, sums them up. And that's been like ticking upwards and upwards and upwards. And for me, it was always like far, far away, like something that is like at some point in the far, far future, this thing will get another digit, but it's never been a thing that's like close. And so I don't know, like a few days ago, I was like, probably like around March or something and I've been playing around with Blender making a little graphic for that. Because Lisa has been asking me, hey, can you can you make a graphic for the one billion blog post? And I'm like, wow, you're thinking far ahead. Oh, okay, cool. And then I've just been playing around because I kind of been sucked into the Blender hole. That sounds very wrong. So Blender, the 3D animations, how far there's free and open source. And that has been recently has been suddenly got really, really good and user friendly. I don't know, like they seem to have had some infusion of code and or cash and really, really worked on their user interface and also on the quality of the rendering and stuff like that. And so with some YouTube, I'm kind of like in my spare time when I'm all coded out. I'm just noodle around with that every now and then. And so I made a graphic and then I just put this day trade on top, which was like, I don't know, 2020 something something until 2023 March. And then I added like a one billion, the number. And I sent this to Lisa and she was like, yeah, why does it say March? Like we're about three days away from this thing." Dave: "Oops." Daniel: "And so we did some calculations and the calculation ended up to be Thursday, January, January 12. And so I was, oh, okay, I got to change this. So I changed the graphic and we like prepared a blog post and stuff like that. And then yesterday it became clear that no, it's going to, it's not going to be January the 12th." Dave: "Okay." Daniel: "It's going to be 11. It's going to be Wednesday. It's going to be today. So just if two and a quarter hours ago at 1745 middle European time zone, we ticked over and luckily we had everything ready. Just the graphic, just the graphic says the wrong date, but I don't really care. Yeah, I was thinking about that." Dave: "Well, to be fair, if your graphic is the 12th, it is the 12th here in New Zealand, so. Yeah. Yeah, I go with that. I go with that. You were just leading with the time at the top, the front of the time zone." Daniel: "Yeah, that's probably the reason why it says that." Dave: "I don't know. We, we, I'm biased, but that's brilliant. That's brilliant. You've crossed that one billion signals line. That's, that's fantastic." Daniel: "Yeah, the most important part, basically, yeah, it was amazing because like, like all throughout the day, because it's the end of the day for me, right? All throughout the day, I've been posting on Mastodon every now and then and being like, oh, not only, I don't know, 600,000 signals to go, oh, only 400,000 signals to go. And it kind of kept increasing and people were reacting really well. Someone even suggested a Zoom party and it was like, probably not, but there was like a lot of interaction, a lot of people were like, it felt like New Year's Eve, New Year's Eve, my God, almost. So yeah, we're getting closer and closer and the energy just kept increasing. It was really cool. And Lisa and I were recording high fives over Zoom and stuff like that." Dave: "That's brilliant." Daniel: "It was really, really cool." Dave: "Well, congratulations, Daniel. That's, that's great to hear." Daniel: "So yeah, thank you very much." Dave: "I'm looking at this, this, I'm looking at this still from your, your blender render. That runs quite satisfyingly." Daniel: "We are now big data. Yeah, that's the blog post on the website already." Dave: "Yeah. So you've got a calendar that's showing the one billion in big, big numerals on top of it and a rocket lifting off in the middle there. And I think we should see if we can link this up. I'm wondering if you're, if you've got a blog post waiting in the wings or something like that, we can link. Brilliant. Yep." Daniel: "That is the hero image for that, basically, like I sent you two images, like one has the" Dave: "Great stuff." Daniel: "rocket arcing all over the image, like from lower right to upper left. And one has the rocket just launching right next to the number and we ended up going with the second one with the rocket just launching because the direction was kind of wrong. Like it felt like going backwards if it goes from right to left." Dave: "I'll say that." Daniel: "And also it kind of looked like the trail of the rocket was going to cross out the number. So I decided to go back and de-emphasize the rocket a little bit, play around with the smoke a little bit more. And I had so much fun, like I just need to include rockets everywhere now." Dave: "I love the render. I'm seeing reflections on the, on the numerals that are 3d and sat there in the middle. And they look almost edible." Daniel: "Yeah, that's kind of how I got started with Blender really, because I had this new MacBook Pro with the M1 Pro, I think, not the Max, but the Pro, and I was like, wow, all this computing power, whatever shall I do with it? Like of course I can compile stuff, but how do I really play around with the graphics card? And then I was reading about the fact that Blender now has ray tracing, like it has a" Dave: "Mm hmm." Daniel: "completely new ray tracing engine. And I was like, I'm going to try that out. And just with a few sliders, you can completely max out the machine. The image that you see, this image took like, I don't know, 45 minutes to render. Because yeah, it has already all these reflections and refractions, and the smoke is partly transparent." Dave: "Wow. Okay. Yeah." Daniel: "It has subsurface transparency, and there's depth of field in there and everything. And yeah, it's just, but it was really fun to make, and I think I'm going to try every" Dave: "That's great." Daniel: "now and then to make something in this style." Dave: "That's really cool. I keep feeling like I should learn it better if I'm lead to sort of have another tool for assets for AR potentially, or creating images like this one. And in particular, I'm thinking of things like app icons, as well as being another potential here with blender, sort of getting that 3d pop by doing it that way." Daniel: "Yeah, I got that." Dave: "But yeah, it's been beyond me for some time. But if you're saying the interface has been given some TLC, it sounds like it might be time for me to, to give it a look again." Daniel: "It has, and also there's various YouTube tutorials that are really well done, like there's this one guy, I think he's called Blender Guru or something like that, and he does this really good series where you just make a donut. And apparently that's the, that's the hello world of Blender designers. And he has these like 20 minute videos. And first of all, you just make the donut, then you add some glazing, then the next episode you add some sprinkles, and all of that teaches you various aspects of the app, basically. And yeah, that's actually super helpful." Dave: "Awesome." Daniel: "And it's, it's pretty fun. Okay." Dave: "I'm getting a slightly off topic that I've got a blender expert in my house of sorts. My eldest child has fallen into it over the last sort of 18 months or so." Daniel: "So they can, they can make your icons." Dave: "They could, they really could. Yep. And then that could be something I could do as well as I could outsource the effort. As it were, or in sources in the same house. I don't know how we call that. But yeah, and getting off topic, but he designed me for my 40th birthday, a couple of months back, a 3d model of the guy from doom." Daniel: "Oh, nice." Dave: "So the doom guy from the game. Yeah. And it's just come to fruition in the last few days, actually, because he had this, this model is fully jointed as like a figure, like an action figure. And he had it 3d printed, he spent ages kind of sanding it down and getting it just right. And then it's been a whole process of painting and gluing it together and bringing it all together. And it looks fantastic to be honest with you. I mean, I'm biased as my son and everything else, but it has come out really, really well. And I think I will potentially link the YouTube video if he lets me to the show notes, because he's put together this sort of compilation of like how he built it and everything else, but you're about to see it if you take a look at the link. So I'll try and find that out by the time this goes out for some sort of link for people. But it's definitely has been a fantastic present to have. And yeah, I just need an updated study room with shelving and LED lights to show it off. That's the plan at some point. Yeah, yeah, something like that." Daniel: "And you're going to put it in, into a, into a, under a spotlight or something like that. Oh, that's really cool. So, so do you, do you like really, do you like really like Doom or is this like a, like" Dave: "He's even built it with a little stand and everything else as well. And he's a plasma rifle too. Well, doom is how I, if it wasn't for doom, I wouldn't be the programmer I am today in some ways." Daniel: "a thing for you, or was it just a random decision to go, to go for the Doom guy, or" Dave: "Which isn't, yeah, way back when in the late 90s, it's software released the source code to do." Daniel: "okay, do tell." Dave: "And the internet went kind of crazy, sort of making different ports of the game. I think originally it was like the Linux code was released and then it was ported back to DOS. The various different versions of the doom engine you can pick up today, usually share some lineage all the way back to then. And at the time that that sparked me off as sort of a 15, 16 year old getting into C programming in roundabout ways. Just so I could hack on the doom engine. Yeah, yeah, that's kind of part of my sort of backstory of getting into dev, I guess. So, yeah, I don't play it so often these days, but every so often me and the kids will play like a co-op game and go and beat some monsters up together." Daniel: "Oh, wow, that's really cool, actually your villain origin story. Very nice. Okay, because in Doom, the one that has or that might, or it might be quick, one of either do more quick has in it somewhere a function that can be used to calculate quadratic equations or something with perfect or like, or approximate them, but they're like, but the function runs really fast. So it's basically the reference implementation for calculating quadratic falloff in all kinds of graphic stuff, but John Carmack, the developer of doom, doesn't really know how he came up" Dave: "Yes, yeah." Daniel: "with it. Isn't that the one?" Dave: "Yes, yes, I think it is. I'd have to research exactly what it was, but I do remember hearing about that and it was, I think it was in Quake rather than Doom." Daniel: "Oh, okay, it makes sense." Dave: "Yeah, but then the Quake source code was released a few years later as well, sort of, I think probably early 2000s." Daniel: "Cool, I just, I just read that somewhere that you can make GitHub co-pilot, the AI co-programmer thing, you can make it spit out this exact function. And then some people were using that to prove quote unquote, that GitHub co-pilot is taking unlicensed work because that's, that's apparently not never been released under an open enough" Dave: "So, yeah, that definitely will have been out in the wild at that point." Daniel: "license or something like that. I mean, yeah, but like someone could have taken the quick source code and then just" Dave: "Wow. Okay, yeah, that would be a bit of a bit of a smoking gun, as it were, as to showing what it's doing." Daniel: "don't know, repackage it and just put it on their GitHub without like, without thinking about licenses licenses or something. So doesn't have to be super evil." Dave: "It's a murky murky world. No. Yeah, exactly. Oh, dear. Yes. Doom, Doom and Quake and source code there. I think 15, 16 year old me would have been really quite enthralled at the idea of being able to tell something." Daniel: "It's just murky." Dave: "Write me X in the style of John Carmack, which is, given I've not used co-pilot, it's my assumption of what you could do with it. I don't know whether it would give you anything meaningful for doing that." Daniel: "I mean, I don't know, probably not. Most of these, like, I actually do use GitHub co-pilot, yes, shame on me, but it's really helpful. But it is helpful for the small, tiny helper functions, you know, like write me a four line function that does, I don't know, this and that. And for that is really helpful because you can look at it and see like, okay, it doesn't have any glaring errors, you can write a test for it and see like, okay, it's behaving correctly. But especially in a language like JavaScript, where I'm not super firm in, it usually does it the, how do I say this, the approved way, the industry standard way that I probably don't know which, which one is the correct way. So that's, that's really helpful." Dave: "Yeah. Yeah." Daniel: "But yeah, I wouldn't trust a whole class written in that, let alone a whole engine." Dave: "I think one of the things with it is that I want all those benefits, right, of kind of reducing boilerplate and cutting developer time and all of that. But I also want the IP side of things to be straightened out. So there's a part of me there that would go, that would be excellent for the team that I work in in my day job for certain uses, right? A co-pilot that is sort of sitting there as you go, potentially offering advice as you've got things as well, right? If you think of it as like an extended auto-complete, almost in some situations, I think it could be really quite useful. But I want it to be trained on our source code and anything else it offers up to be nice and legal in terms of its origin and what it's giving us, because it worries me that at some point this is going to unravel." Daniel: "Oh, yeah, at some point, there's going to be a discussion and by that, I mean a legal" Dave: "And it's going to be a bit of a sort of, like I say, an IP nightmare after a point in terms of what's been generated by and what's not, if it gets used, you know, just wholesale." Daniel: "discussion about all these, what is the output of all these AI like in relation to their input, like, where's the, where's the legal rights to them and everything else. And I mean, of course you can, like there are various points along the, along the scale where you can really easily see, okay, this is okay, and this is not okay. Like for example, like, if I use Photoshop, for example, and then I select something and then I use the content aware fill function, then it will use an AI to fill that part of the image. For example, it's me who made that image, I have the copyright because I've just used the Photoshop tool, right. And not many people would probably debate that. But then on the other hand, if I tell an image creation AI to like, I don't know, make me a book cover in the style of, I forgot the name, some famous book cover artist who has a very distinctive style, then it's getting murky, right." Dave: "David Wood. No, I wish." Daniel: "And then, and then if, if, if GitHub copilot spits out an exact function that is copyrighted, and then like, there's really like, like, this is, this is basically a line that has" Dave: "But yeah, yeah, I agree." Daniel: "been crossed. And as I said before, like the line has probably been crossed out of negligence, and maybe not willingly by the developers of GitHub copilot. I don't want to like, make them sound more malicious than they really are. But yeah, there's a thing to be, to be said for checks and balances here. And that's, that's just a thing and a topic that's going to be with us for the next few" Dave: "100% yeah." Daniel: "years, I think." Dave: "Agreed, agreed. I think I want all the benefits from none of the downsides, I think is my bias here." Daniel: "Oh, yeah." Dave: "So, and those downsides feel like they've yet to be figured out in terms of the legalities and all of that. But Daniel, I want to move us back to where we were at the beginning of the show, because I remember you said you were going to ask me and talk to me about sort of systems and ticketing and organising work." Daniel: "Right." Dave: "So I think if we circle background to that, that could be quite cool to talk about." Daniel: "In this case, David, do you do agile?" Dave: "Oh, good question." Daniel: "So, um, yeah, Oh, yeah, I get that." Dave: "So which David are you asking you asking day job David or you're asking indie dev David because they're kind of two different types of developer. Yeah, go on then." Daniel: "Um, can you compare and contrast those two? Mm hmm." Dave: "So do I do agile at home? There's kind of almost no point in some ways because my development work on my indie projects comes in fits and starts as I'm carving out time from weekends and evenings and things." Daniel: "Mm hmm." Dave: "And this is probably quite crucial actually because to that end, typical agile as I see it and I'll get to that definition in a second, but typical agile is more about building up a cadence, like like a flow of work, right and a rhythm of what's been developed and delivered. And it's about making sure that you've got sort of the kind of correct rhythm and balances over the course of a period of time to them be able to iterate relatively quickly. And relatively sort of meaningfully in terms of your taking an input and everything else." Dave: "For my indie dev stuff because it's in fragments of time stretched out over periods of months perhaps before I release like a major release. The cycle isn't there. There's no rhythm there to sort of start building this up. But I do have there are practices that do come back over the line from sort of my day job work into my main d work. So I'm going all around the houses here because I've not defined what I think agile is before we get started. So maybe I should do that first and then I can talk about what comes comes back over from from that sort of world into my indie dev." Daniel: "Oh That's easy agile as a swear word that just means" Dave: "But so, Daniel, let me ask you a question. What do you think? What does agile mean to you?" Daniel: "Do the same work but call it differently and have lots of meetings. Um" Dave: "OK." Daniel: "I'm joking, of course. Okay. No so agile is Basically a the concept of let's break down the waterfall Development methodology that has been that was like predominant in the I want to say 90s and 90s and So just towards the beginning of the 90s I think like people were starting to think about like how can we make developing software easier and faster because back then people would usually Write down a specification and then write the whole huge program By that specification and then at the end find that oh, wow, we've made a mistake and we just like we The whole structure is wrong" Dave: "Mm hmm." Daniel: "And so that would be very costly and very slow way of developing software And so people were trying to be more agile by splitting up the work and then only specifying Um parts of the parts of the work usually very small parts that can be done in what's what they call a sprint so like That takes maybe a month or maybe even less and then um Just work on that have something and then see if it works run the tests and then maybe even release it into the world Or at least internally so it needs to be functional For some way and then iterate on that and so for the next sprint Be like hey, what can we do to improve this? What can we what can we change and this usually especially compared to waterfall waterfall leads to better software that is less stuck in these very rigid phases but at the same time in various companies companies it has this has grown to become very disliked by some people because Um, what various people do and I've like the names of these people escape me right now But there's like there's been a whole lot of books and stuff like that From people who were like, okay. These are these are the agile methodologies and you need to do this You need to do a sprint review meeting. You need to do sprint preparation meetings You need to do all these kinds of different meetings and they and those have become a little bit of a religion" Dave: "Mm hmm." Daniel: "and while the idea behind these meetings was intended to be um clarification communication and I don't know just like improving the whole thing many many, um People who write software came to dislike them because they became sort of a cult thing where like a cargo cult for Being agile, which means that oh, yeah, we're agile because we have these meetings But we don't really use them for the intended purpose because we didn't really understand it And so you're just stuck in a stand-up meeting where 10 people say I have no blockers and yesterday I did the" Dave: "Oh, yeah." Daniel: "Ticket number four seven eight five And today I will do ticket four seven eight nine and again, I have no blockers so next person and um That is just horrible and I very much dislike that but at the same time, um So for for my own project and that's project and that includes telemetry deck what I usually do is I have a Kanban board that is like one of those. Um, so you have like imagine a A table in front of you on the computer And there's like these cards and you can move the cards in stacks. They're stacked" Dave: "Mm hmm." Daniel: "Vertically, but you can move them horizontally from left to right. So the vertical thing is like basically you can sort them for By priority and then you can move them from left to right like one left means maybe I started working on this and then two left Me two right means I finished this and so that is something that I really used. Sorry" Dave: "Yep. So you end up with like, sorry, Daniel, so you end up with with effectively like a backlog or a not started pile, a doing pile and then a done pile in terms of your your table. You've got these these three columns effectively going from from left to right for camber." Daniel: "Yeah, that's a perfect description. Thanks. Thanks so much Um, and so that's something I really really use Because it is very chaotic, but it still helps me keep you keep a certain kind of overview" Dave: "Is that about right?" Daniel: "And it also helps especially with projects that as you described are like going in in small in small bursts um, because If I if I only have a little bit of motivation or time or both I can pick something that seems small and Easy to start and if I know, oh, I have a whole day a whole week in front of me I can pick something that is like hard. So I don't have to adhere" Dave: "Mm hmm." Daniel: "strictly by the By the hierarchy by the prioritisation um at the same time recently um, I started Doing more in that regard because um, I've kind of been thinking back to how I used to do project planning back when I was uh team leader leader in various organisations and of course you like with more people you need to do way more than that" Dave: "Mm hmm." Daniel: "And I actually started introducing sprints for myself again And the reason for this is that I felt like I'm I'm tackling various things that Are distinct tasks, but need to like are integrated with with each other like I have for example The final feature that I'm right that I'm working on right now. It needs various Changes on the server. It needs various changes in the way that the query language is is inter interpreted It needs of course a user interface and it also has some dependence even on the way charts are rendered and um, so these are all various like and that means at least 12 to 15 sub tickets And so I was creating all those tickets and I was like, ah, how can I force myself? to Not start the first three and then get sidetracked by a completely different feature and then the finals get never finished because that's something that happens sometime" Dave: "Mm hmm." Daniel: "um And so I actually started using GitHub's new sprints feature um, I'm giving myself one week sprints and um Um, yeah, it's it's been quite motivating at the same time. I don't have 40 or 60 hours of my week only for programming right now because I have a lot of other things that I need to do that" Dave: "OK." Daniel: "are not code um, so it's still a very um bursty style of development because um, uh, sometimes I don't know like sometimes I start a day and feel like oh I have the whole day for programming, but then something happens. Maybe a server problem. Maybe a an important customer who I wanted to um, convince to use telemetry deck Is calling or something like that or like Lisa is calling me and like hey, I need help writing" Dave: "Mm hmm." Daniel: "um documentation a blog post or something like that and then suddenly like my my day becomes something different and so um I can't really give you my Velocity, which is like how many tickets how many work items can I can I do in a week because It it's it varies wildly But I can tell you that it's like between five and ten Things per week or so and that's actually really refreshing to know that so I can like front load my week with hey Let's just drop five or five or ten things in there And see how many of those I can I can do and I can't promise that I'm keep up with it but right now it's really helping me and it makes development faster and It makes me really you know like when I'm when I add ticket number I don't know of eight of ten. I really start to see the interconnectedness and the the various features that could exist Um, completely separate from each other. They're enhancing each other and that's piece really really good So I'm I think I'm going to stick with it for a while" Dave: "That's cool." Daniel: "So So, right" Dave: "And what you're, what you're describing there as well means that like Kansan to me feels like the right sort of flow for itty bitty time stuff that that is in short bursts or is getting interrupted because it's very simple you're either it's either not touched it's in flight or it's done." Daniel: "So Yeah, pretty much" Dave: "Right. And prioritising the queue is great that helps you what you're describing takes it just one step further with your one one week sprints in that you're effectively theming your work by by pulling it together in that way all the all these these related tasks I imagine that you're picking up from there or there's a theme it's a feature it's a thing you know like you said it's a bit potentially it's it's all to do with funnels this week or whatever. Again that's really good because when you come back after a meeting or whatever it's very clear what you're picking up from that." Daniel: "Yeah, very much so and also it helps against like so the way I've implemented this is just I just added another column and that column is All the tickets that are in the current sprint, but I haven't touched yet And so these are separate from the beginning of the current sprint" Dave: "You can just come back to the queue. I imagine it probably makes it easier for for sort of regaining a context as well to some degree." Daniel: "But I haven't touched yet. And so these are separate from the big pile of things that I want to do someday And that really helps because when I come back I'm I'm less tempted to just pick something that is really easy and and and cool and quick to do And instead tackle the harder things that but that are part of the bigger theme or feature" Dave: "Yeah. Yeah. And I think that that that temptation is a big deal for Indies because you know who tells you know you know it's you you get to decide where things are going and I think even in your in your current situation of being sort of out of the solo part of things right because you got other people working with you but being mainly the solo dev. I think that that is is incredibly useful to you to have a system like this." Daniel: "Mm-hmm, please, please Please" Dave: "I wanted to talk a little bit about like my view of of our trial and like where I've seen it work and how I've seen it work so because I share some of your initial sort of cynicism about devs getting stuck in meetings all day and all of that I've seen it done in various different ways and I think to start." Dave: "Go for it." Daniel: "Oh one anecdote before you before you start and then you have kind of the floor for a while um, so I used to be uh also work as a consultant right and my hourly rate was outrageous And I was I was really good at it and and and people would pay me and to to come on these teams and Partially lead those teams or just take part as a programmer in these teams and at one point I was working for a very large automotive um... Company and they had a huge software stack and they had they were like comically They were the counter example against agile basically So I was sitting in these meetings and like out of a two-week sprint at least four full days We're just meetings and I was sitting in these meetings just thinking about oh, yeah Somewhere a counter of with a lot of money is just picking up every minute and I was like, yeah Go on with your meeting. Go on with your meetings it's okay" Dave: "Mm hmm." Daniel: "Okay, mm-hmm" Dave: "Yeah, that's a good point though right these things cost like they have a overhead when you get everybody together in a meeting because that's everybody's wages being focused on their time in that meeting for the hour so" Dave: "you sort of start adding up everybody's hourly rate and how long the meeting goes on for and it can be quite frightening after a point how much you know a single meeting can cost a business. Especially when you know the people organising these meetings tend to invite everybody to them as well as the other bit. So thinking about this actually this is a good, good kind of way to bounce into what I'm thinking about here in terms of what I've experienced because yeah I've seen that that effect." Dave: "And that sort of meeting for meeting sake kind of aspect creeps in as well." Dave: "So if I sort of wind back a little bit. Very rarely is anybody going to put their head on the line and say, oh we're doing waterfall. You know we're using prints prints to project methodology or whatever the heck from like you know the late 90s early 2000s and we're still doing waterfall like everywhere says they're doing agile pretty much." Dave: "And you're right in your assessments of it being sort of cargo called to you I guess is is a phrase that kind of works in that there are all these people who came out with books and does the agile manifesto which I can't quote verbatim I'm not that into agile. But there was this statement made, I guess early 2000s late 90s books came out. And what happened is is that almost everywhere kind of went this is the hot new thing we need to go do this." Dave: "And over the course of the last I guess 15 to 20 years somebody can correct me if I'm wrong I guess. And almost everywhere started experimenting with an adopting agile in one form or another. And certainly in the last five to 10 years I feel like everywhere I've seen as has been doing that." Dave: "The problem is is that it's usually we do agile but and then whatever is in that but bit afterwards is where the devil is in the detail and you find out that it's like, actually it's still just a waterfall approach. We've got this is the spec and there's no deviation from it at all and we're just slicing it up into two weeks at two week sprints." Dave: "You know with a kickoff and a load of like getting devs to agree to unrealistic targets by way of making them estimate things usually using like a points sort of scoring kind of idea where you don't say how many days you think something will take or how many hours." Dave: "But you say roughly you know how big it is relative to anything else by by giving it a point score. And in those situations where the core process is still really sort of waterfall or something else." Dave: "I don't think it works. But you may as well just admit that is what you're doing and and to work in that that that manner." Dave: "And I think that I don't think there's any one sort of pure way of doing our job that certainly sort of works brilliantly like I do think everywhere has to be their own, their own implementation of it and that actually comes out of the team and the people involved in the type of products you're working on and any other constraints to." Dave: "So I don't think it's a bad thing that everywhere is our job but necessarily, but the bad things are usually in the butt side of it." Daniel: "The bad things are usually in the butt David Wood" Dave: "And we're not, we are not having that as a show title. I'm sorry, Daniel." Daniel: "I completely agree with you like I can can come across as very cynical Well, but all these all these parts that you mentioned they're kind of like puzzle pieces and you need to" Dave: "But yes. So if I think about the places I've seen it work, and I'm not going to pick on any one particular team or company or anything like that." Daniel: "You need to know about them and then build a process that works for you and your team" Dave: "But if the composite of what I've seen work as it were is generally like a one week sprint with a team is going to be too short for weeks is sometimes too long." Dave: "Two weeks does seem to be the sort of sweet spot for for building up a sort of a cycle with things in some ways. But again, that varies from place to place. And then the other bits that I've seen work is that where you've got enforced meetings as it were or rituals if you want to call them that. Obviously they need to be bought into by the team and the team should agree what they think is going to be best for the way they work." Dave: "That is the approach of our job that I think works really well where everybody has a bit of a say into OK, we're a team, we're going to adopt some of these practices. What do we want? You know, we all understand there's a bit of a menu of options here and getting people to buy into that. And then the things I've seen really, really work have been things around. Well, OK, we will have a kickoff for any sort of new piece of work where the people necessary for making that thing work come together and just talk it through." Dave: "So this will be, for example, bringing it into mobile development. Perhaps you've got a new feature and there are some designs ready to look through set of screens. There may also be an understanding of what the data or backend API needs to sort of look like. And so a kickoff may well be that you have the designer talk through the designs and then the devs involved can then offer their feedback at that point." Dave: "You can have a bit of a two-way conversation, but they'll talk through the vision. If there's any other inputs into that in terms of what we're trying to achieve, why we're trying to do this, usually coming from a product owner or somebody in that sort of project management kind of space. And then if there are any other things in terms of constraints of the backend or that sort of thing, you'll get that input from the people in charge of that at that point as well." Daniel: "You You You You You" Dave: "And ideally, a kickoff in that sense doesn't need to take incredibly long. It takes as long as it takes to go through the screens, have a bit of a discussion, a bit of a back and forth, but you're essentially trying to get everybody aligned in terms of what they think the thing is going to be. And by doing that, you sort of set the developer up for a bit of success in terms of understanding outside of themselves what the designer thought this should look like," Dave: "what the product owner's input was in terms of what we're trying to achieve here and what the sort of outcome is for the customer." Dave: "And so actually, those meetings become valuable because this is context as a developer that if you were to just sort of go, okay, I've got a ticket. There's some designs linked. All right. There's an API spec over here. But nobody's told you, you know, the real reason we're doing this is because we've got thousands of complaints about this one specific bit of the work, right? Nobody's giving you that information. And, you know, in the process, you find an aspect of the design that doesn't really work. You're trying to take it another route." Dave: "So then, you know, when you're playing it back and you're done, you're like, okay, we went this way because of this and you've missed the big important thing. You know, this now doesn't solve anything. And although you and the designer did have a chat and you agreed it, you've missed the input from the other people. So what tends to happen then is that you will end up having to refactor or rebuild in some way. People will discuss it. Everybody feels a little bit bad because you've lost this bit of context or whatever and you might make some new tickets." Dave: "That's why you're working. I've seen happen a fair bit and it's because people are not talking to each other and you're essentially working through dysfunction at that point. So, you know, it would be it would be like sort of saying given somebody the remit to go and build out your funnels. These are the technical steps that you think it needs to have." Dave: "But actually, there's, you're missing the context about what people mostly want from the funnel that could be crucial in terms of going the right way with your, your data model underneath, for example, in your world. And so, yeah, by having this sort of discussion at the beginning, you can, you can de-risk to use a phrase, the work that comes afterwards, because you'll find these things out anyway, right?" Dave: "You'll test it. You'll find a fault, hopefully at some point or we've missed this or this will be better if it was in it this way. And I feel like nine times out of 10, a lot of these things could be resolved by just speaking about them upfront." Dave: "So that helps when there are things you know, and that's one aspect of it. So I think like, you know, meetings that are productive and that sort of a sense." Daniel: "You Yeah, you need to you need to be on the same page basically" Dave: "Great. And actually, I'm a big advocate for sort of kickoff meetings and bringing people together at the start of work and that sort of thing. Yeah, we're seeing it not work. And actually, I've briefly skimmed over this, but there's the inverse of the meetings I've described where people get together usually as a whole team rather than just specific people involved where people will talk through and have a retro over the work that's been done in the last sprint. When they ran effectively and, you know, by somebody from usually a, like an agile practitioner or a project manager or even somebody who's just outside of the team comes in in one way or another." Dave: "But where they ran well, a retro is really powerful because you'll drive out like the things people have come up against but not been able to talk about very well for whatever reason along the way." Dave: "Where they ran badly, a retro where you look back over stuff just becomes a blame game and people use it to air grievances and that's never really productive for anybody overall. You will notice the things I'm talking about has been beneficial to our trial. I've not talked about the code. I've talked about the people." Daniel: "Yeah, totally." Dave: "Yep. So I see it when it works well. I see it as a way of putting a ring around some of the people's stuff that makes things work. And if you do it right and you're not having people in pointless meetings all day, then actually it makes it better for the devs because you're clearer about what you've got to work on. You know, you have these quick bursts of contact time with people and then you go and get on with it. And then there's other quick bursts for you to bring it back to people. And that's a vision of sort of the agile meetings and cadence that I really like because ultimately you're building software for other people." Dave: "You know, so you can't just sort of be a developer in a cupboard who takes a ticket and spits out whatever I mean you can, but somebody else has got to then bring your work together and bring it to people." Dave: "I think it works much better if you're talking about why you're trying to do something, what you're trying to achieve and that you've got these points that are of time where, you know, it's okay, we're kicking this off, we're coming together to do this. Or we've completed X, Y or Z. Let's go and check how we've done. I think there's a lot of value in that." Daniel: "I really like that So what you're saying is basically Gone" Dave: "So, cool. And you'll also, sorry, Daniel, I was going to say you'll also see how it doesn't scale very well to a solo developer right, you know, you're not trying to organise time with yourself." Daniel: "Yeah, totally" Dave: "I mean, you can perhaps to try and put different hats on and do these meetings. I'm the designer now. Here's this. I'm the developer. I don't agree. We'll do it like this. You can do that with yourself. It'll be a bit weird." Daniel: "No, but it's gonna be more important once we are more people and also when I work together directly with my co-workers It's usually we usually pair program and so a lot of the stuff it's happening in another way But I completely agree that it needs to happen and what I also hear from your description and that's I very much on board with that is like You you need a functional team. You need a team that works well together. It has that good social hygiene basically And then you can reap the benefits of agile, but if you have a dysfunctional team where no one no one likes each other Or no one knows how to talk to each other Agile is not gonna fix that" Dave: "No. And actually, it'll probably amplify it. And this is where you get the everybody's in a daily stand up where you just go, yeah, no blockers, you know, move on. Nobody likes that really, but people do it if they think they've got to tick the box. Again, I've seen ways of breaking that down. So you go, okay, nobody likes these meetings, so we'll stop having them." Dave: "And actually a team that I'm working in at the moment, that's what we've done. We, we, we, we, from the get go, we said, we're not doing daily standards, we'll have a one, one meeting a week, where we come together as a sync meeting. There's a bit more than a stand up. And then otherwise we will use Slack and we will use asynchronous updates from everybody. So there's a daily thread that goes into the channel and people give their updates on to this, this post and thread." Dave: "And again, we're not going to write war and peace when we update there it's literally what am I on what am I blocked by what have I landed sort of thing right so that most and usually people are saying what they've got on that day and what they're blocked by more than anything else. And that works. That works really well because when people say, oh, I'm a cross X, Y or Z on the thread of the people try men and go, well, okay, I'm doing this today, can we chat, you know, and it forces those conversations which a stand up should do." Dave: "But also if you're like, okay, I'm fine. I know what I'm doing. I know what everybody else is doing. You can skim read it at your leisure and not let it disrupt your flow as well. There's no like dreading nine o'clock because that's when this hour long meeting is going to happen or whatever for stand up." Daniel: "I think I very much like this topic, but I know that we both need to Finish the show pretty much on time today Because otherwise my very hungry cats will devour me and that that would be the end of the show which would be pretty sad But I have one more question in in one or two sentences. How is Toot SDK doing?" Dave: "Very well." Daniel: "Cool Is it released?" Dave: "Two words. It's not released yet as we speak so massively over ambitious when we last spoke but yeah, I think if I talk to what what's happened over the last few weeks with to the SDK, I piled into it a bit over the holiday break then I had to stop because otherwise I was going to have no" Dave: "day. And similarly Constantine had a good break over over the Christmas period. But we're back now. And we're just trying to get the post information working properly so master on Pleroma all of these things, the API is that you talk to they give you back HTML for a post. Okay, which is that's fine. You know, works well for the web." Dave: "But for showing on our side in iOS we want attributed strings for some of this stuff, because people make, you know, they can make a post where they they have bolded text italics text whatever." Daniel: "Right. Oh, I see" Dave: "And so we're working on that we're making a parser for this stuff. Yeah, and there's a couple of ways of doing it and the first way is quite brittle and quite slow and a number of people who are testing to SDK pointed this out to us." Daniel: "Doesn't that spin up a complete copy of Safari in the background" Dave: "And it's actually the way everybody gets told is that you can create an attributed string give it the HTML and I tell it the document type is HTML and it will try and give you an attributed string back. And that's the reason why we're making our own parser. Yep. So anyway, parser for attributed strings and potentially something similar that gives you Swift UI views. And with all of this we're trying to make it work nicely for dynamic text and also get the custom emojis that you can use in line with your text on master on. We want them there as well. So there's a bit of complication there's a bit of complication around okay how do we load those asynchronously and still show them nicely in with the text and again make sure that we're not introducing sort of brittle ways of working that an app shouldn't have." Daniel: "Yeah, you get that You" Dave: "So, yeah, I still think we're odds on for a release over the rest of this month, but I'm not going to hold myself to a date now like I want this bit nailed and then we'll release it publicly." Daniel: "Right And especially you don't have to like you can change stuff under the hood as long as your API is more or less stable" Dave: "And once that release happens, it won't be a full release right it's it we're covering about maybe 20% of the master on API at the moment, but we'll be in a good position to invite other people to assist in the effort with with covering the rest. Yeah, and that's the thing." Daniel: "Which it sounds like it almost is then it's fine to to refine these things continually with the feedback and input from your users" Dave: "Yes, exactly. And, you know, that's going to be a good place to be is that we'll we'll have the SDK there people can download it and take a look potentially build apps on top of it." Dave: "But equally once it's public if somebody wants to add add something, fix something submit PR. Yeah, we're going to be totally up for that. Because that's that's the idea of the SDK in the first place is that multiple people working on it is going to light on the load of this sort of stuff for us for us all. So, I'm hoping that users of the SDK will also participate if they come up against anything like that." Daniel: "Awesome" Dave: "Yeah, so I went from two words to 10 minutes but there we go." Daniel: "Oh well, um, to like two sentences can be 10 minutes if you're a politician or Dave Wood apparently" Dave: "Yeah, well I speak in commas Daniel so there we go." Daniel: "And then you add some parentheses in there like as long as you don't put parentheses inside parentheses" Dave: "Yeah, yeah." Daniel: "Um, then then we're good. I think because footnotes on podcasts. They don't they don't work. I would I would I would love having footnotes on podcasts" Daniel: "I would love having footnotes everywhere. I write basically but okay, we're going we're going deep into the woods now. Okay. Um, David, where can people find you online if they haven't if they want to hear more from you" Dave: "Yeah, if you want to read many commas from me, you can go to my website at davidgarywood.com. You can also find me on master on at davidgarywood@social.davidgarywood.com. Both of these will be linked in the show notes." Dave: "How about you Daniel?" Daniel: "I make telemetry deck which is app analytics, of course, and you can find that telemetrydeck.com and you can find me in social media mostly at daniel@social.telemetrydeck.com. Because we're Mastodon friends now or Mastodon fans? I don't know. We're on the Fediverse" Dave: "Yeah, I'm Daniel Gary indeed and I am tooting along with TootSDK." Daniel: "Dave, this has been amazing. Um, it's always nice to hear you and hang out with you and I can't wait for the next time" Dave: "Likewise Daniel, catch you in two weeks." Daniel: "Byeeeeee!"