Creativity in Code

Speaker 0: Awesome. Well, super excited, to be diving into this. I think it's gonna be a really exciting conversation. Obviously, this is I've built my entire life around, like, the idea that we're talking about. I think we all kinda have, so it'll be hopefully some some interesting stuff to cover.

Why don't we kick it off with some intros so everybody kinda knows who's who's chatting, and then we can get into the theme. Stu, do you want to kick it off with with an intro?

Speaker 1: Yeah. Sure. Let's see. What's a good, succinct way to put this? I have both a graphic design background and a coding background, so design and engineering together, which is awesome.

So I speak both both vocabularies. It didn't use to be awesome, I feel like, then when we were young. It made us kind of an outcast in both worlds. Maybe I'm speaking too much for myself. So I've worked at Google and Amazon and various other places, and I'm currently at Unity Technologies.

Speaker 0: For the for the second time around. Right?

Speaker 1: For the second time around. Yeah. I was pretty torn about leaving the first time around. I left to pursue something pretty interesting, and very happy to be back in the family with a lot of folks that I really enjoy solving tough problems with. And I should probably mention that spans like creative technologist stuff, augmented reality, virtual reality, a little bit of quantum computing thrown in there.

But, yeah, it bounced around between product design, marketing, research work. It's all fun.

Speaker 0: Definitely. Yeah. I've probably known for 20 20 years, over 20 years maybe. Going all the way back to the beginning, you know, talking about, like, getting trained, whatever, learning, you know, design and development. You definitely kinda get this sense of, like, not jack of old trades master, jack of 2, master of, like, hopefully both, like, freedom and technology.

They're just no different. But, yeah, all the way back in the the Yukon days. David, how about how about you? Maybe back from where you are now.

Speaker 2: Yeah. Great to be here. Thanks for having me. So I'm a head of engineering at a digital product agency, here in the UK called Pixielabs. We're London based.

We design and build digital products, mostly web based or mobile based. We've been going for 10 years now. We had our 10 year party actually a couple of months ago, which was a lot of fun. And I've been with PixieLab since its inception, helping to initially writing all the code and increasingly my team not letting me write the code. And prior to that, I was, helping to kinda lead developments, at an innovation lab at News UK, or at the time it was News International, which is the publisher of The Times of London and The Sun, a big newspaper publisher here.

And prior to that, my my background is very, traditional. I did computer science. I was I was a very traditional nerd and always have been, always will be. But, yeah, worked on a whole bunch of stuff under under the kind of pixielabs umbrella, everything from large companies, you know, people like Twitter and HomeServe, but also start ups and and smaller brands and everything, yeah, from, like, big platforms for Fitzy 100 down to cat food subscription websites. And we once made a thinking about, sort of like things that are the most creative, we once made a typewriter type by itself when you tweeted at it, for an art installation with in partnership with Twitter, which I get so much mileage out of in conversation forevermore.

Like, that's like the one. It's like the one project where you're like, I can talk about this a lot forever.

Speaker 0: Was that at a museum perchance? Like, was that a museum over on your

Speaker 2: side? Yeah. It was like it was initially a there was like an art exhibition. They ran Twitter ran like a competition for ideas that were powered by tweets in some way, like any idea. Right?

And people submitted everything from, like, pigeons flying around measuring and tweeting the air quality, all the way to the typewriter that was, like, typing out a a novel by through Twitter. And we had to, like, come up with some representation of all of these ideas that people had submitted or, like, 6 of the winning ideas. And then I think the typewriter ended up at the Globe Theatre as well, where it was typing the complete works of Shakespeare, but it would wait for the someone to someone in the world to tweet the next word that it wanted to type. It took months and I think really annoyed all of the staff like, in the corner, like, clacking away. This was a really loud old school typewriter.

Speaker 0: Yeah. So just randomly for someone to, like, say the word betwixt, and then it could keep on Yeah.

Speaker 2: Exactly. Exactly. And, you know, like it wasn't the I will admit it did have a time limit before it would just type the word and move on. Otherwise, I don't think it would have ever finished. I mean, you can

Speaker 0: just sit there and, like, be the one to keep it moving along. But Right.

Speaker 2: And that's the thing. You would stand in front of it. Right? And you could tweet the next word, and it would, like, tweet back at you saying that you'd you'd powered it. It

Speaker 1: was wild. The idea of an impatient typewriter.

Speaker 2: Yeah. It was. It was impatient. Yeah.

Speaker 0: You should just start tweeting out, like, prompts. Like, okay. Listen. We gotta get this thing rolling.

Speaker 2: Yeah. Please someone tweet this word.

Speaker 0: Yeah. Yeah. I did. So at my agency, which is called Ranger, we did something similar. It was with Google, and Teller, I believe, was, like, the creative side, that was pushing it.

It was a museum, and they had oh, I don't even remember the one of those things you look through, the, periscopes, telescopes. Mhmm. But it was, like, all digital, and they had all sorts of, like, art museum installation stuff that was, connected to like, real world stuff that was connected to technology. So similar to what we're talking about today, you know, bridging the gap between the real world and digital, I think we're kinda getting more into the the creative and code or design and development depending on which alliteration you choose. I love it.

Well, thank you both for for being here. This is, super exciting. So and then just kinda tap it off. So my I'm Ben Haines. I started, an agency maybe 15, 20 years ago, called Ranger out of Brooklyn, which is where Stu is right now, I think.

So David's in the UK. Stu, you're in in Brooklyn. So I started in Brooklyn, really, with exactly what we're talking about. Like, I had seen a lot of development firms, and I had seen a lot of design agencies, and they were trying to communicate. And you just get a lot of the, the design hands off.

It's like pixel perfect, you know, mock, or here's what we're here's what we're looking for. And, you know, the the development's like, oh, we built it. Here you go. But it's not really following the the design principles. They're not giving feedback on what's possible.

Like, designers are really great at making things that look great, but not functional. So I tried to bridge the gap hiring designers and developers to build for, you know, Google, Snapchat, AT and T, Prada, US government, etcetera. But that's where this software Directus kinda stemmed from was, wow. Okay. So we're building these really innovative projects for those sort of companies, and, you know, smaller companies, culture institutions, etcetera.

But we're building the same thing over and over and over again. How do you take maybe one of the more I mean, quantum computing, Stu, so you you got me there. But, like, the database is pretty technical. How do you make the database, you know, in the work of a a DBA, a database administrator, you know, how can you democratize that so the business user can do it and you you do it through design? You know, really strong intuitive UX and UI, giving you know, I I was inspired by PHP MyAdmin, which I think is maybe lacking design.

I you know, Not not the best not the best system I've ever used. So I was like, oh, just take that and make it friendly and intuitive and safe. So that's where Directus, you know, our our software sort of stemmed from. But so today, we're we're kinda really covering the basis of, where all 3 of us live, which is are we gonna say design and development or creativity and code? I like I like both, I guess.

Speaker 1: I think I'm leaning towards creativity and code. Okay.

Speaker 0: Yeah. I would say design development, but creativity and code, I like it's not just design, I guess. So, yeah, that is probably better. So the intersection of those two things or the overlap even, I think we've all sort of built the whatever we've been doing for the last 10, 20 years has been has been right there. So, without further ado, why don't we jump in?

