Code with Jason
Code with Jason
300 - TDD and AI with Paul Hammond
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
In this episode I talk with Paul Hammond about TDD as a discoverable principle—something alien programmers would independently arrive at. We discuss my "specify, encode, fulfill" formulation, why programming needs theory instead of rules of thumb, and the business payoff of technical quality: Paul returned to a well-built project after 18 months and delivered months of planned work before Christmas.
Links:
A Snail Mail Newsletter For Coders
SPEAKER_00Hey, it's Jason, host of the Code with Jason podcast. You're a developer. You like to listen to podcasts. You're listening to one right now. Maybe you like to read blogs and subscribe to email newsletters and stuff like that. Keep in touch. Email newsletters are a really nice way to keep on top of what's going on in the programming world. Except they're actually not. I don't know about you, but the last thing that I want to do after a long day of staring at the screen is sit there and stare at the screen some more. That's why I started a different kind of newsletter. It's a snail mail programming newsletter. That's right. I send an actual envelope in the mail containing a paper newsletter that you can hold in your hands. You can read it on your living room couch, at your kitchen table, in your bed, or in someone else's bed. And when they say, What are you doing in my bed? You can say, I'm reading Jason's newsletter. What does it look like? You might wonder what you might find in this snail mail programming newsletter. You can read about all kinds of programming topics like object-oriented programming, testing, DevOps, AI. Most of it's pretty technology agnostic. You can also read about other non-programming topics like philosophy, evolutionary theory, business, marketing, economics, psychology, music, cooking, history, geology, language, culture, robotics, and farming. The name of the newsletter is Nonsense Monthly. Here's what some of my readers are saying about it. Helmut Kobler from Los Angeles says thanks much for sending the newsletter. I got it about a week ago and read it on my sofa. It was a totally different experience than reading it on my computer or iPad. It felt more relaxed, more meaningful, something special and out of the ordinary. I'm sure that's what you were going for, so just wanted to let you know that you succeeded. Looking forward to more. Drew Bragg from Philadelphia says, Nonsense Monthly is the only newsletter I deliberately set aside time to read. I read a lot of great newsletters, but there's just something about receiving a piece of mail, physically opening it, and sitting down to read it on paper that is just so awesome. Feels like a lost luxury. Something about holding a physical piece of paper that just feels good. Thank you for this. Can't wait for the next one. Dear listener, if you would like to get letters in the mail from yours truly every month, you can go sign up at nonsensemonthly.com. That's nonsensemonthly.com. I'll say it one more time. Nonsensemonthly.com. And now without further ado, here is today's episode. Hey, today I'm here once again with Paul Hammond. Paul, welcome.
SPEAKER_02Hey, thanks for thanks for having me again.
Is TDD Discovered Or Invented
SPEAKER_00So this is your second time on the show. I really enjoyed our first. Um I believe somehow I found you on LinkedIn, and then we had that episode, and I felt like you and I really connected and had some good stuff to talk about. And so here we are again. Um there are two topics you and I talked about pre-show. Um one is TDD and the other is AI. Um two topics that a lot of people are probably really tired of hearing about, but I'm not, and I think there's probably a lot of people who are also not tired of hearing about these things because they're both very deep. Um let's start with TDD. So I I I was sharing with you pre-call um my thoughts around this Kent Beck uh canon TDD post. Um and you know, Kent Beck, I I understand that he's kind of the main progenitor of TDD. Like my understanding is he doesn't claim to have invented it. Uh he he kind of independently rediscovered it, and he's been kind of the main guy out there telling the world about it. Is that kind of your understanding?
SPEAKER_02Yeah, so that's exactly how I understand it. I think um I can't remember whether he said that in the in the TDD book that he published. Was it because was it late 90s, early 2000s he published that book? I can't remember whether he explicitly says it in there or whether it's like a blog post or something, but I've heard him say the same thing that he didn't invent it, he reinvent it, sorry, he rediscovered it. Um and certainly I think was very heavily influential in kind of um re-popularizing it, the idea. Yeah. That's my understanding.
SPEAKER_00Yeah, and I think there's an interesting clue there, it's a foreshadow to these thoughts I've been thinking. Um we we use two different words there, invent and discover. Um was TDD invented or was it discovered? I think you could make arguments either way. But here's what I started thinking about. Um this this might seem a little kooky and out there, but we'll we'll we'll get back around to the main point. Um sometimes I think, you know, if there are aliens out there on other planets, which I assume that there are in the billions of galaxies and the billions of stars per galaxy, and what surely must be uh, I don't know what a billion times a billion is, but that many planets, and then some, there must be intelligent aliens out there who are doing similar stuff to us, who are who are at least on par with our level of intellectual sophistication and technical sophistication. Um and if those guys are out there, uh what have they discovered or invented that is the same as what we have? You know, surely they must have discovered things like prime numbers or the Pythagorean theorem. If they have the Pythagorean theorem, it must be the exact same one as ours, because it can't be any other way. So there's those certain things that just can't be any other way. Um before I continue, just just for fun, um, can you think of any other things? Like if if there's aliens out there with a technological civilization, what what stuff might they have that's the same as ours?
SPEAKER_02Oh, yeah, I mean it's it's really interesting way to start a uh podcast, isn't it? Start talking about aliens and stuff. But um the the thing, like I mean, I actually kind of agree that the uh you know I wasn't expecting to be kind of talk about this one, but the the sheer size. So like I I'm a bit of a kind of space nerd as well. I watch tons of videos. This guy, Anton Petrov, who I think is amazing, does all these uh space videos on um YouTube and so on, he's fantastic. He always talks about like you know, um he always talks about scientific discoveries and new papers that have come up, and he um it's he's kind of he's very well known for like he's the it's not aliens guy, because every time you know it's always never aliens with him. If he ever says it's aliens, I'm gonna believe it. But um, in terms of um I guess the kind of universal truths, if you like, that would be rediscovered. I mean, one that springs to mind for me is uh evolution, the the theory of evolution, um, and the idea that you know God trying to describe uh evolution off the top of their head. But you you you know, the the it's it's I think there's a certain kind of um underlying kind of scientific truth there that would be rediscovered by like if even if you didn't talk about aliens, if we talked about human beings and we said somehow you could press a button and burn in all knowledge that human beings have ever had throughout all history, and um all the books have gone, everything is gone, it might take a long time, it would take a long time, it might take thousands of years, but eventually humans would rediscover evolution um and they'd discover you know Darwinian selection and all of all of that stuff again, because they're universally true. Um so I guess like that's the one that springs to mind for me. We're talking about something like because I guess what you're trying to what you're saying here is that um test-driven development is a kind of um it's almost like a universal uh truth, if you like, or it's it's something that would work under any kind of circumstance and could be re uh rediscovered, as you say, as opposed to being necessarily invented. Yeah, is that fair?
SPEAKER_00Yeah, and I'm trying to build up from a very solid, uh uncontroversial uh base argument and build up from there. Um you know, uh it's it's it's you know, if if you buy the idea that aliens exist, uh, and it doesn't matter if you actually think there are because um uh the argument doesn't depend on you buying that. Just suppose there are. Um I don't I don't think it's a big leap to say they would have discovered prime numbers, for example, or the Pythagorean theorem. Um they they probably probably would have discovered calculus, you know, not specifically Newton's calculus or Leibniz's calculus, it would be their own calculus, but there are certain aspects of calculus that are essential and some that are incidental. You know, between Newton and Leibniz, uh they had stuff that was different and stuff that was the same. The stuff that was the same was was the essential parts, and then the differences were the incidental parts that were incidental to each of their own flavors of calculus. Um and so they they also the aliens would also have surely discovered computation. Um, because computation, of course, well predates uh mechanical computers. People have been doing computation for millennia. Uh any anytime you're carrying out uh when you evaluate a mathematical expression, two plus two equals four, that's a computation. Um and then it stands that um if you have computation and you know how to do mechanical, electrical engineering and stuff like that, eventually you're gonna say, hey, let's make a mechanical computer which can do computations automatically. And if there's uh computers, then there's surely alien programmers, because computers need programmers. And if there's alien programmers, then surely they will have discovered test-driven development. That might seem like kind of an arbitrary thing to expect to have been discovered independently. Um, but I don't think so. I I think it's one of those things like, you know, calculus, for example, was discovered at least twice independently on the same planet. Uh same thing with evolution. You know, Darwin discovered it, discovered it, and uh that other guy whose name I can't remember discovered it around the same time.
SPEAKER_02Is that the one you're thinking of?
Specify, Encode, Fulfill vs Canonical TDD
SPEAKER_00That doesn't ring a bell. For some reason the name Wallace is coming to my mind, but I don't know if I have it right or not. Um anyway, multiple times, you know. Um and and all test-driven development is it, and and here's my personal formulation of it, is um you decide on your specifications and then you encode your specifications in tests, and then you implement the behavior that fulfills those specifications.
SPEAKER_01Yep.
SPEAKER_00And there's a certain logic behind it. It's really not arbitrary. It's um there's something very essential about it. And and I'm very careful to um speak at a high abstract level when I say specify, encode, fulfill, because I want to separate what's essential from what's incidental.
SPEAKER_01Yep.
SPEAKER_00Um and and here's what I was getting at pre-show when I when I said there's Kent Beck's canon TDD, which is like, you know, here's the canonical version of TDD put forth by the main TDD guy, period. Um and I'm gonna be conceited enough to to propose that I have something better. Um so what I think is is better, at least when teaching beginners, is this specify and code fulfill loop because uh Kent Beck's Canon TDD, um let's see if I can recite it from memory. I I think he says step one, make a list of scenarios that you that you want. Um step two, write exactly one test, you know, take exactly one of those scenarios and write a test for it. Um then run it and and let it fail. Then step three, write just enough code to make that test pass. Um step four, optionally refactor, and then step five, repeat from step two until the list is empty. Are you looking at it right now by chance, Paul?
SPEAKER_02I am I am reading it right now, yeah, and you you've remembered it perfectly. I don't know if you had it on your screen there, but um it's uh yeah, it's that's that's how he describes it in the blog posts. Yeah, okay.
SPEAKER_00Yeah, I I read it very recently, so I I remembered it. Um but I think that um so I I think the difference between Kent Beck's Canon TDD and my specify and code fulfill, um, which I've I I'm working on a blog post of my own. The way that I've formulated my specify encode fulfill, it's not meant to be prescriptive, it's meant to be descriptive. Um it's it the uh uh the canon TDD, I I I feel like it is an algorithm, and that's not a criticism of it. Um it's it's just an algorithm, here's how you do it. Um, which is fine and good, but before we get to the algorithm, I think it's a good idea, good idea to say, here's what it is, before we get into here's exactly how to do it, because some of those um details when you're just getting started can be uh confusing and and distracting. And in the beginning, I think we can do without them.
SPEAKER_02Yeah, yeah. I mean, uh one thing there's a couple of kind of questions that I I have for you there. I guess I guess one is um so it if I understand what you're saying, it's it's it's kind of like um taking a little bit of a step back to look at the bigger picture rather than rather than going straight into the detail. But I guess one question for you is do you agree with the detail there? For example, it's always one test at a time. Is that is that something fundamentally not controversial? That's you know, uh we agree on that, it's always one test at a time.
SPEAKER_00I agree with the one test at a time, and that that's the way that I do it. Um I don't know that it's inarguably essential. I think you could do, for example, you could write two tests and still uh get by with that, and you get basically the same benefits.
Teaching TDD Through Instant Feedback
SPEAKER_02Um what one of the frustrations that I've had with um not necessarily with TDD, but with communicating the value of it over the years has been, I can't remember now, because it's a while ago that um I obviously went on the last um podcast with you, and I can't remember if I made this point uh at that time. So if I'm repeating myself, apologies for that. But what one of the things that I I have found a little bit frustrating at times is that um when you're actually doing it day-to-day, um, and and let's forget about AI for now. So let's, you know, you you're doing it as a should we say, just a normal programmer, um, no AI assistance. There's this really kind of powerful um feedback leap that you get into quite quickly in my experience. And you know, you you you get this um instant feedback the moment that something goes wrong, you you see it straight away, right? You see it in seconds. And one of the things that I've kind of thought about in the past in terms of teaching it is almost like if you take a step back and rather again, like you're saying, rather than go straight into the detail, almost like teaching a class, I think one of the ways that I would want to do it is almost have like a complete example. Like here's the end point, here's where you can get to. And I've actually done this previously in a kind of informal way, where I've been working in places and I've shown people um, like I build, like, say, you know, let's say it's a React app, I'd build like a non-trivial React kind of maybe application or or at least a component's a bit non-trivial. And then I'd say to them, so the the thing that I'm going to argue is that um you if you work in this way, you're gonna get this instant feedback and this higher confidence that you've not broken any existing business behavior. And it should be uh from the perspective of of the business behavior, you should be able to like if you break something, you should be able to tell in a second or two, and you should know why that matters to the business, right? And so what I would do, and what I've as I said, did it kind of fairly informally, but is I would give them uh a working application and I'd say, okay, I'm gonna run the test on this screen. Now you go ahead and tell me where you you want to break the code, and we'll just go in and break something, and then um you would go in and you know, say, okay, we'll turn that greater than to less than something like that, you know, in the code, hit save, test should rerun, and you should see instantly, here's the business reasons that that thing failed. And to me, that's almost like starting with a eureka moment rather than going into the um that's the idea anyway. So rather than going straight into the, you know, this is how you do it, you go one test at a time, and you know, you you go into this cycle, it's almost like here's the value of it, and you can see because I when I'm working on stuff myself, break stuff all the time, you know. But I I find out seconds after I've done it that I broke something. And it can be very frustrating though to have this perspective, because in order for that to work, you need a kind of non trivial example to show it to people. Do you do you see what I mean? So it's it's kind of well, I don't know if that helps kind of um you know, uh uh answer that a little a little bit. I guess my perspective on it is that showing the value of of the technique um before going straight into the how is is really kind of um i I think it's very valuable to do that and and you know to aim for these kind of hopefully light bulb moments that um people can experience.
Toward Programming Theory Not Rules Of Thumb
SPEAKER_00Yeah. Yeah I think what you're saying is very consistent with where I'm coming from. I I I I think the idea of levels of abstraction is very relevant. You know this this canon TDD is at a good level of abstraction for what it is, but I find myself wanting to go uh uh even higher like to the top level of abstraction that that you can possibly go to um which you know to to speak to what you said it's like you're starting at a high level of of abstraction with here's the value of this practice um okay now that we've conveyed the value of the practice let's talk about how you achieve this in order to get this value and that's of course a lot more motivating than starting with here's how you do it and then at some later time communicating why you just went through everything that you that you went through. I'm working on I've been talking about this book that I've supposedly been working on for like more than a year. It probably will be several years before it even comes out if it comes out but this book is basically like my version of like code complete or something like that where I just try to do a coherent brain dump of everything that I know about programming. And one of the underpinnings of it is that in in programming we have a lack of of we have a lack of theory like musicians have music theory um what else um there there's mathematical um theory number theory that's an example I don't know can you think of any other fields where they have theory um I mean math is the one that springs to mind medicine um yeah yeah yeah um yeah and and obviously science again oh yeah it springs to mind of course yeah yeah philosophy um so there's these other uh more mature fields which have theory behind them but you never hear people talk about programming theory um what we unfortunately have more of is like uh flame wars and such online where people debate um in in kind of a well and it not just debates but in teaching people go by these rule of thumb kind of kind of teachings and um the how I define rule of thumb I got this from David Deutsch in the beginning of infinity um a rule of thumb is like a prescription without an explanation so for example uh with with regard to duplication for example the rule of three that's a rule of thumb you know tolerate duplication uh twice but on the third time unify it but it it tells you what to do but it doesn't say why and it's kind of arbitrary like why two and three why not three and four or some other number and I think we would be much better off if we had theory behind these things uh where it doesn't say and and to me theory isn't about what to do theory is about what is here are the uncontroversial facts and from these you can draw what to do yeah it's it's interesting that you mention the rule of three thing because it's always been something that kind of annoys me a little a little bit that one because it's like you say it's very kind of arbitrary and it is a rule of thumb it's it's um you know it's you use the the word prescriptive and that's exactly what it is.
SPEAKER_02Before we um started this this call because we had a brief chat um and I I mentioned of course this is relevant to what you're saying right so I mentioned that obviously you know as you have as well been working quite heavily with ai recently and I um so I I mentioned the dot files I I created which are just my personal dot files. When I when I first so what I did was I created a um a Claude MD file with just loads of my own kind of perspective and opinions in there. And one of the things actually was was about um the whole do not repeat yourself kind of thing right and but what I said to it and I I put these rules I'm I'm trying to find the uh the specific file now but um I'll find it now but uh basically what I put in there was that um rather than having like a uh you know an arbitrary rule set like that like you know just look for three you know duplicate instances of code to me where you come to the actual underlying meaning and and um uh the the the real kind of rule if you like is uh dry is about knowledge is the way I see see it it's about um it's about duplication of knowledge in the in the domain and to me it's like you can you can end up in a position where you've got um the the same code might be repeated multiple times but it's expressing different knowledge about the system um and in which case just leave the duplication do you see what I mean don't go for the uh the abstraction but sometimes you can see quite early on you know actually this this is r relating to a specific piece of knowledge in this domain and therefore I can make that abstraction early because I understand well to me that's about understanding the underlying reason as to why you apply that rule right um right because I I've said this before and I have a a blog post about it like you can have two pieces of code which are totally identical but they don't constitute duplication because they they don't have the same behavior behind them.
SPEAKER_00If if one changes it's only duplication if it's a logical necessity that the other one changes too. And if that's not the case then you shouldn't unify them because that wouldn't make sense.
SPEAKER_02Yeah um yeah I I think what's interesting now though is that so what I've just I've in this chat now I've just linked you to that um you can you can see this this kind of skill that I've written and uh if you search for dry in there you can see now the the point here is that you know what what I've been trying to do with with the kind of AI stuff right recently is to put these kind of rules that have always worked for me into um into a format that can be kind of reused by AI and kind of gets AI to use these kind of same underlying principles. What's quite interesting is this so what I've linked you to there is a page on my uh dot files which is about refactoring and it's a skill in claude so I'm using claude claw code. What I like about this is that um inside this particular skill so I'll just read a tiny bit out um so I've got just to relate to what we were just talking about uh dry and I've got dry equals knowledge not code abstract when same business logic concepts so semantic meaning uh the code would change together if requirements change obvious why it's grouped together keep separate when there's different concepts that look similar so it's structurally similar but it's it's a different concept would evolve independently and coupling would be confusing. Now what I've also done in that um in that refactor kind of skill is I've got a list of root rules for when not to refactor. So right at the very bottom of that file I've got don't refactor when code works correctly and there's no bug to fix, when there's no test demands to change, um would change the behavior that's uh a feature not refactoring. And then the code is good enough for the current phase. I'm not sure actually because I re- recently re- I recently um changed this this structure so I'm not exactly sure if I've got the um because I had some of Sandy Metzi's rules in there previously as well and I think um just looking at it now I might have taken it out of this specific file but um but what's nice about this though is that what I found is by having these kind of centralized rules AI will push back sometimes. So I'll say to it um you know um I've just done a big piece of work have a look at see whether this code can be nicely refactored. And now what it started to do is is to argue back with me and say actually this doesn't need to be refactored because you know um it's actually perfectly good for what you need. Maybe you could consider refactoring later if XYZ becomes you know in a a thing. And I found that having these kind of specified um kind of rules really helps with that kind of flow. You know and it's it's it's become much more satisfying to me to um to work with these tools when you've got these kind of underlying rules if that makes sense.
SPEAKER_00Interesting. Yeah I've I've found similar things like if I give Claude some uh rules to follow it it does a pretty decent job most of the time of of following those um yeah so let's see I kind of lost my my train of thought um but I I I think we're talking about the idea of uh principles um you know theory and principles and and I think it's uh it's it's really valuable to to graduate from that kind of like uh rule of thumb uh it I almost think of it as kind of like the medieval craftsman um approach it's it's like you know you you watch the the cabinet maker doing his thing and you just do what he does and it's like why am I doing these things? I don't really know exactly I'm I'm just copying because that's what he says to do. And if I practice these movements and techniques enough times I'll get the same results as him even if I don't understand why I'm doing what I'm doing. And I feel like that's kind of the maturity level that our industry is at. Yeah.
DRY As Knowledge And When Not To Refactor
SPEAKER_02Yeah it reminds me of the kind of production line thing the Henry Ford thing where you know you take the specific skill out of each kind of like smaller part of the system and you just make it make that thing kind of reproducible like a rubber stamp almost but people don't necessarily understand fundamentally why they're doing things a certain way um yeah and I I think that's it's it's definitely uh it's definitely true. But having having said that then the question becomes about like what are the kind of underlying truths are there are there some to be discovered and will they be uh will they remain uncontroversial? Do you know what I mean? Because people like to argue these things and um you know so I guess it's to me then it it becomes quite an interesting you know what are the kind of underlying principles that are true.
SPEAKER_00Yeah well again in that book that I talk about so much in the show, The Beginning of Infinity um David Deutsch talks about explanations and the difference between good explanations and bad explanations. And first of all he says science is all about explanations. You know the the goal isn't to come up with hypotheses that merely predict the outcomes of experien experiments or anything like that. It's to come up with explanations true explanations about reality and what he says and I think he got a lot of this from Carl popper is a a good explanation is hard to vary. So if if you think of like for example um the explanation for why we have seasons he uses this example in the book um it's you know the earth is tilted at 23 and a half degrees and and so sunlight reaches the earth um at a more oblique angle in the winter than in the summer when the sun's rays are more direct. And so in the winter there's less light per unit area reaching the ground and so there's less energy per unit area and so that's why it's colder. You can't vary that explanation very much and have it still work. Whereas like he compares that with uh myths about why there are seasons uh like there's a a god who goes away in the winter and comes back in the summer and when she's gone it's cold because she's uh and he's like you could vary that as much as you want and have it be the opposite um and so I think about the same thing with with programming um there are rules of thumb in programming that could be varied quite a bit um without um um they don't have enough detail uh because the more detail an explanation has um the more it explains um and and if an explanation is so general that it it can be varied quite a bit then that means that it doesn't explain very much so again to pick on this rule of three which I despise so much um why two and not three you could vary it it could be three and not four um and there's there's plenty of others that are the same so um if if we get to work on creating this body of programming theory how do we know whether it's any good or not um if we have really specific explanations theories um that are hard to vary I think that's good evidence that we're onto something and those things are going to stick around for a long time and they're not gonna be overturned.
SPEAKER_02Yeah and I guess I guess one thing to maybe add to that is that they could be rediscovered and they'd be rediscovered again with the same level of kind of non-variability or or little scope for variability I suppose. I think that makes sense.
SPEAKER_00Exactly like if you go back to this thought experiment of what would alien programmers independently discover, they surely would discover problems with duplication and they would discover remedies for duplication and and what would they independently discover and not it's a good perspective I was going to say like a thought experiment but it could as you say it's it's almost like you know it's it's a thought experiment that could lead to um I guess those kind of more universal truths I suppose yeah it's it's uh it's quite a lot to think about to be honest.
SPEAKER_02It's quite um yeah it's a really interesting one.
Encoding Principles For AI To Push Back
SPEAKER_00Yeah and I hope I hope that this does provoke some thought for some people um I feel like the software industry could benefit a lot from um the kind of in in science and philosophy this tradition of criticism. And it's a um methodical criticism it works via conjectures and refutations. Somebody conjectures an idea um and then that idea is subjected to criticism and if it if if the attempts to refute the idea the hypothesis fail then that doesn't necessarily mean it's true but if if we can refute it that definitely means it's false but if we can't refute it then we can tentatively accept it as true.
SPEAKER_02But I don't feel like in programming we have um we have that level of maturity in our discourse um we have again flame wars and stuff like that where people kind of defend uh their beliefs emotionally um rather than dispassionately examining ideas together yeah so the perspective of of the kind of book idea I mean have you have you actually started writing it is it is it um yeah so is the idea that you I mean I'm just kind of speculating now based on what you've been saying but is is it is it almost like you is it almost like taking an idea or a truth that that you think has been discovered or is is there and then analysing it to you know I don't know I don't I'd almost based on what you're saying I almost think it'd be like really interesting to have like almost each chapter is um you know I I could see it structured in that kind of way where you've got like each chat chapter is a principle and then you go then you actually kind of attack it from that perspective. Do you see what I mean? And like here's here's the way that we could attack and strip out you know these things about about that idea that actually might not be true and here's how we can evolve like um a more kind of fundamental truth by you know maybe almost I don't know I'm quite thinking out loud here but it be like an interesting thought exercise would be an idea that seems to be applicable and seems like a good idea on the surface but then when you start chipping away at it you find actually there's some dents in this in this idea but maybe that takes us to a more kind of fundamental um uh truth do you know what I mean because maybe yeah if if if if you've got an idea about a subject I have an idea about subjects so idea A idea B if during the course of a uh a debate your idea kind of exploits certain um flaws in my theory and my idea maybe shows certain flaws in your theory but then we come together and create a new theory theory C which has n neither of the the flaws of the original and only the strengths then maybe that's like how you know how how how stronger ideas and principles are discovered over time.
SPEAKER_00It's interesting I know it's quite interesting isn't it yeah yeah and I think it could be really useful um I the way I have started the book and I find this um this area of of writing really difficult um the way I'm starting it is is to talk about uh talk about the way that we decide in programming what's a good idea and what's not um because okay all of this started from my repeated not very successful attempts to refute the idea of service objects um and I'm I'm I'm sure that you've encountered this idea and have feelings about it yourself have you encountered this idea of service objects?
SPEAKER_02Um I have but it depends on because people define these things in different ways. So um and obviously I spend a bit more time you know more kind of on the front end where you don't necessarily see these kind of patterns as much. But if you like if you were to define a service object like how would you define it according to your kind of understanding of it?
SPEAKER_00I mean that question right there kind of speaks to one of my biggest arguments against service objects is that nobody even agrees what one is and how can you have this uh principle that you follow if it's It doesn't doesn't even really have a definition. In my experience, when most people say service object to answer your question, there's talking about a command pattern object. And in general, I think people are looking for the answer. You know, my code is messy. What's the answer?
SPEAKER_02Yeah.
Beyond Craft Pride To Business Justification
SPEAKER_00But unfortunately, there's not and there's not one single answer. Like how should I structure my code? There's not one answer to that. People it's you know, people are looking for the equivalent of a weight loss pill. Um, and when I say, hey, weight loss, this weight loss pill is not the answer. And the the the response is okay, so which weight loss pill is the answer? And it's like, uh no, like unfortunately that analogy doesn't really work because the uh the real answer is just eat less. That's that's the whole answer. Um but the real answer in programming is like, well, here's these like 40 books that have been written about software design, and and that's the answer. Uh it's it's not one single thing, it's a bunch of things.
SPEAKER_02Yeah, and it, you know, for me as well, is it's it's something that um I you know I think your experience as you kind of mature as a as an engineer as well, is that you again it comes back to principles. You start to see underlying principles like as to why maybe some of these patterns were invented in the first place, and then you you you you might see where uh such a pattern is applicable. Like when I earlier in my career, I read, as I'm sure probably a lot of people do, I read a book on design patterns, can't remember which book it was, but I read a book on design patterns maybe a year or two, maybe two, three years into my career. And for some time I felt like I wasn't being a proper engineer unless I had a design pattern solution for everything. Do you know what I mean? And so I'd I'd be like, I no matter what problem I was I was presented with, I'd look in this book and oh, what pattern should I use here? You know what I mean? And you end up with an overcomplicated mess, and it's just you know you're missing the underlying principles as to why uh these patterns are being described in the first place, you know. Um yeah, it's um I mean there's an example of that, um, like I I play about stuff in you know spare time, what little spare time I have. Um recently um I I was playing about with um the um hexagonal architecture pattern just just for a bit of fun, uh you know, just just kind of playing about with it. Uh what I uh decided to do to kind of so for maybe people who are not familiar with the architecture, it's um it's one of those things as well, when it's described, it feels quite abstract. Um and I I need to make something concrete to understand how it all kind of comes together, right? So the idea uh between uh the kind of hexagonal architecture is um you can almost think of your um application as like um the the the kind of domain logic and the the inner logic of your application should be completely separate to um both the kind of where it's consumed and where where the data ends up going. So in that regard, um your inner logic, if you like, your application logic shouldn't know that it's being used by a website, for example, um, and and maybe it could be used by a command line as well, you know, the same logic could could apply there. Um and when it comes to the kind of outgoing logic, um you shouldn't need to know or care in your inner kind of um application logic that um you know whether you're using Postgres or you know uh MongoDB or whatever, you know. So to kind of learn that concept, I uh I played about with it and I built a little tool that had a front end on the web and could be controlled by CLI at the same time, you know what I mean, just to prove how those things kind of come together. But it's not something that do you really need to do that all the time? Almost certainly not. It's it's overkill for a lot of applications, I think. So understanding the the benefit of what you're getting from these patterns um, I think is like is is kind of key. Does it make sense?
SPEAKER_00Yeah. Yeah. What I think about when you describe hexagonal architecture, which I'm not really familiar with. I've only skimmed a couple of posts about it. Um I can see the merit in that because it it seems to be making use of the ideas of uh loose coupling and modularity and those encapsulation and that kind of stuff. And that makes sense. Um but there has to be a specific enough rationale for the specific applications of modularity and so forth. Um and and if you're uh it if you're doing additional work to create a certain level of modularity without having a specific justification for it, then you're paying a price without getting a benefit and it's premature generalization. Um so that's not a criticism of hexagonal architecture necessarily, um, but it is maybe a reason not to just always use it as a default architecture.
SPEAKER_02Yeah, definitely. And that's exactly the kind of really before that would be the conclusion I would I'd come out with anyway. But I just wanted to this was a spare time project, and you know, I just wanted to play about with it and and and see how it feels in practice. But that's the the key there is and this is what I'm saying, really, is the it's it's the it's that judgment that you exercise at the very beginning where you say, Well, what is the value that I would get from doing this? Do you see what I mean? Um what is the like because there could be a ton of value to to using uh an architecture like that in a given scenario, but it it does take time, I think, uh in a in an engineer's career to be able to start making those judgments, you know, and rather than to just swallow a blog post that says this is a good idea, and then you go ahead and you know you create all these abstractions that never get used or uh weren't necessary, and you end up with paying the price of indirection, and you know, um so it's yeah, I I think um I think that it's what you were saying about principles is is is firstly true that I think there are some fundamental principles that could be dis could be described that maybe apply universally, um, and at the same time then there are certain you know patterns that can help you in your day-to-day job that um you are contextual and uh may maybe the lines are a little bit more blurred. Do you know what I mean? Um sometimes it's just judgment, I think.
SPEAKER_00No, no, no. Uh please don't say that. Um you know, saying something is just judgment, I think, is is is just saying I make these decisions based off of unconscious intuition, and I just have not yet articulated the specific rationale behind it.
SPEAKER_01Yeah.
SPEAKER_00And you know, uh a a lot of experienced programmers, including myself, um are are guilty of saying that kind of thing sometimes. Um and it wasn't until you know, I think if you really sit down and try to articulate these things, you can, um, but it can be surprisingly hard. Um, it's like, why did you do that thing exactly the way you did it? It's like, well, my my experience and intuition just told me to do it. And and that's like true and valid and everything, but it's not very helpful, obviously. Um, because then it's like, oh, well, I guess I'll just go get some experience so I can develop my intuition. See you in a few years. My hope is to fast forward people and say, okay, here is the specific content of my experience and intuition.
SPEAKER_02Yeah. Yeah, I know it makes sense. It's probably not the best way to uh to word it. But um yeah, I mean it's as you say, it's um I don't know, I think I think these are things that come over time, aren't they? You know, when it's um yeah, in in terms of um kind of more universal rules. That's right. I've kind of lost my train of thought a little bit there.
Patterns, Hexagonal Architecture, And Over-Abstraction
SPEAKER_00Um well here here's what um here's a big part of my motivation for wanting to write this book, which I may or may not ever finish. Um, you know, there's this I I I hope to provide people with uh like intellectual toolkit where it's not just like here are these design patterns already handed to you, here are the answers, but how do you evaluate any design pattern that might come your way? Um and and and so start with that and then go into specifics. Like, okay, now we've talked about how to evaluate any particular idea that you might encounter, and then here's some specific ideas, like here's what TDD is, and here are the arguments for it. Um here's what this is a tough one, but here's what object-oriented programming is, and here are the arguments for it. Um and and to lay out as much as possible in objective rather than subjective terms. Because what I really don't like is the idea of well, just you know, if it works for you, do it. Uh, yeah. Whatever works for you.
SPEAKER_02Yeah, I think the word evaluate is a really good word, to be honest. It's it's um exactly having a kind of tool set to be able to be able to evaluate like anything under a given context um makes a lot more sense to me. You know, it's um and that is something that is a difficult skill to learn, especially when you are starting out, I think. You know, it's it's um and having the confidence as well sometimes because it's um I can't remember that I I studied history at university um of all things, and I I can't remember exactly because this is like 25 years ago or something. So I can't remember where I encountered this, but it was um book I was reading one time and it was some kind of philosophical book. And the guy was saying, like, what's what's the sign of um like somebody with real ability? And um in this book he basically said it's somebody who can read uh a very convincing argument in a book, maybe a really convincing argument, but can compose a counter-argument to it at the same time, um, and and can maybe counter that and doesn't isn't susceptible to always believing every good looking argument that they come across. Um and I think having having tools kind of by your side that can help you to make those evaluations is a really strong thing. Yeah.
SPEAKER_00Yeah, that's something that I've thought about too. Um, you know, coming across a really strong persuasive argument for something and being able to come up with specific refutations for it rather than just like well rather than falling for it, or almost as bad, just being like, eh, my gut tells me no on this one without really knowing why.
SPEAKER_02Yeah. I think one example of that for me is it's the word pragmatism or pragm pragmatic. It's um I feel like that word has been hijacked um in a really bad way. Because it's it's um, I remember reading The Pragmatic Programmer years ago. I'd love that book. I think it's a great book. Um what one book that I wish I'd read earlier in my career, actually, The Pragmatic Programmer. I read it, I I don't know, it's only a few years ago. I just I'd had it for ages and I just picked it up for some reason and started reading through it, and it's like almost every page is like a gold mine. It's like so, you know, so many good ideas in that book. Um but the the idea of pragmatism to me, it's pragmatism works kind of both ways. It doesn't mean just cutting corners. And I think in in business, uh one thing that I hear a lot is people on the particularly on the business side who use the term pragmatism to justify cutting corners that are actually going to cost a lot of time and effort and money ultimately to their own business without realizing it. And to me, that's an example of where, you know, um I don't know, I I just find it very frustrating when these kind of words are used. Um the meaning of these words it gets changed, doesn't it? It's a term semantic diffusion. I think I can't remember if we discussed that last time. It rings a bell.
SPEAKER_00Um yeah, and I feel the same way. Um like like there's often advice. I I even have a discomfort with the term of cutting corners, because I want to be very careful to distinguish, and I think you'll totally agree, um, to distinguish between arguments from like professionalism and craftsmanship and stuff like that. Maybe we've even talked about this last time. Arguments from that versus like hard-nosed business arguments. Like, no, there are concrete business reasons uh to refactor this code. It's it's not for craftsmanship, like screw all that. Like, that's not where I'm coming from. Um, I'm I'm on your side of the table, I'm on the business side, and and we're making these investments, these technical investments uh in order to serve the business. And it's often seen precisely the opposite way.
Evaluating Ideas And The Meaning Of Pragmatism
SPEAKER_02Yeah, completely. I mean, this is for me this this is one of the kind of my own kind of eureka moments in my career, if you like, because I used to I used to struggle to communicate this one to the business because I cared passionately about the quality, the underlying quality, but it was very difficult, or I found it difficult for some time to get the business kind of on side with that. But I almost took a step back um some some time ago and stuff, you know, to kind of in the same way you've been talking about stripping away the underlying principles, like why do I really care about this? What you know, why is it that I actually care so much? And to me, it ultimately comes down to the fact that I I believe that the a quality, the proof that you have a quality foundation is that you can keep making changes successfully over time for the business, and you can keep delivering over time. And what I started to do as I've been contracting, I've been obviously moving around a lot more as a contractor. Um, and I one of the first things that I try to do is to strike up a good relationship with the business, right? And and I I I always want to work on products that I actually care about and I feel invested in the product and the success of the product, um, not just the technical success, but I I want it, I want the product to be a success in the marketplace as well. So I feel like I have to be involved in um you you know, uh understanding the motivation uh behind features that the business is asking for and working in a really collaborative way with the business over that side of things. But part of my job and part of my responsibility is communicating back to the business the technical cost of certain decisions, right? And um getting across quite quickly that you know having a really solid quality foundation is what is going to make it possible for us to test out these different ideas that you you have, right? And because we can keep making changes, we can try things out. Um, I'm currently, I say currently because I'm off for Christmas right now as we're recording, but um, I I've been working on so I I've been contracting in in one place for um a few years now, which is quite rare for me, but it's just kind of worked out quite well. And so I've stayed in one place for a couple of years. Um when I first started there, I was lucky enough to work on this greenfield uh project. And it was um, I also, for full disclosure, worked with some extremely talented uh engineers on that. It was so much fun um, you know, working with really solid people from the very beginning and just hitting the ground running. Like it was it was just instant connection with these people and it worked really well. And we we built um this system that um again was test-driven from the ground up, but really kind of you know, we did the whole walking skeleton at the beginning. So we were uh doing pipelines that could go straight to prod from pretty much day one. Um, we had the really strong test in, a really strong relationship with the business, all good. Worked on this project product for about a year, um, and it was successful and it's all well and good. Then I moved on to other things within that same business and came back now, um, maybe 18 months or so after touching that project for the last time. They've been asking us to build new functionality in there, and they were scoping out for like the next six, seven months. But, you know, and I don't just want to kind of sound like I'm just beating my own chest here, but because it was really well put together and well written, we managed to do all of that in in a fraction of the time that they were expecting. Because the changes, because of the way that um both the code internally is kind of structured and the way that it's tested um specifically as well, meant that the same um threats and same problems that we see in that same company with different projects were not as significant in here. And so suddenly we're having these conversations, a new business, um, new product owner uh working on this with me. So um the I'm working on a project that I worked on from the very beginning, but this product owner is kind of new to this product, right? And as I'm working with her, and as we as a team are working with her, we're just finding that actually all these kind of things that we thought were going to be problems, because I hadn't worked on it for 18 months, I had to get my head back into it again, were not problems. And and it's like, okay, um, so again, I won't go into too much detail of the product itself, but just to explain for the purposes of um just kind of giving a demonstration an example, the entry point that we were talking about having a completely new entry point to this application. It's a fintech product, so I won't go into too much detail about it, but a completely new entry point where a user can come in in a kind of midway point in the journey for various reasons, which if you want me to go into I can, but it's maybe not that interesting. But the point is that um they come in from a totally different angle into the journey, and it's kind of like the the journey's kind of half complete, let's put it that way. Um so they bypass a chunk of the original journey. But because of the way our tests were written originally, we can very easily write tests that simulate exactly that journey, and we can see end to end um exactly how that's going to work. We can we can do it even through the browser. So we get um so like server-side session logic is all properly um tested as well, going through that full path. Um, and it ends up just being something that originally, as I say, we were scoping for months into the next year. We basically finished it before we broke up for Christmas and it's it's ready. Um where we're actually waiting for API teams now to catch up with what we've done. Um, but again, it's all of that that kind of run, if you like, there is because the it it's communicating this idea to the business that because because they're all loving it, right? And they that you know, why has it been so easy? Why oh we need to take away these learnings, blah, blah, blah. But it's like, well, because we built it properly. To begin with, and we didn't compromise. And when we had these conversations, I will say um that the original project product owner, um, if I say her name, I mean I'm only going to say positive things about her. So Darshner, I'll say I'll say her name. Um, but you know, uh loved working with with her, and um, she's still in the company, but not working on that particular um product anymore. But when I and the team that I was working with first worked with Darshner, um she just seemed to understand there was this mutual respect right from the very beginning. And she would listen to us when we when we explained why these we were doing things a certain way and why it mattered. And she always gave us time. If we ever said, okay, we need to do uh refactoring of this, here's why, here's the implications if we don't do it. She always gave us um the ability to do that, and it paid off massively. Interestingly, about a year down the line, we were having a curry in uh London together, and we'd all had a like a drink or whatever, and she she let slip that she used to be an engineer. And I was like, ah, that explains quite a few things, but but still, um just to be clear, um, you know, I always aim to strike up those relationships with people regardless of the the background. Do you know what I mean? It's it's um it and I I think it it's incredibly powerful when you've got the business on your side in that way. Um, and you really can live the dream as well. And it's it's very frustrating when you um you then come across people who, especially very loud people online, will say, Oh no, you don't, you they'll they'll they'll they characterize it the wrong way, right? So they'll say, Oh, you don't need absolutely perfect everything. It doesn't all need to be beautifully designed, and you know, these these engineers you know just want everything to be beautiful and the code has to be immaculate, um, and they forget that we've got a product to deliver. And it's like, no, that's not it at all. It's um we're doing this. What I'm talking about is pragmatism, right? But pragmatism works both ways. Um, the business, if you just cut corners and you you know as an engineer that by cutting these corners you're actually gonna cost the business time and money. For me, you're not you're not you're not really doing your job properly unless you communicate that back. Do you see what I mean? That's how I feel.
Quality As Sustained Change And Business Speed
SPEAKER_00Yeah, yeah. Um, and that frustrates me so much where people are like, it doesn't have to be perfect. Um, because the choice isn't usually between like perfect and merely good. I've said this before. It's it's usually a choice between acceptable and abysmal. Um it's it's not a choice between A-level work and A minus. It's more like a choice between F and D plus or something like that. And it's like, no, I'm not arguing that we do everything perfectly. I'm I'm arguing that we just don't do a that we at least don't do a really stupid job. Because I I think, you know, uh I I I think you said something about uh we built the system properly, something like that. Um I I prefer to, especially when communicating with business type people, to say something more like we built a system wisely, you know, we made good investments that pay back in the future. Because again, it's it's so easy to make a confusion between like um doing things out of like craftsmanship and professional pride and stuff like that, um, and doing things for specific business justifications. Um I I want to comment that like basically that whole five-minute chunk of stuff you said just now, like that definitely needs to go in the book. Um to me, not just to me, I I think it's objectively true that everything is connected to everything else. Um like all programming, basically, all programming is done in service of a business objective. Um and and so you can't really talk about programming without involving the business concerns because there's no reason to do the programming other than in service of the business. And and the other part that's really significant that I think can't be left out is r relationships. Um, because programming is done by people working together and and uh you know if if you have a good relationship with the people you work with versus a bad relationship makes all the difference and no amount of technical competency is gonna make up for a poor relationship.
SPEAKER_02Yeah, 100%. It it's something that um I over the course of my career, I I put a lot of effort into that side of things. So like early on in my career, I really was that stereotypical just want to stick my headphones on, um, you know, just give me tickets. I I I was that person uh early in my career, but I I started seeing how I wasn't as effective as I wanted to be, and I wasn't as satisfied as I wanted to be. And I would I'd read up more as well and speak to people. And you know, I I I ended up working with some very talented people, um, luckily again, quite early on in my career, who were really good at that side of things, and seeing how well they could communicate with the business and seeing how much of a difference that made, it made me kind of put a lot more effort into that side of things. And I I find it so much more satisfying now to you know, I I I very much see it as like I'm part of a team, right? And I want the team to do well. Now that sounds like an obvious thing, right? Just sounds like something you say in an interview, you know, blah, blah, blah, you know, teamwork, whatever. But to me, it's um it it's really fundamental to the extent that I look at it now, and I haven't fully kind of answered this one myself, but I was thinking this recently, and I think I put this on a LinkedIn post a few weeks back or something. And it's an interesting question to you, I guess, as well. Is um if as an engineer, if you work on a product and it's a technical, technically brilliant and it's a success on a technical level, but it makes no impact in the marketplace. As engineers, have we done a good job? And it's an it's an interesting one because I I I think that it's not fair to have a complete my perspective on this is I don't think it's fair on us to have a complete black and white answer because you can't always dictate the market, and you you you could have built an absolutely brilliant user experience product, but for whatever reason, just didn't hit at the right point in time. But I like to think that what we do the way I look at it now, it's I've heard this term products engineer being thrown around, and I I don't know how new that is because I mentioned it recently, and somebody was saying that's not not a new thing at all, and it isn't really, but but I do see myself in that kind of light, you know, it it's um uh some of the most productive days that I've had as an engineer had had me write no code at all. It was just it was I know engineers typically don't like so many meetings, it's quite a common you know thing, but like the right meetings with the right people at the right time can make a huge difference. And again, just just just one thing to mention on on this recent project that we've been working on. We actually didn't write any code for like the first few weeks of this project. Because what happened, this new um, as I say, products owner came in, and she managed to get people from because we we've got people from domain API teams in there, we all kind of came in together in let's say one room, but one kind of virtual room because it's mostly remote. Um and we had lots of kind of discussions amongst ourselves that just those discussions, because I'm talking with directly with the core domain API uh uh team that I'm gonna be we were able to just rule out so much effort and so much work to realize oh, that's not possible because of you know such and such a the way this their API works down further downstream that we didn't know about. Um or do you do you know what I mean? And having these kind of conversations um sometimes can make the absolute world of difference. Um and it's yeah, I I my own perspective on that question, uh I would be interested to hear what you think about that, um, like whether you consider it a success. I I think you have to be fair, uh, you know, because um, you know, we can't dictate the market conditions too much, but I do like to think that my job is not just to write code, it's to try to help make the most successful product, right? And for the business, um, and whether success means making more money for the business or if it's an internal tool just being more useful for the users. I I like to be involved with the like close relationships with the UX team as well. And I love working with a really good UX team. Um again, I've been very lucky to to work with some amazing UX people who you know fundamentally speak to users and and uh know how users kind of um consume the products and and their opinions are not based on just finger in the air, kind of, you know, what I think. It's it's um they've got real data behind many of these uh decisions, but yeah, it's um it's definitely a full team effort, isn't it? And the the technical stuff which is so important to me is all there to enable all of the other stuff. Do you know what I mean? And when you when you have those connections uh and you're firing on all cylinders, it can be an amazing that to me. That's the agile dream, right? That's how it's supposed to work. Um is is you know, you work in these kind of small increments, you have this kind of technical foundation that makes change uh dramatically reduces the fear of change. Um and by doing that, you can work closely with the business and experiment with stuff, you know. So a good example, I guess, would be to say um would be something like, you know, say if you're working on a product that um isn't actually the right market fit, right? And maybe it's not too far off with a few tweaks, it could be. If you do the whole, you know, the way software development maybe worked many years ago, the waterfall kind of approach, you you could put all this kind of effort into designing the perfect thing, whatever, and do a big design up front, uh big, big uh release, you know, of all these features in one go, and then you find out right at the end that this thing doesn't work, right? But if you've got the foundation in place to um to be able to keep making changes with the with high confidence, you can experiment, you can release one feature and get some feedback from users. Oh, actually, they they're not it hasn't hit with users the way that we we thought it would. But maybe if we change this feature to work a slightly different way, or even better, you know, we've had feedback from these users who are consuming this product, and they've said if we change this feature to work this way instead of that way, um this would be better for them. And so you you you course correct, yeah, and ultimately hopefully help the business create a better product. Do you see? That's that's kind of how I see it.
Relationships, UX, And The Real Agile Loop
SPEAKER_00Yeah, that is such a deep question, deep and broad. There's so much to it. Um, because there's so many factors involved. Um, you know, for one, it's like, what do you want out of your career and why? Um, like for me personally, I'm not ashamed to say that my like north star for my career is just compensation. Like I I want the maximum compensation possible because I figure if I'm gonna work eight hours a day, might as well get paid the most that I can because why would I want anything else? That's my way of looking at it. And and for me personally, I figure that the way that I can maximize my compensation is by being the most valuable to the business. Um there's this quote I've repeated so many times in this on this podcast by Benjamin Franklin. Um, if rascals knew the advantages of virtue, they would become honest men out of rascality. Um so it's like, how can I satisfy my greedy, selfish desires? Well, by being like a really good employee. Um, so that's that's the path that I'm taking toward that. Um, but my conception of a really good employee might not be the same for every employee business combo, because there's not really s such a thing exactly as a good employee or bad employee. Um I mean there is, but like the the the value is in a connection uh between an employee and an employer. It it's only when you combine those two things that any value is created. Neither thing has value on its own. Yep. Anyway, it depends on how you look at that. Um and it depends on how much like influence you as a developer have inside your organization. Um personally, uh at the time of this recording, I work at a really big company. I have a certain size influence, and that's that. There's a lot of inertia, as there is in all big companies, and I'm I'm not gonna change anything more than than what I'm gonna be able to influence. Um and and so what does it mean for me to do a good job? That's a different answer, I think, than if I worked in a really small startup. Um and so uh for me, I I have kind of an outlet because I have uh generally at most of my jobs such little influence and control. Um I have my own side business that I'm working on, this continuous integration product I've been building for the last few years, um, where I can just be completely full stack all the way from the business to the graphic design, UI design, down to the servers and stuff like that, just absolutely everything I control. And that way it's totally meritocratic. You know, like if it fails, that's 100% on me. If it succeeds, that's 100% on me. In a in an employee situation, what I do is so much mixed in with things that I don't control that it's hard to even say what constitutes a good job and success and failure and all that stuff.
SPEAKER_02Yeah, yeah, it's um that that yeah, it's always gonna vary from like one organization, isn't it, to another. I mean, I I'm quite lucky in the sense that where I am now, um I mean I I would say that the the teams that I'm working on now are very healthy teams, right? And and people work together in quite a collaborative way. And I I would say I think I do have quite a high level of influence in in that domain. It's quite a big company. Um, so my side of it, um, you know, I I'm on one kind of side of the company. Um, side is probably the wrong word because it by splitting in two, but one kind of uh area, let's say, and I think I have a quite a good sphere sphere of influence um on that side. But having said that, um, I think that it's this particular organization, it's it's it's quite well put together by people who um when they're interviewing, I think they care about the the soft skills quite quite a lot as well. And um, you know, they they tend to the people who come in tend to be people who can be reasoned with, um, if if that makes sense. And so, you know, I uh in in terms of like sphere of influence, I think that I I have quite a good sphere of influence it in only now, but having said that, when you move from one organization to another, you've always got to kind of re-establish that. Um you know, you you're also dealing with um you know politics as well. Let's not, you know, that that's that's a thing, you know. As a as a contractor, I go into places and you know I can be dismissed very quickly if people want to. I don't know how it works in uh America and other countries, but certainly in the U the UK, it's um seems like a flexible kind of workplace kind of thing. So I go in, my compensation is is typically higher than most employees, but the downside to that is that I take on more risk. Um and if things don't work out, then they can just say goodbye and usually you have like a two-week period, and that's it. You you you're gone. Um but one thing that I really like about that is that because I am a contract center, I can't get promoted internally, right? That's not a thing for me. You can get uh a renewal on your contract, maybe you negotiate a slightly higher rate the next time around, whatever. But you can't get promoted. Um, there's no such thing. Unfortunately, because of the way so many organizations is kind of structured, and again, I'm coming at it from a UK perspective, but I'm pretty sure it's probably very similar in the US. Um, you know, people want promotions, they have to be seen to be doing certain things as well. Um, so the the one thing that always annoys me is this term, oh, what's the term uh is it uh oh impact, show impact. That thing annoys me a little bit because when when I come into a team, so like there's been a nobody would argue that I've not shown impact in the organization I'm at now. I think nobody would argue that, right? I don't mean to just blow my own trumpet, but I think it's that would be the case. But I never went into a a situation that I thought, how can I kind of, you know, how can I show impact here? I would just go in and see a problem, right? So one example was, you know, I remember we talked about cucumber last time. And uh when I joined one of the projects in here, it was very cucumber heavy, and the tests were not trusted and were a pain in the back side to work with and so on. So I kind of um, you know, really heavily kind of pushed for moving away from Cucumber and came up with the plans how to do that, communicated the value, and eventually got stuck into the work and we all we we moved away and we're now using um playwright and it's it's it's far better, you know. Um, but I never went into that from a political point of view. Do you know what I mean? I've got to show some kind of impact here. And the problem is, so I've been asked uh in the past, would I get would I um go perm in this place? And one of the feedbacks that I gave was actually this. Um I'm like, well, what if what if I join a team and the team are firing on all cylinders and everything's going really well? I don't want to be in a position where in order to get the next bonus or whatever, I've got to somehow do some kind of big, you know, be able to point at some kind of big explosions in the sky. Do you know what I mean? Oh, I did this great big thing. Because maybe the best impact I can have for that team is to just just swat in and keep the wheels turning. But at the same time, maybe there's big problems there, and I can go in and identify those problems and and help. So yeah, I think sometimes the you're dealing with uh the motivations of people because of the way uh organizations are structured, they're not always and it's not necessarily the employees' fault. That that if you're told as an employee you need to show impact, um, so you need to show how you can have an influence on other teams. Well, what if you didn't need to do that? Do you know what I mean? And then so suddenly you're playing this this weird game where you have to do this thing because it's in your interest to, but I don't know. That that kind of thing frustrates me no way.
Work Theater, Impact, And Organizational Incentives
SPEAKER_00Oh man. Yeah, that opens up two cans of worms, which uh unfortunately I don't think we have time to get into. Um, but just to mention what that brings to mind for me is I I I think a lot about the push and pull between doing real work and carrying out work theater. Um and and we live in, you know, I I I I have a healthy respect for the fact that we live in reality. We we live in the is world, not the should be world. And no amount of wishing that reality was different will make it be different. And so carrying out this work theater is just something that has to be done. And that's that's a whole thing. And then the other thing I I want to comment perhaps controversially that I think the better a team is the more room they have for improvement or I should say capacity. The more capacity they have for improvement because the people are probably smarter and smarter people are more fertile ground than no offense, dumber people. And and it's kind of paradoxical because you would think that like you can get like a hundred percent good and no better but I think it's more like a multiplicative type thing where um the the better you are the better you can be it's it's more like the rich get richer kind of a thing. But again that's that's a whole topic and and we do have to wrap up soon but um I I want to give you a chance to it sounds like you had a response to that.
Continuous Improvement And The Scenarist Tool
SPEAKER_02And then anything you wanted to share uh in in terms of links or anything like that before we wrap up yeah um yeah in terms of response to that I mean I I was just going to say yeah again the the the that's been my experience the teams that like I'm working with now for example um there's a there's a constant the culture of constant improvement right so and it can often it's just small things now because we've always had that approach and and when you always have that approach and you always try to kind of you know keep the standards high keep improving over time you tend to not end up with these big things that you need to do anymore. Do you know what I mean? Like like to improve things. But there is a constant culture of like there's there's one area of the system that um to this day uh causes some friction. And I'm talking about a different product here not the one I was talking about before but um one of the products and it it it it's a bit of a scarier place to go to because the tests aren't perfect in that area and so on. But we've got a we as a team we've all come together and we figured out how we're going to incrementally improve that over time. And again a lot of that is getting good tests around it and so on. But yeah um I I clearly could go on for longer but um yeah in terms of um links I mean there there is one thing that um one tool that I've been working on um I mentioned to you previously um it's uh scenarist is the name of it so if you go to um scenarist.io um that is a a a framework or a kind of tool that I've been building for so actually what I was talking about um previously uh in the projects that I've been working on where we're able to kind of um simulate entire journeys through through the web through the browser um mocking out any downstream service how however we want we came up with a kind of system for that um and I kind of looked at this and I was I I just thought I'm sure I could open source this I could do a version of this that's open source and that's exactly what that is that's what scenaris is. Now for now um at the time we're talking here I put it later maybe a month ago um it's it's open source you can go to GitHub you can see it um and as I say scenaris.io is the library um what I haven't done yet is produced any um material that sells the idea and shows how it can how it works and so on. I mean I have got docs there the docs are really comprehensive um but what I'm planning to do over the next few weeks is to record some hopefully fairly short videos that just show um the value of that tool and how it works. But it's quite an exciting area and also I think dramatically helps testing tools like NextJS which I'm no fan of Next.js I have to say but um it it helps you know that's the area I've been in and it's massively helped us we can even test um server uh server side comp server React server components uh we can test them this way and the react the Nextjs docs don't even have a way of doing that it just basically tells you to kind of wing it they they don't really tell you how to do it.
SPEAKER_00Um so yeah that's um but it's all open source and not that yeah it needs to get better at the profit side um well we'll put all that stuff in the show notes um and I really appreciate you coming back for another episode I hope we can do a whole bunch more episodes in the future and thanks so much for coming on the show.
SPEAKER_02Yeah no worries thanks a lot thanks for having me