So I guess to start off, Stew, you mentioned sort of, your history going through different large orgs, you know, AWS, Google, Yahoo, relatively structured companies or very large companies. I'm curious when we're talking about creativity and code going at the c's, how do you, like, encourage a culture of innovation at a company that's a little bit more rigid or, a little bit more red tape?

Speaker 1: Wow. I guess, the answer varies quite a bit depending on which context. So for instance, Google is a huge company. Right? And there's a lot of rigid structure in place necessarily.

But what was really cool about Creative Lab and also, the data arts team is they were little corners of the company that, folks like Andy Barrett, who runs Creative Lab, he had won the confidence of his fellow executives to, say, we're gonna go off and do something crazy over here. Here's why it's justified. Here are the business reasons and marketing reasons and whatever, but we're going to go be a little nuts and you're going to sit back and chill. And so I'm so glad that like in that context, there's a very strong leader standing between you and a lot of that process, and it allowed Creative Lab to be a little crazy. And I I haven't been there in, quite some time.

I feel like there's a little bit of a trajectory where it started to become a little more formalized, probably also necessarily. But I also remember the more Wild West days, literally, with a sword and champagne bottles and stuff, just impromptu on like a Tuesday evening because everyone's working late and major projects are due. So there are a lot of good it was a place where there could be some irreverence and the space and time for some creativity. Of course, things have to get done and they have to get shipped and delivered, so it wasn't without pressure for sure. Whereas I would say Amazon was a very different case and ultimately, I don't think AWS is just so not geared towards a creative process.

So I think I lost the battle a bit there within AWS, which is sad. Yes. There's some great people there. But,

Speaker 0: I can imagine, like, just in the in the 2 you just described, you know, one has creative in the in the title, you know, in the team name and servicing. So, like, they kinda have maybe different focuses, maybe. But

Speaker 1: Yeah. For sure.

Speaker 0: Yeah. And that's that's pretty amazing. And I I feel also feel like, you know, the more emergent like, the newer the idea is for a team or for a company, regardless of how big it is, it's easier to be in that, like, divergent mindset and just be like, oh, we're gonna break things. We're gonna innovate. You know, that's one of the same.

We're gonna be, like, super creative and just kind of push the envelope. And then over time, it's like, oh, we have real world things. We have to answer the investors, or we have to kind of rein it in a little bit and switch to convergent mode. Both of those are pretty established companies, but creative I don't remember when Creative Lab was formed, you versus

Speaker 1: I don't know. I wanna say maybe there were seeds of it in 2006 or something, which is well before I joined. That would have been I

Speaker 0: mean, it held on to that idea.

Speaker 1: Very fuzzy about the yeah.

Speaker 0: Yeah. I mean, held on to the the ethos of, like, create I mean, yeah, that's the purpose of the team. Interesting. And would you say the same thing for I think we we were talking recently. I think maybe there was some overlap at Yahoo between when you were there and when I was there, maybe not.

But would you say the same thing for for Yahoo? Exclamation.

Speaker 1: Well, I think, I, speaking of returning to places, so I had been at Lab, went to Yahoo for a few years, then went back to Creative Lab and Dana Hartstein, which is a whole other story. So I think I entered Yahoo with a different mindset. The context was that Marissa Meyer had left Google, and she had taken over as CEO, and it was still the early days of that, so there was a lot of this optimism that Yahoo had built this giant, I'm gonna use metaphors here, had built this giant ship, and it was a brilliant ship. It was a big battleship out on the sea, but over time, its facilities have been squandered and things were not going so well. So Marissa climbs aboard and says, I'm the captain now, and you could go do a startup or you could go do something else and you'd have to build your entire ship, and that is a difficult lift.

Or you could jump on this ghost ship and take all the good parts and rebuild them, and that seemed to be the mentality. We're all here. It's a new era. We already have all of these products and services and things that generate revenue and just let's use it. Let's build anew, from this kit of parts.

And, so it was a pretty exciting time. And there, maybe I'm speaking too much for myself, but it felt like there's a bit of this sort of pirate mentality of like, here we are. Let's blow things up and let's reinvent. And because of that, I started out in marketing, had some success there. My biggest success there already incorporated cutting edge research, early days of machine learning, Marketing, obviously, design is what I was bringing to the table.

So it was all like engineering, marketing, and design altogether. And because of that, I was in marketing, then I was in product, and then I was in research. So I literally, like, bounced around the company kind of doing similar stuff at every turn but with a different hierarchy and sort of a different set of rules being bent in in a new direction.

Speaker 0: I like that. I like that. So anybody on my team knows I'm a big fan of metaphors. And I I thought for sure, when you talk about breaking the ship apart, you're gonna go down the, like, the Theseus, paradox. Oh, right.

Yeah. And I was like, oh, no. We're going pirates. We're doing pirates. I like it.

That's that's amazing. Yeah. I think that that kinda makes I I I have always sort of worked at, my like, an agency, like self self employed with the exception of maybe a a year, year and a half at we were both, AOL, Verizon, Yahoo, which may or may not have had overlap with you. But, yeah, it was for me, they there was, like, creative freedom, but it was definitely, like, you can be creative until like, toward the end of the process, and then it's like, I hope you had fun because we're gonna shut that down, and we're gonna work on something, you know, something else that maybe is a little bit less fun. And which is almost more stressful because you get to work like, you get to take a project to 90%, and then they kinda scrap it.

I just wasn't used to that way of working. It's like, oh, well, I guess that's that's how it's gonna be. So I I wanted a little bit more control and kinda stepped away. I was like, alright. I just need to be able to sail my own pirate ship, because even pirates, sometimes they're they're not hiring the way you wanna pirate.

Speaker 1: Yeah. If you if you wanna lament some of those, Yahoo things, I got it to a 100%. We had a a very successful marketing campaign that resulted in a patent, which is weird for marketing, and some other interesting developments. And I thought, wow. Okay.

Based on the back of this, now it's time to start my own team. And, with the right group of folks, we could bang out a few of these every quarter, and wouldn't that be a good thing? And, it was tentatively called the Marketing Innovation Group, and I was so excited to take this remit that I thought I had earned and like run full speed with it, and that turned out not to be the case. For some reason, it was like, well, that was successful, but the analysis was for none of the reasons you listed. And after that, they never had a project like that again.

It was like, all right. So I moved to product for a while with some other very crazy folks.

Speaker 0: Yeah. You get to meet different meet different teams. I was I was moving toward, like, the VR teams. We probably would have intersected at a certain point.

Speaker 1: Oh, goodness. That would have been a lot of fun.

Speaker 0: Yeah. Oh, yeah. Absolutely. But then I was where I was like, how far can I get down this road before whatever cool thing, you know, we dream up gets scrapped? So I I kinda stepped stepped away, but, I'm sorry.

Well, so and, David, obviously so I shared some time, you know, with with the big companies like like Stu. You've been over a decade at your agency at Pixie Labs. I ran mine for a similar amount of time, and what I found or just in general, you know, agencies really have to stay at the bleeding edge of, you know, what's going on in terms of the tech stack, in terms of just everything from the the small, like, what's going on within the front end, you know, CSS and frameworks all the way up through larger trends, and things that you can pull into your process. Because you're not always like, the spec that you're giving from a given from a a customer or a client or whatever it is isn't. It's like the the goal, but how you get there and how you really push it is on the agency.

And I'm curious. How are you making sure that your team stays on top of, you know, the creative and tech, staying ahead of the game and just leading, you know, leading that side of things. Yeah. Any any

Speaker 2: specific I mean, like, as an agency, right, you're optimizing for being billable and kinda remaining ahead of the curve and doing experimentation and things like that can really kinda run counsel to that. It's funny, like, you actually mentioned, Stu, about sort of, like, you know, having a corner of the company that had won the the confidence of execs and and things like that. Like, you almost kinda have to do a similar thing with time, right, and enshrine a a a portion of time where you, you know, for us at Pixielabs, it's like a day a month where we've sort of set aside as non client time, which is not a lot of time to really get a lot done. And, naturally, I'd much rather it would it was a bit more. But, like, having some time that is a little bit enshrined that you're like, this is the day when everyone feels okay with putting down the client work that they're on, you know, and which can be tough with deadlines and things like that and and try and, you know, use that time for a bit of experimentation.

But, also, I think, like, there are some areas you can be flexible in an agency on projects. So I kinda try and look for opportunities project by project. Right? And sometimes it can be a bit of an exercise of bargaining with a client as well. So if you've got something where the budget's a little bit low, or maybe it's a for good thing and you're being asked to kind of, like, help, you know, help out something that is more charitable or something like that, maybe maybe that client might be a bit more receptive to you actually doing a bit of experiment you know, experimenting on that project.

Right? Trying something that's a bit unfamiliar and just being open with that and saying like, hey. Maybe we're gonna try something a bit new here or work with something that's a bit more unfamiliar to us or, like, we have this idea that we don't know if it's gonna work, but we wanna try it and, you know, depending on the parameters of the project. I think that that there's an opportunity then. Also having, like, good relationships with clients, especially long standing relationships can help with that, especially if you're you know, one of the things that you do in an agency is, like, how can we get more out of a client?

Right? Like, how could an existing client, how can we unlock more more spend, more investment in us? And having some ideas, having some things that are experiments, and I'm kinda trying to sell that as an as a kind of joint experiment. Right? And being like, well, let's experiment with this thing together that we see there's a potential for your business, and, like, we can help that make that happen, I think is also is also a way to do it.

And I think thinking about the engineering team as well, just in general, like, you do have to make sure that the experiments kinda in some way, I think, align with, like, our goals and vision. Right? Like, if we're, like, we're primarily doing stuff sort of web and mobile. And so, you know, I don't know if I would be comfortable with it with one of my team, like, going wild and doing some experimentation with something hardware based or electronics based or or something like that. Like like, maybe, but I think that that feels a little bit too off piste, and a little bit of a challenge to justify.

And instead, it's like, okay. Like, if there's something that's slightly out of our lane, but not massively out of our lane necessarily, unless that was something that we were like, as a business, we also wanted to move into. Right? There are definitely things, you know, that we're seeing on the horizon, like, that you you're sort of alluding to, that are like things that we're like, we do wanna try and move into that area. So those opportunities then maybe are a little bit more left field that then the team can kind of like explore a bit more as well.

But, like, having a little bit of alignment, I think, is useful, especially in a small team and especially where you don't have a lot of time to do it. You don't wanna go too off piste. What do you think

Speaker 0: like, in terms of some of those things that might be on that horizon? I'm just curious.

Speaker 2: Trends. Yeah. Like, one of the one of the things that I'm increasingly thinking about is about Apple moving into the AR and VR space with VisionPRO and thinking about how big of a deal that is for that kind of side of things compared to even I remember when I was at news and we were doing stuff to do with augmented reality and scanning QR codes and putting 3 d models on bus on the sides of bus stops and things like bus shelters and things like that. And, like, nothing has really moved along for a very long time in my opinion. Like, it's sort of you know, there's not sort of been like a huge like, it was novel then.

It feels a bit novel now still. But I wonder about, I pay a lot of attention to the fact that Apple are really moving into that space. And so that is something that as a business, we're like, that feels quite out of our lane compared to web and mobile, like, even though it is sort of adjacent. And so that is something that strategically I'm like, there's some there's some thinking to do here.

Speaker 0: Yeah. Oh, for sure. Yeah. I like it. I like that.

And so it's interesting. So you're saying almost like you're you've got this I think, like, Google also had a lot of companies have had this, like, idea of, like, white space where 20% of your time or whatever they can afford, is given to their their teams to say, like, hey. Just build. Like, come up with the cool stuff. It doesn't it should be generally on task, but, you know, more proof of concept.

But you kinda scope that to the projects, and you kinda budget it in and said, hopefully, if if there a client is looking for something a little bit more innovative, it's like, well, we're we're gonna kinda go off and do some like, a little r and d sprint as part of the budgeted time, or how did you structure that?

Speaker 2: Yeah. That's yeah. That's we're kinda talking about 2 different 2 different approaches there. Right? On on one hand, you've got the the, like, time that is for us specifically that we're kind of enshrining as non client time.

But then on client projects, it's really about, trying sort of keeping keeping things in the back of your mind of, like, things that you'd like to do or things that feel interesting or worth exploring and trying to find opportunities to to kind of worm them into a project or trying to, like, sell them into to an idea that a client has or a problem that a client has and being like, oh, like, we actually think that that this, like, new thing that we've that we've seen that we wanna do a bit of experimenting with, you know, it's you've got a you know, finding something small that we can that we can, like, experiment with something on. And I'm thinking specifically there about new tools or new frameworks or things like that rather than anything too major, just sort of like really about kind of staying at the edge of, you know, the tools using the right tools and using the best tools, to to get the job done. Right?

Speaker 0: Yeah. I like I like that. So I guess that kind of is is pretty interesting. That kinda segues in. I would almost throw it back to to either of you, I guess, at this point.

But, on that the tech side, you know, in terms of the stack, are there specific tools or platforms, that have been, like, pretty pretty crucial in building out the different projects that, either of your you know, you or your teams have been have been pushing? Specifically through the lens of, like, this intersection of creative and technology. Obviously, there's plenty to to go through in the tech stack, but I think this is a more nuanced space. Well, of course, Unity. I

Speaker 1: mean, I I do agree with Unity. Just, you know yeah. I'll leave it there. I won't pitch for my own company too much or the company I'm a part of. But so other than that, I would say, 3.

Js. My goodness, Ricardo and team over the years, that was really the real entryway for me because I started out as a web guy. I started to mess around with 3 d, didn't understand it so well. And then after banging my head against 3. Js and relearning matrix multiplication and all that good stuff, it's it's paid dividends as, the web has become more powerful, WebGL and now WebGPU, and WebAssembly, you can do a whole lot of stuff.

David, you had mentioned the there being a gulf between AR, VR, and, and the web and mobile. But I found with things like like the quest, I could do it so much through the web. It was really exciting. And that was one of the things that I worked on at Amazon was, their Sumerian product, which was pretty interesting. To me, the most powerful thing, it was all in browser, sort of like Unity lite in browser.

The most powerful thing was the blue publish button on the top. You can make any experiment you want. And then the moment that you were ready to share it with the world, you hit that button, and it takes a few seconds, maybe like 10 seconds. And in that 10 seconds, it is taking your project and replicating it on all of Amazon's servers with all of its 9.9 whatever uptime, and you can immediately share that URL out to anyone. And I thought that was so

Speaker 0: cool. 9.9 uptime is not that great, Stu.

Speaker 1: Well, 99 whatever. Yeah.

Speaker 0: They do the they do the best replacement. Yeah. Yeah. But I mean, 3 JS, I mean, it's crazy. I mean, I guess similar to Directus, you know, what I've been working on, it's been around for a long time, but its relevance kind of can still be in the future.

Like, it can become more relevant over time depending on I mean, 3 JS has just been, like, just such an amazing thing to not just follow along, but just to use, like, just browsing through the demo pages and all that and just being like, oh, I could kind of fork this idea and just run with it. It's such an amazing platform. I think there's all and then obviously being it's open source. I think it's MIT, obviously. Oh, yeah.

Yeah. Yeah. Like, I think that's a big any open source tooling, is is a big win in my book.

Speaker 1: I've contributed tiny like, a tiny, tiny bit.

Speaker 0: For 3. Js? Yeah. Oh, wow.

Speaker 1: It's it's not really worth mentioning, because it's so small in the scheme of things. There are real contributors.

Speaker 2: You're doing it anyway.

Speaker 1: It's like, okay. Yes. I gave back a tiny bit to this tool that has helped me.

Speaker 0: We'll we'll call it a micro maintainer.

Speaker 1: There we there we go. Yeah.

Speaker 2: I

Speaker 0: like it. How about how about you, David?

Speaker 2: I think, like yeah. It's interesting. I I had some notes about thinking about tooling of things like 3 JS and and stuff in kind of Webexa land. Like, I think for for things that are around, like creative and bringing creative ideas to life, I try and think of, like, what are the tools that are like one person tools, right, where you can go from nothing to done. Like, you were just describing right where you're talking about, like, building, you know, working on an experiment and then publishing it, right.

And you've got all of that tooling in place, that means that you as one person can go from idea to execution to deployment and, like, live and and actually in in the real world. Right? Like, it's boring, but we use, Ruby on Rails, right, as a as a web framework for for most of the stuff that we do, all of the web apps that we're doing. And that has the same kind of idea. Like, in fact, the the founder, David Heinemann Hansen, was saying this at the conference the other week of, like, it's like a one person framework.

Right? It's like one person can do the front end, the back end, the deployment, the maintenance. Like, the tooling is designed to be used by one person and actually make, like, make a lift as one person rather than having something that is inherently complex or has multiple moving parts or you need to add more moving parts to it to bring it to life. Right? So that if you're sort of building something yourself from scratch in, I don't know, some some JavaScript framework where like, some back end JavaScript framework where you've gotta also work out the hosting and, you know, you've gotta decide, is it is it is it microservices based?

Is it am I gonna put it in a cluster somewhere? Am I gonna you know, how do I how do I get this live? What do I need to think about? Like, those things start to turn into, like, things that you naturally split up into multiple people or you need, you need a person just keeping an eye on it every day and that kind of thing. And and so I really like, like, that's the kind of thing that I that I think about, of, like, what are what are the tools that are, you know, that are that are good for, like, one person that that cover everything from from from start to

Speaker 1: finish. Well, I feel like here's where we could also segue into direct us, which is

Speaker 2: I did have that I did have that written down that, like, you know, directors is kind of a bit of a one person tool, right, in the sense that it there we go. In the sense that it wait. Where can I get one of them? I haven't I don't have one of those on my desk. What is it?

Hang on.

Speaker 0: I always have, like, a 1,000 of them printed, like, today, so we'll we'll touch base. Great.

Speaker 2: Yeah. Like, in the same way. Right? In in in the you know, it's like database. You've got APIs.

Like, it's giving you all of the it's giving you the front end layer to work in. It's giving you the API layer to work in. There's a director's cloud hosted environment. Right? Again, like it is.

It's it does feel like that kind of thing of, like, tool tool of tool of 1 team you know, 1 person teams kind of thing. Yeah. And I think, like and then, otherwise, I was thinking a little bit about, like, what tools do I use just to, like on the very creative end when I'm thinking about just, like, coming up with ideas? And I have to plug I have a special place in my heart for Excalidraw. Do either of you use Excalidraw for, like, for, like, putting together little diagrams of stuff?

Speaker 1: No. The comics

Speaker 0: at the end of, of Yeah.

Speaker 2: But it's it's I don't know what it is. It's something it's so aesthetically pleasing to use. You you open up Excalidraw, and it's like a blank it's like the classic, like, infinite whiteboard, infinite canvas type tool, but, like, everything looks like you've scribbled it. And there's and it has just the right amount of shapes and colors and lines and sizes that everything you make just looks I don't know. I look over my old Excalidraw drawings, and I'm like, these are all so nice.

They all just it just makes everything look it's like just it's like just loose enough. It gets kind of reminds me of, like, balsamic mock ups, but I always felt like balsamic mock ups, the aesthetic of that never really kind of vibed with me. I think that is too Comic Sans of of mock ups, but something about Excalidraw, I just

Speaker 0: might Yeah. We we use that a lot just for, like, quick, like, oh, let's just go in there. I think, hilariously because I I believe, if I'm remembering the tool the tool correctly, it gives you, like, a one of those random names, whenever you join until you, like, register and say this is your actual name. Right. And the first time I logged in, I'm in with, you know, 20, 30 people, on the direct score team, and it it assigned me Tremendous Beaver, was my my written name.

And I I think that still floats around in our Discord server. So, but, yeah, I think it's that balance. I mean, right there is a balance of, like, looseness and, like, get things done. Right. Striking that balance is really difficult.

It seems easy, like, just with with design. Like, design becomes transparent when it's done really well. I feel like a tool like that, just makes it seem effortless. Hopefully, that's what we're trying to do with Directus as well. And you you mentioned sort of it's a good tool for 1 engineer, and I think another aspect or facet of that is when you can make that one engineer, that one creative technologist, whatever it is, seem like 10.

You know, it's not just effective. You can do it yourself, but giving them the abilities of, like, oh, I'm just, you know, just front end. It's like, oh, this kinda allows you to be full stack and kind of build, at a full stack level. There's some marketing stuff in there somewhere. Yeah.

You're right about that. Is there, like, a good way to assess? I mean, you have emergent tech. You've got, you know, AI. You've got all these amazing things that are kind of flowing out.

And how can you use them, incorporate them into your workflow, be more efficient. But, also, sometimes when you're building it into the stack, especially the stack of a client, that might you're gonna build it and sort of deliver it, and it's gonna exist and maybe you have to maintain it for months here, how do you ensure that the tech that might be a little newer is actually stable enough? You know, it's, obviously, it's out of beta. It's all that. But, like, how do you know that it's the right decision?

Or do you just say, like, well, we'll we'll learn from this, and maybe we won't use it for the next project. Maybe we'll have to rip it out, you know, 6, 12 months later. But anything in terms of that evaluation process?

Speaker 2: I think you've kinda talked you kinda started to touch on it, really. I I think that it's all about experimentation, and it's about time boxing and making sure that you have some time to evaluate at the end or or to have some kind of retrospective either as an individual or as a team of, like, how do we feel it when using that new technology or experimenting with that new paradigm or new approach? Like, did we like it? Did it did it and, you know, upfront deciding, like, is this gonna speed us up? Is the plan that is gonna you know, it's gonna make us happier to do whatever it is we're doing?

You know, and and really making sure to be critical of the of the the work that you've done and the process you've gone on and be like and be willing to discard it. Right? And be willing to go, no. That was shit. Let's never use that again.

Right? It it it really, like, it really slowed us down, or it was really error prone. Or, you know, we learned things like kinds of things. I was trying to think of examples of that, and I was like, we tried to experiment building something largely using serverless functions, right, on on AWS with with Lambda functions. And we were like, let's never do that again.

Like, that was horrendous. Like, it just slowed us down. It was like that we didn't see the benefits of the you know, that we that we were expecting to see. Let's let's let's not do that again. Like, making sure to do that, right, and have that process.

And, yeah, I think there is that concern of, like, if you've baked something in and now, like, do you need to rip it out if if it's not great? But I have an element of pragmatism of, like, if something works, then it's prob like, you maybe don't need to worry too much about the thing that you've built if it's not working, like, especially on the engineering side as engineers. Engineers love things to be, like, perfect and and technically correct and engineeringly, like like, neat and tidy up. And I strongly push against that all the time. Like, as much as I can, I try and push against that because I think that it's too easy to fall down that hole versus just being like, well, what you know, is it really valuable for it to be perfect?

Or, sure, it might be a little bit unmaintainable, but, you know, how long is it gonna last anyway? Like and is that thing gonna completely change in in 6 months or a year because the business has moved on, the idea has moved on, the product has moved on? Maybe you're gonna get an opportunity in 6 months to just throw it away anyway because the value the direction has shifted. So I wouldn't worry preemptively about kind of refactoring something just because you're worried that it's gonna be a bit less maintainable.

Speaker 0: Yeah. Yeah. I guess it depends if you're building whatever the tech stack is or the project at, like, the foundational level or more the facade, you know, that's gonna just like, a ephemeral, microsite or something like that, or product that's gonna be I I think it was also a piece of it is, like, even if you like it, you know, David or Stu or your teams are like, oh, this is amazing. You know, 3 JS, not a good example here, but, you know, the kind of the rug being pulled out from under you if it's like it stops being so popular, and something else kinda comes in. Like, oh, Sketch is the right meme.

Sketch is the right tool, and then you go over to Figma. I was on I love Sketch, and then suddenly I was like, no Figma's Yeah. Absolutely where where the future is. And then there's been lots of projects where, like, an open source maintainer just disappears and then Mhmm. Love it, but it just isn't available or it's just not the right tool.

Or you've got the the niece of the the client, kinda recommend some some tech tech, and they're like, oh, this is what we have to use. This is a requirement. I'm like, oh, well, why? That's not Mhmm. The right job.

Speaker 2: I mean, the thing with the thing with, like, stuff being abandoned or whatever, like and the and the risk of that is, like, well, like, how much were you sped up by using that thing in the first place, and how much are you now being slowed down by it being abandoned? Right? Like, you gotta you gotta look at the whole picture. And, like, you know, you you can't necessarily tell what's gonna what's gonna, like, be less supported or is not gonna be the the favorite going forwards. And it's like, you know, if it helps you at the time and at the time you evaluated it and you had a good evaluation process that you can kinda stand behind and you're like, yeah.

We decided that that was the right thing at the time. And now in hindsight, it was a terrible choice. But also, like, we were sped up at the time, and we got the job done, and we delivered the project. Like, what, like, where do you wanna be? Like, do you want the thing or not?

We could also stay at decision paralysis at the start of the project forever and just wait to see which thing comes out as the best. That is true.

Speaker 1: This is part of the reason I like to, comment my code so heavily to document those decisions

Speaker 0: poor,

Speaker 1: you know, whether they turn out to be better in the future. Also, because it may seem altruistic at first, but it's mostly for me,

Speaker 0: you know,

Speaker 1: 6 months down the road looking at your own code being like, why? Yeah. Why did I do this?

Speaker 0: And then to read like,

Speaker 1: oh, this, you know, this very minor edge case is gonna be

Speaker 0: There's nothing worse than, like, you go into your old code, and you're like, that's not the way that should be.

Speaker 1: Why did I

Speaker 0: do that? And then you, like, try to fix it. And then, like, 2 days later, you're like, oh, that's why I did that.

Speaker 2: Yeah. I can't oh, yeah.

Speaker 0: That makes sense.

Speaker 2: I always I'm always writing comments and encouraging the team to write a comment. You know, if you're just, like, hacking a fix in, but it's because you've got no time, add a comment being like, hey. Hey. I know this isn't great, but, like, I'm I'm under time pressure right now. Right?

And just and just, like, being being nice to your past self and and your past team selves when you're looking at code and you're like, what the hell are they thinking? And it's like, well, maybe they were, like, under super client pressure at the time or, like, you know, didn't have the full picture of what was going on, and and now you do. And it's like like, that's the like, software is the the clue is in the start, but it's soft. Right? You can change it.

It's Okay. If it's bad today, you can someday, if it's so bad, you can fix it. You can do something about it.

Speaker 0: Yeah. And you're not, I mean, you're not really intimating unless you're breaking things. Yeah. Right. You gotta just document those breaks, why those breaks are there intentionally and with nice fun emojis right there in the comments and the GIF.

Yeah. So I'm curious, you know, when starting the creative process, you know, Stu, I'll I'll throw this over to you, and, you know, there's obviously Jed's other point. You have lots of things that, you know, back when we were, like, I like, living together and you were working through these really exciting projects, and now there's probably more enterprise y, large scale projects. But regardless, when you're starting a project like that from scratch, you're sort of in the initial ideation, you know, r and d

Speaker 1: Yeah.

Speaker 0: Phase? Like, how what does that look like for you, like, moving through that process from, you know, 0 plus?

Speaker 1: Yeah. Well, in some ways, I feel like such a dinosaur that I'm almost embarrassed to to talk about it. But, I'm I'm really into physicalizing ideas. And, obviously, I'm a tech guy. Right?

I don't think we'd be having any of this discussion were it otherwise. But, and yet, pen on paper, Sharpie, just, you know, paper's recyclable. It's cheap. You can burn through ideas. The worse the scribble, maybe the better.

And then being able to physically tape up or pin up that stuff so that your your memories are anchored physically around you, and you can refer to a cluster of ideas. And so I know it feels like most people don't work that way in 2023, and it feels like a very old, mammalian kind of, you know, I need to physically represent things in a certain time and place, but, yeah, that's that's how I'll start to formalize the very cloudy ideas in my head. And then from there, I'll start, you know, sketching in, maybe in Figma, if we're really honest, sometimes illustrator still, or directly in code. And, you know, code's so wonderfully flexible that, yeah. So, yeah, for me, it still begins with a a physical process.

Speaker 0: Interesting. Yes. I like, I've seen a lot of that, like, working with companies like IDEO. They're big on, like, sticky notes. I remember back in, like, school so are you is it, like, printout paper, like, no lines, line paper, grid paper, field notes?

I'm so curious.

Speaker 2: Like,

Speaker 0: paper is pretty tense about a space stationery. Sticking up to your walls.

Speaker 1: You know, back back when we lived together, ancient times and, and Yukon, really, I mean, I was all about those, Rhodia grid pads. You know? I needed the grid. Yeah. I'm sure you have some within reach.

Probably.

Speaker 0: There's a lot. I have, like, literally just from, like, from those times and just I'm like, in my head, like, yes. That's exactly what I need. It's just pads, field notes, grid paper, like, just every sort of paper. Like, yes.

Right tool for the right jobs. Like, sometimes you need a grid, sometimes you don't. It's like an home and joy.

Speaker 1: Yeah. I I started to migrate, around I guess when I when I went back to school, I realized I started getting all of these notebooks that were just, blank paper, just blank, no grid. Yeah. Just no rules. No no constraints.

Oh, there must be speaking of, like,

Speaker 0: the design the intersection of design development, sorry, Code and creative. I feel like there's the intersection of, like, sticky notes in a in a notepad, like, in a, like, spiral notebook. There has to be I mean, I guess maybe it is just a sticky pad, but something a little bit more formalized. So it's like a book, but you can just pull it out and it's got the sticky Mhmm. Right there on it.

We'll we'll get there. I like that. So, David, any thoughts on that? Like, when you're starting starting your process, anything specific beyond sort of taking into the world with with stickiness?

Speaker 2: Yeah. I was thinking actually about that that thing where you said, like, the worse the sketch, the better. It reminded me of, you familiar with the process shape up from, from base camp and 37 signals. They have like a whole dot. There's a, if you Google it, you'll find it.

And they, they talk about thick marker wireframes, Right? So using, like, a really thick pen to draw a wireframe so that no one can get bogged down in the detail of, like, how you know, is this thing this size or that size? Is it adjacent to that thing or above it or or to the left of it? Like because it's like the you've used such a thick marker that you can't tell the detail. You can just kinda get an idea of the rough shape, is like a that's what it made me think of when you were like, the worse the sketch, the better.

I'm like, yeah. I definitely see the value in this.

Speaker 1: Engineer that. So working on some very early was yeah. Wow. This was web based VR stuff in, Creative Lab around, like, 2015, I guess, maybe 2016. So, we were kicking around some ideas, potential product tie ins, things like well, I won't mention what we were working on exactly, but it involved us making some sketches of things in VR and these were early prototypal things that we were going to use to excite the people with the money in the company and then get the budget so that we could outsource and bring in you know, modelers and and, you know, hardcore VR engineers, and then we could start to build the thing.

But the problem was making these prototypes. They looked terrible. You know, they're mostly, you know, low poly things that we could make quickly And that was lost on a lot of our higher ups and executives. They'd put on the headset and they'd be, why is it so terrible? And we kept trying to say, this is a sketch.

Don't you understand that that looseness and terrible, you know, the slow it looks like, you know, lawnmower man because we're not spending money or too much time on this. And no matter how many words we tried to use to verbalize it, it didn't come across as a sketch. And this was, shortly after Google had acquired, Tilt Brush. And Tilt Brush did not have a scaling feature in it yet. It was early days, and we were making this cityscape and it looked terrible.

So I had this idea, we need to do the napkin sketch for VR. So what if, just in my living room at home, I had my own VR rig. What if I could use Tilt Brush to hand draw the cityscape so it looks like a sketch? But you needed to be inside of it, and you couldn't do that yet. You could only draw as tall as you could reach.

That was the, you know, the limitation of Tilt Brush. But now I knew these folks. They were part of the Google family, so I was able to just email them and say, hey, I need to scale up these drawings. How could I do this? And they were able to send me, you know, some Python code and and walk me through how their, Tilt Brush files were organized, how I could break them apart, you know, increase the size of all the vectors, which is pretty easy operation.

It just wasn't in the interface yet. Put it back together and then open it. And so ultimately, that's what we did. The next walkthrough was literally a sketch of what we were trying to make. So it was really like the reverse pretending that it's still on the napkin.

Yeah. I think that communicated a little better that this is a stand in for the real idea. And if you like this, give us the money, and we'll go do the real idea.

Speaker 0: Yeah. Yeah. I love that. First of all, Tilt Brush is amazing. I remember the same thing just in there just building.

I think I feel like they had a scale feature or maybe not, actually. Yeah. Probably not.

Speaker 1: I think they know. They didn't or before

Speaker 0: They chose the app. It's never happened to you.

Speaker 1: Yeah. Oh, yeah. Now, I mean, by the time that app was deprecated, it was trivial to scale things up and down. Yeah. But in the moment, we had to

Speaker 0: I think it's important. Like, the idea of, like, a rough knock or, like, those prototypes where it's like you have to enforce the rough because if you go too far, I was guilty as, like, a perfectionist. I'm like, oh, I'm making these these mock ups or whatever it might look like in the really early just pitching things. And if you, polish it too much, it's it just seemed it comes off as like a design that they start nitpicking like, oh, how do we change that? Like, we're not even looking at that.

We're looking at, like, broad strokes here. But the more detailed and accurate you make it, then they start focusing on different elements of it. So it almost helps to have, like, Tilt Brush. I'm just gonna swap this out there and just, like, see you know, just only comment on what you can see. And when you start adding and predifying it, becomes a very different conversation is is what I found.

Speaker 2: I also think it reminds me, like, as a as an engineer, like, I think about these things maybe with like, I draw a lot of technical comparisons. And I think about, like, when you're coming up with ideas and trying to, like, come up with a solution to a problem or or come up with an idea, I think about it as, like, not locally optimizing down one path. Right? And it's, like, going to if you go too detailed too early, I sort of think about it as, like, I don't know if you're familiar with this sort of, like, approaches for for for sort of, like, machine learning or finding finding optimum solutions to problems of, like, the difference between, like, a hill climb algorithm versus simulated annealing. Right?

You may be familiar with these. Like, the idea of a hill climb is like if you're sort of, like, searching through a problem space, you just go to the next best problem the next best, like, answer and then the next best answer and the next best answer. And eventually, you get to the top of where of the answer, and you're like, that's the best one. But what you didn't know was that the other side of that hill, there was another much bigger hill that was like an even better solution that was just totally different. But you couldn't get there because you were just, like, going down the better and better path and you weren't, like, exploring other options.

And then simulated annealing is the idea where of, like, when you start trying to find the solution, you have an element of randomness where you're always just like, you're sort of you know what the best you found so far is, but you then also randomly just kinda, like, go wildly off piste and try something completely different and go, is that better? And then you're like, no, no, never mind. This is actually the better thing. And then sometimes you find those completely different solutions, and you go and explore. So yeah, right.

Very similar. Very similar.

Speaker 1: Yeah. You're also describing I'm not going to do this justice, but the difference between gate based quantum computing and annealing Oh, really? D Wave does. Yeah. And their, gate based is winning for sure, but, there's some pretty good arguments, I think, for quantum annealing still.

Right. But it's the same, I won't derail this further, but it's the same sort of math.

Speaker 0: So like,

Speaker 1: you know, I mentioned, like, having to learn to multiply matrices again and, like, you know, reteaching myself linear algebra for 3 d stuff. And, you know, all that computation is best handled by a GPU, you know, massively parallel small computations. And then you start to realize it's actually pretty similar similar for, artificial intelligence and machine learning, you know, model training. And then it turns out, again, it's the same old story for quantum simulation. So, yeah, that's how that's how I bounce through those things.

But I'll

Speaker 0: Yeah. Yeah.

Speaker 1: I'm derailing. So What's more

Speaker 0: what's more exciting than quantum I mean, I don't I know nothing of quantum computing, but what could be more exciting than than going off the rails there?

Speaker 2: I once, I once met someone who was at a at a wedding who's, like, doing research in quantum computing, and I was like, oh, this will be interesting to talk about. Like, I I'm a you know, I'm an engineer. I know a little bit about this kind of stuff maybe. And And I was like, so tell me a little bit about what you're working on. And I think I got a best one in 10 words that he said.

I was like, I have not like, you have just immediately lost me. Because he was in some kind of, like, world to do with, like it was something to do with about how you measure the output, and there was some very specific detail of what he was looking at. And I obviously cannot remember it. I did not understand it at the time. It was fascinating to just hear someone talk about it and realize that I'm like, I I'm getting 1% of this.

Speaker 1: Yeah. But if if you think it's an exciting topic, I have a recommendation, which is, this guy who was at Microsoft at the time, Andrew Hellwer, I think is his name. I think it's h e l w e r. He gives this lecture that you can find on YouTube, and it's named after clearly his favorite book on the subject, which is a great book. It's called Quantum Computing for Computer Scientists, And, I've forced myself through the book.

His lecture is so much more to the point and beautiful in its simplicity. He throws away all of the bad metaphors about, you know, cats in boxes and, you know, pizza bagels. Is it a pizza? Is it a bagel? It throws that away, and it gives you the very basic math, from a computer scientist perspective.

And from there, that's that was my entryway because I was trying to figure out, like, what is the super cool quantum, quantum computing, quantum physics, whatever superposition? And because of him, I can now give some pretty concrete answers about what's a cubit and how does it work, at least from a mathematical perspective. The actual physics of this stuff is

Speaker 2: Of how that stuff works is, yeah. It's I feel like

Speaker 0: I'm in much easier to get the Schrodinger side than the math side. I'm a visual No. No. No.

Speaker 1: A a cubit is just two values. That's it. It's just a pair of numbers, and then you can build from there. That's it. Yeah.

It's just a pair of numbers.

Speaker 0: It's only that easy. We're just period and then end of end of the whole lecture. Yeah. So to kinda, like, bridge quantum computing, which is I'm not gonna say inaccessible until you listen to that lecture and you really understand all about it. So, like, AI and something that is, for a lot of people, you know, very inaccessible in terms of really understanding how it's all happening behind the scenes.

But there is sort of a resurgence or not resurgence, but a continued resurgence of, you know, AR and VR and AI, all these things kinda, like, coming to a to a front. I'm curious, what do you think so specifically on the on the ARVR side because I think there's probably more experience there. Stu or David, any thoughts on how that's gonna change the landscape in terms of, building online experiences?

Speaker 2: I mean, I just I That's definitely one for handle, you know, like, can't

Speaker 0: stand those people with community on its name. You know, from from professional to prosumer to consumer and then just keep working its way down the tree. I'm curious what your thoughts are on, like, what do what do think the the issues might be, the challenges, the opportunities, the cool stuff that might start flowing and maybe when, in the ARVR space?

Speaker 1: Well, I I think it'll take me a moment to process

Speaker 0: what I

Speaker 1: can talk about and what I can't talk about. So I'll I'll start with a story from the the pandemic, or, well, let's say lockdown. It's still a pandemic, right? We're still anyway, in fact, I'm almost officially, one line again on the COVID test Just

Speaker 0: a

Speaker 1: Yeah. That was my past week. So we were we were working on something at Amazon, a side project that had to do with warehouse spaces and developing a sort of kiosk that would be for internal use for, you know, a specific task. And we're all working from home. We're all trying to figure out how to do that and also work on projects together.

And, to develop this kiosk, I really what I really needed was to have, like, a bunch of different TV screens and things delivered to my home and to have someone prototype these things together. And then I could say, like, you know, this is too big, too small, in the wrong place, whatever, and that just wasn't happening. We just weren't at that point as a society to make that possible, nor do I really have warehouse space in my small Brooklyn apartment. But what I could do was very quickly mock up all of these things, using Amazon Sumerian, put on the headset, and walk around in that space and and get a sense, you know, style, in relation to the size of my own body and feel like, oh, okay. So if this is proper scale, this one feels right.

This one doesn't. You know, this is somewhere in between. And it's an immediate gut reaction, and it cuts out all of the guesswork just being able to be virtually in that space, without having to pay for any of the hardware, have it shipped, have it set up. So that that may be a safe way to start to tiptoe into answers here to that question, hopefully.

Speaker 0: Yeah. No. I mean, a 100%. I mean, I've it's it's interesting just the spatial side of it because you're you know, obviously, it's immersive, but that means, you know, we are directional as a as a animal. You know, we see this way, but it's you know, there's things going on behind you, and so it's just a whole different landscape.

You know, what you what you kinda mentioned, I think, kinda ties into the fact that, you know, it's it's just a completely different ballgame. It'll be a different mindset for how you develop and build in that space. How do you hint to somebody that, like, you're supposed to be looking behind you? So, like, maybe maybe turn around and go look at that call to action or whatever whatever that might look like.

Speaker 1: Yeah. Oh, for that, I mean, shout out to, former colleague, Jess Brillhart, who's a big name at Creative Lab and now continues to be a big name on the West Coast. She gave the keynote at South by Southwest a while ago for immersive experiences. She's a filmmaker by education, and has a lot to say about directing attention and focus in a 3 60 degree medium, and I say 360 because at the time, it was really 3 60 film. So it really it really was like rails in a circle around you, and, of course, immersive is, you know, that on all axes.

Speaker 0: Yeah. The 360 day, that was the project that I was working on at, that large company that got 90% of the way there and then got scrapped because of video content being lacking. So ARVR is pretty exciting because the content doesn't lack. You just create it. It's a little bit more generative, so that's, a different different space.

But, so we're coming up on an hour. There's a a bunch of questions that came in, but I don't know if we're gonna have time for those. But, yeah, any any what's that?

Speaker 1: Oh, no. I feel I feel bad. We should get to Well,

Speaker 0: I some of them. Let's throw we could throw one in because I think it kind of brings us back to that sort of the intersection space, which the question was, do you have any strategies around fostering collaboration culture between designers and developers? And I'll just quickly like, I this is a big thing for me at Ranger, my my old agency, because, I I was both. So I was, you know, I was the intersection, and I just tried to hire people that were the same, you know, that had the same sort of, like, training or or background skills, that I had. And And so I was able to avoid that altogether.

You know? And I kinda even pitched that in meetings. I was like, oh, there's the Harvard, like, oh, we're gonna have the seating chart. You know, and we're gonna have our designers here and developers there, and here's how they work in pods and all that. And I was like or you could just avoid the communication altogether and just make them all, you know, it's kind of pre creative technologies, you know, as you turn.

Any thoughts on how you can foster that? Like, if you have teams of, like, strictly developers and strictly designers, how you can, marry the 2 of those for either of you?

Speaker 2: I've been thinking about this a lot at the moment. Because as an as an agency, we don't have any designers at the moment on us on staff. So we work a lot with third party designers or design teams or freelancers. And so I've been thinking about this a lot because we've it's always been a challenge. We've never quite hit on the right process, and we still haven't hit on the right process.

But some of the things that I think about is, like, I think the best devs are the ones that know a little bit of design or, like, good UX and goods, like, like, understand what, you know, some of the, like, just kind of, like, basic underlying principles about what's good and bad design. And the best designers are the ones that understand a little bit about what are the limitations of the medium that I'm delivering into. Right? My worst experiences of working with designers are people who are print designers by trade and haven't really adapted to the web and that but are just doing some web design stuff as well. And it's like that is just such a different world that, like, it it doesn't align.

Similarly, I've worked with devs or or or, like, helped look after devs who don't who just don't intrinsically understand anything about good or bad UX. And so as a result, we'll, like, implement designs badly or, like, not even put the right kind of boilerplate and skeleton in place to kinda unlock further development on top. And then, otherwise, I think, like, just a lot of side by side work. Right? Like, just making sure that things are iterative, making sure that it's about, like, responding to challenges, especially when it comes down to kind of delivery.

The worst projects are the ones where delivery of designs is a cutoff point. Okay. Now start the designs. Now start the implementation. Sorry.

And the best ones are the ones where, like, every small stumbling block of, like, oh, this is actually really hard to lay out on the page, or this is actually really hard to bring to life. Like, but if you just change would it be like, if we just tweak this, it'll be way easier to do. And then, you know, having that kind of that process of, like, it's not about, like, criticizing the designs being wrong. It's about, like, work working within each other's limitations, the space of delivery, and the space of design. I think that that works best, which is maybe a maybe an obvious answer.

Speaker 0: Yeah. No. But an important one. I mean, again, like, not to get into methodologies, but, like, the waterfall, you know, especially if the designers are just not aware of what they can or can't do can be really problematic. They have to progressively enhance, and they have to know the limitations.

And if you only find that out once things are done and polished, you're you're in a bad bad spot. But Yeah. Stu, any any thoughts on that one?

Speaker 1: Well, I feel like I have a similar experience as you. So educationally, I think we're both taught print design, but, of course, with, that's not our trade at all. You know, we're in the code from an early age, so that sorted itself out. Still big love for good print design though.

Speaker 2: Yeah. For sure.

Speaker 1: But like you, I'm that intersection and I kind of, my present team excluded because I love my team, so I don't wanna give the impression that I don't. I think outside of my team, what I've experienced in the past is that, like, it's the 2020s. Why are these things still separate? They should all be me. That sounds very narcissistic or very arrogant.

I mean, like, I accidentally somehow had these two influences and I'd like to think it was special. That should no longer be special. It's the kids coming up today really ought to have a foot in both worlds and may specialize in 1 or the other, but it's just so weird to me to meet young folks who don't, who seem to be firmly in one camp or the other because it just seems like evolutionarily, that that's just how it should be today.

Speaker 2: Yeah. And you can actually see

Speaker 0: When I would hire people at Ranger, I was I used to talk about, like, this t shaped tire. You know, you've got, a deep dive in their area of specialty, but then a crossbar of understanding so they can communicate with the other teams. You know? I'm a I'm a friend developer, but I can talk to the designers in the back end database. But Yeah.

Now I feel like I need to update. Maybe it's like a capital m, and it's like you got a couple deep dives, a little bit more, you know, jack or jill of all trades. You you understand this and that. You're kept but you're a little bit more sprawling with the adjacent sides of you know, print design can be super relevant in how you do digital design, which can be really key in how you do UX and UI. And, you know, I think it all is really just makes a more robust, experience in person, when they're a little bit more multifaceted.

But

Speaker 1: yeah. I just wanna reiterate again, love my team. It's just it's in the back of my head because we were our team was having this discussion recently. And so, you know, shout

Speaker 0: out to Yeah. That's a huge one. I I completely agree. I I watch sci fi movies all the time. I'm like, man, this is I watched the old sci fi movies.

Like, they're saying, like, by 2020, we're gonna be in a very different place than where we are actually. I saw one last night with a creator, which was very timely with, you know, the AI stuff, and it was and it had some amazing not print design, but sort of that feeling to it. So I think, yeah, there's lots of ways all this can get pulled together. I but I think it all comes down to that intersection. Whether intersection is inside of one person, you know, they're they're both as, you know, I think the 3 of us are, or you can foster and bring together multiple people across a team and make that team sort of the the whole of of this idea of that intersection.

I as I mentioned, I love metaphor, and I'll leave I'll leave us with, a story from when Stu and I used to live together. So we, you know, probably riding around the kitchen with on a unicycle or something. But, at one point, we had a a microwave, and it was, you know, just a throwaway junkie microwave we found. We're like, well, we're not gonna use it. We're just gonna trash it.

And so we're like, well, what can we microwaves, you know, as as as younger people do? And so we we put, like, soap in there, and, like, soap was doing cool stuff and all that. And then we figured out, the the, you know, the ultimate test was this grape. And we just cut a grape in half, and you sort of leave the two halves of the grape just slightly connected. And it essentially the sugars or whatever it is, it forms plasma, and this ball of plasma rose to the top of the microwave and literally was melting the metal.

But it just came to me while we were talking, and I was thinking back through all those those sort of things that happened. I was like, that's the intersection of design development. You have just, you know, 2 things to these 2 halves. This could be very different, but just you have that connection, and then suddenly you've got this plasma ball that's burning right through the top. You're innovating to the point where you're breaking things, and that's what we're all trying to do.

Speaker 2: So And then your microwave explodes.

Speaker 0: And then the microwave explodes. And then

Speaker 2: it was I

Speaker 0: burned up the the I burned up the Yeah.

Speaker 1: I had the cord, you know, just ready to pull out anything whenever

Speaker 0: At least we had yeah. We had the the fire extinguisher and the cord ready to get pulled, but, no, it was awesome. And I'm just trying

Speaker 2: to work out where that was going as you were saying that. I was like, where is this where where is this coming back

Speaker 0: You just We made it again. Awesome. Well, a little over time, but I this was super like, just I love just meandering through these these different topics, and and, I I think that's what it's what it's all about. How can you be creative if you had everything super structured? So, yeah, David, Stu, thank you so much for for hopping on and chatting through this.

Hopefully, we can we can do it again sometime. This was this was awesome. Yeah. Make sure it happens.

Speaker 2: Cool.

Speaker 0: Alright. Thanks, guys.