Connie Shi + Matvei Malkov, Google Material Design

On what makes software engineering a true creative practice

Liam speaks with Googlers Connie Shi, a software engineer on Material Design, and Matvei Malkov, a software engineer on Jetpack Compose, and the trio unpack what makes coding a creative practice, and which creative choices are required when you build a design system for other developers around the world.

The wide-ranging conversation turns from complex problem solving and technical logic to the concept of creativity as the question-provoking quality of a thought.

---

Liam Spradlin: Okay, welcome to Design Notes.

Matvei Malkov: Hello.

Connie Shi: Hello.

Liam: Uh, so just as an introduction, I want to hear from each of you, Connie and Matvei, what it is that you're working on now and what the journey was like that brought you to that point? And maybe, Connie, I'll start with you.

Connie: Sure. I'm currently working on the, um, Compose Material 3 Library as part of Jetpack Compose. How I came to this point is I studied computer graphics in college. Uh, worked on a series of mobile applications and became interested as part of that in understanding more about the design-system side and also how UI libraries are created. An opportunity came up and I joined Materials Design four years ago. And have been, uh, fortunate to collaborate very closely with the Android team for the past few years.

Liam: And, Matvei?

Matvei: And for me, um, I think it's, uh, you know, pretty, uh, pretty straightforward in general. I studied computer science in the, the uni as well. Then I started, uh, working just nightly, uh, like in a few agencies here and there. First of all, I started like in with the back-end development and then I switched over to mobile, specifically Android's development. Made a few apps here and there. Tried out the, to, like to be a startup person. It didn't work out.

Um, and then I decided, "Okay, maybe that's enough for me with the applications and, um, like development. Um, it's enough for me to develop for kind of users. I want to develop for developers." And, um, decided to train myself in library development, framework development, well, uh, which is what I'm currently doing. For four years I work at Google and the whole time have been in, uh, andro- uh, just toolkit team, or Android Toolkit team. Uh, so we develop libraries for other developers to, to use to build applications. Pretty exciting thing.

Liam: Both of these stories, it strikes me that both of these stories sound quite straightforward, but for me as a designer, I have a lot of questions. I'm going to have a lot of, uh, probably basic questions for you both. Matvei, when you say that you like worked in the startup world on applications and things like that, but you became more interested in building libraries, can you expand on that a little bit? What made libraries like more exciting or interesting to you than, than full applications?

Matvei: Yeah, yeah, yeah. Okay. Um, how do I, how do I tackle this? So I think the idea is there is all this, this part, uh, of you building some things for developers, um, as an engineer. But the, the audience varies quite, uh, quite a lot, right? So if I'm building something, um, in my application, I still, uh, develop things that my teammates will use and I will use later on, which kind of makes me a framework developer on the very, very, uh, small-scale, so I can serve four or five other engineers, maybe 10, maybe 20.

Um, so while I, while I was doing this kind of d- designing complex solutions, uh, for the application, reusable parts, um, and whatnot, I identified that I kind of enjoy this part of, um, of programming. Just kind of making sure that some things survive the test of time, um, still serve the purpose when the new, uh, um, requirements come from product or from, from design even.

Uh, and then I decided, "Okay, what if I will make it, uh, like a full-time job, to just make the new libraries, APIs, interfaces, uh, for developers, uh, to use?" So it kind of allows me to, um, allows me to serve a big, big, big, right, of different users, cohorts, um, different backgrounds of users, um, different expertise levels, which is pretty challenging and interesting, uh, thing we're currently doing.

Liam: Connie, would you say that it's similar for you or different?

Connie: I agr- ... I, it sounds similar. I think in reflecting on why I chose this path, from my last team, I worked on a educational product, uh, Google Classroom. And so they were very passionate and driven people who wanted to solve problems f- in the education space, which were very worthwhile. But similar to Matvei, I found myself, um, trying to balance how to focus on the end product, but also, finding time and space to make sure that the software and the engineering behind the product was solid and, you know, brought user delight.

And was accessible, and all these other aspects that, which contribute to the enjoyment and the, um, end goals of the product that wasn't exactly stated in our, you know, annual, um, goals or road maps. And so it was, I think I realized that I gravitated over time towards the, like Matvei was saying, building tools, so that it would make it easier for other developers who are more business logic or product focused to be able to do that aspect of their job easier. Instead, of having to figure out how to cleverly, um, or use extra time that they had to focus on these more foundational building blocks that should be available and somewhat standardized so that, um, more of our peers can take advantage of.

Liam: It sounds like maybe it was something that you wish someone else was doing back when you were working on product.

Connie: Absolutely, back then, um, at Google, there was a crowdsource library before the Material Design team, I think staffed up our own engineering, um, teams and produced a library. So it was very fortunate that by the time I was interested there was this opportunity to, uh, participate.

Liam: I want to back up and understand. Connie, you said you studied computer graphics. I'm interested to know what you learned there and how that informs your software engineering practice?

Connie: Sure. I went to school to study computer science, but my focus was computer graphics because when I was much younger, I was very interested in animation. I wanted to work at, uh, places like Pixar or DreamWorks as a special effects artist. But over time, I realized that what interested more, while the, you know, the, the visual art was very beautiful, that I was more interested in the tooling and how to, um, solve the problems that arose from, uh, at first just like the computational limitations.

But then, um, later also, uh, I think I, as I learned more about what the life of a visual artist, uh, is like, it appealed to me less than, uh, what it's like to be a software engineer, which I think is a lot about solving problems. And understanding constraints. All the things that I think we will discuss further on, but, um, you were asking me, how does that ... Sorry. Could you repeat the question? (laughs)

Liam: Sure. I'm curious how, um, how that kind of perspective informs the way that you create software now?

Connie: I think when I first started studying computer science, I thought it was a very logical, mathematical-based, uh, discipline. That there was, you know, a right answer and a wrong answer, very black-and-white. And as I continued my studies in both the very, you know, logical computer science side and then also computer graphics, I realized that it's more of a craft. And more of a trade, and so there's a lot ... There's no one right answer, right? The creativity ... I guess, I, I think through computer graphics, I discovered the creativity side of, uh, software engineering.

And so I think when I, through my day-to-day job, I try to think about I guess, the, the subjective aspects, and the human aspects of computer science, and software engineering because until whatever artificial intelligence can take over our jobs completely, we have to (laughs) deal with that very, um, you know, sometimes illogical, but always very fascinating, interesting part of, uh, dealing with another person.

Liam: Yeah. Okay, I, I'm really interested in that, um, because you two are the first software engineers that I've had on the show, except for maybe a pilot episode that I recorded back in the beginning, um, with Roman Nurik. Um, and the premise for us kind of getting together for an episode is that software engineering is in fact a creative practice, which I think maybe some folks, including designers who work with software engineers might not be aware of or might, you know, not have that perspective. So I want to know from each of you, what that means? Where is that like human-subjective side to the software? Where does that come in and what makes is creative?

Matvei: Okay. I can, I can, I can give it a shot and then let me know if I'm, uh, you know, if, uh ... I'll get carried away quite a lot-

Liam: (laughs)

Matvei: ... 'cause also it's, it's a nice segue 'cause, uh, Connie talks about, um, about graphic design, right? And then, um, as I happened to study a l- uh, little bits of the graphic design like low-levels, so, you know, graphic languages, and shaders and, and whatnot. And I think that's kind of where we can touch on this creative process of in general, in creative and software engineering being a creative practice. We can go from the one side of the spectrum where you have, um, design and kind of, you know, building this mental castles of logic, um, of, uh, of a problem you're solving.

And we can end up on the other side of the spectrum, might be something like even line. Maybe it's like, uh, you know, a space of creativity. So for me, like this, uh, engineering being a creative practice is when you f- find some time, during your day to call this kind of focus mode and either see, experiment, and see things appearing on the screen. For example, for you, right, I'm kind of saying, "Okay, what if I do this? What if I do that? How do I accomplish this tricky design that I've been given?"

Uh, it sounds kind of small, but then, um, you can really, really can get carried away trying to, uh, produce something that works well, feels nice, you know, well optimized and stuff like that. And then, yeah, again, that's kind of like on, on a visual side. And on the, um, design problem I solve in space, is like where you ... Because you, you try to maintain the big problem in your s- in your head, expand on this, contract, uh, and, uh, you know, see how it, um, later spills out into the code you're writing, which is pretty, pretty creative process, uh, at least for me.

Liam: Could you walk through maybe a small example of that, the, the way that you, you know, perceive a problem, which can be addressed by code, and expand and contract that to come to a solution?

Matvei: Sure. Let's say you have, uh, maybe layout to design, right? You have like half of the screen to make it, so that it appears on user end later on. I think e- even, even from here, like you start by kind of building a mental map in your head saying, "Okay, this thing goes there. This things goes here. Those things are f- f- form kind of a group and those things are completely detached." I feel like even now, I'm talking about it and I'm kind of building a tree, a tree of elements and how they are connected.

Um, so even this, like you start getting more kind of, you know, you, you start to imagine things, right, uh, i- in, in your head. Build a tree, seeing, okay, I can solve this one with this tool. This one is with that tool. You maybe try to sketch it. Maybe you fail because the tools available to you are not enough. Or you don't know what tool you need to use yet. So you go into, into, you know, into the weeds of one section of the screen. The other one, coming back again seeing, "Okay, m- I'm kind of done with this one. I want to finish it, uh, a little bit more, but for now it's, uh, it's enough. I'm going there to another place, uh, on a screen."

Uh, design this kind of, this beats again, then zoom out again, to, to see the, the bigger picture. Maybe you get some feedback from the, from, uh, from your peers on how this looks, how this feels. Maybe you go to your designer, product manager, get the feedback, and then, you know, start over again. It's kind of more I think the example on the visual side and, um, makes you keep a lot of stuff, yeah, in mind. And kind of navigate through this.

Connie: I have to take a moment and process everything Matvei has said (laughs) because I think that's very-

Liam: (laughs) Same.

Connie: ... deep thinking. Um, maybe if I could go back to your original question of what, what does-

Liam: Mm-hmm.

Connie: ... the idea of a creative process mean to me? The word curiosity comes to mind and because I think for something to be creative, to me, it means that there's no, at least to me immediate obvious way that, you know, a problem should be solved or it has to be performed. Um, in order to I guess tap into the creativity, I think it has to be something that maybe, uh, invites questions and, uh, like I said, a curiosity to learn more. You know, maybe if you're, you know, d- day-to-day were asked to make something or solve some problem, uh, what makes it creative or what, what, uh, a list turns it into something that requires, uh, either a creative process or practice is that, you know, we want to find out more.

What is the purpose? What is the problem? Who are you trying to, um, answer the question or solve the problem for? What benefits does it bring them? What are the different possible ways we could approach it? Um, I think especially from Matvei and me because we, um, don't work in a close ecosystem, meaning, you know, we, we're not just, um, concerned about an app where we control the back-end and the front-end. And we know what the user can and and cannot do 'cause we have a very tight control.

I think that requires a lot of, um, creative thinking about, you know, "I cannot predict what everyone will try to do, so how can I, um, design something, like an API in our case, such that we promote and strongly encourage the behavior we, we want? And, um, in a not very constricting or dictatorial way, try to dissuade you from (laughs) doing what we do not wants." Um, and then of course, based on feedback from our, our lead adapters, um, and from our peers, it's a very iterative process. Because whenever you get new input, hopefully you'll be amicable and fluid enough to, um, mutate. And be nimble enough to adapt to the new, uh, needs and constraints that you learn along the way.

Matvei: Wow. This is so-

Connie: (laughs)

Matvei: ... uh, this is so, uh, deep actually and, and so true what-

Connie: (laughs)

Matvei: ... what Connie just said. I kind of got like this, um, in my head this metaphor for writing a story. Like, you know, driving, driving a person who u- who's using your tools, APIs through the story. The idea is we, we have tools and we really, really have to think on a day-to-day basis of like, "How the user will p- perceive our, our things we're building, our building blocks, uh, what should they see first? What should they bring the most attention to?" So I think it's kind of like again, storytelling, scripting thing, which is, I can see that also creative practice. So in that sense, in that sense, it's very, very, um, uh, very similar. An asset is fine, I imagine.

Liam: I have to say, first of all, I feel like I have an extremely rich picture of what goes into creating code. And second, I want to say that like the, the picture that I'm getting from both of you is actually from a process perspective, a philosophical perspective, and, yeah, a creative perspective. It sounds very similar to what an interface designer would do when they're working on an interface design. And I think having you two, who work on libraries here is such a great example because your product also, as you said, deals with users and these users happen to often be other software engineers or developers.

And I know from interface design that when we talk about trying to guide users through the story or, you know, enable them to do certain things, we think about in design like certain signifiers, which could be text, or icons, or just shaped colored regions of space that imply (laughs) the ability to do something. (laughs) And I'm curious what those signifiers are in code that allow your users, who are developers to understand what they're kind of able to do, supposed to do with the things that you create?

Matvei: First thing that comes in mind, even though being, uh, a very cliché thing, right? In, in, in programming, in programming, there is a cliché that says like there are only two hardest problems in, in programming, in engineering, which is, uh, cache invalidation and naming. We, we skip the cache invalidation because it's technical problem, but the naming, I think is something we heavily, heavily utilize in our day-to-day job.

Uh, and, um, I don't know how much time on, in my life I spent just actually, you know, just sitting down, not writing code, and thinking, "How do I name this thing?" Because the name is, uh, the utter importance for us and then for developers as well to discover, to understand what it means, what it, uh, what this thing will be used for.

Um, and it goes for kind of public things developers will see, um, on all the layers, right, so it's, uh, it's all the, the names of the parameter, what this means, um, how do we kind of signal to developers that this is the thing they need if they have this use case to solve? So, um, naming is very, very on a surface there like we, we utilize this, this thing a lot, um, among some other, some other things.

Connie: Matvei and I have had many conversations about naming and I've learned a lot from the motivations and, uh, let's say API regrets that, uh, the Android Org has had in the past. And why now, naming, you know, now there's a lot of guidance, um, around naming. I think beyond that, um, in our libraries, we try to, you know, have documentation and have examples. And we have, you know, things like a catalog app to showcase how we recommend our APIs are used.

I know that on the Material Design side, we want to be able to be helpful and be a bit more opinionated. And provide guidance, um, about the, the ranges of, not only feasibility, but recommended, you know, colors, or paddings, or boundaries, or typography, or whatever else. And I think depending on how a library is designed, that could more or less, uh, be also how we convey, um, guidance, uh, to our end developers on how, uh, we think that our library could be used to help them achieve whatever, uh, business needs they need in their application.

Liam: I want to latch onto something you said there that, um, the library is designed, (laughs) code is designed. Um, earlier, Matvei, talked about a castle of logic and a castle is certainly designed. There are a lot of materials that go into that. I'm interested in what, what, um ... There's a question that I ask to a lot of folks in different disciplines. Like what is the stuff that you're working with? What is the stuff and how do you compose it? (laughs)

Matvei: Well, I don't know. Maybe I just, um, really right now, 'cause, 'cause, uh, because of, because of what Connie said, I'm gonna attach to this idea of, you know, storytelling, um, a little bit. Um, so maybe that's why it comes to mind as well. I think it's kind of, uh, you know, it's, um, castles of logic, uh, are built on kind of like, you know, logical pieces of this goes here. If this Boolean bit flips, then we go through another completely different corridor in the castle or like just an in g- different branch, uh, in our, in our logic, like in, uh, in, uh, in our imaginary tree, uh, in my, in my head.

Connie: Uh, Liam, I can add on from a slightly, maybe a different vantage point. So I agree with everything Matvei is saying. Um, and you were asking about what materials we use? I think of, uh, what m- what Matvei has described, if I could, um, torture the castle metaphor a little bit more to be the center? And then as we expand, there's the grounds, and the moat, and whatever else that protects it. And I, I think of those as supporting features, right, that make, um, the castle strong, and, and protect it and, and for it all. And I think those, uh, are the, sometimes aspects of software engineering that we don't think about 'cause they're not so core to the code.

But they're things like documentation and the secondary things we think about like, "Yes, our primary user base is the developer, but our secondary user base, perhaps even more importantly, is the end user and how does the tools, in this case our library, how does that enable the developers to create the kind of experiences that our end users want? Um, and then also, how do we support just beyond the core library that we provide to the developers in order to, um, make the most effective use of the, of the tools that we're providing?"

So I think of the materials, you know, being the bricks are maybe the code that we write and then, you know, the documentation that we provide in the library. And then, uh, in our library cases in particular, the additional, um, developer-advocacy support, the community that we provide, um, and the, you know, ongoing support. And the, for material, the design tools and the, you know, all the other sort of huge cast of supporting characters that help enrich and create this ecosystem.

Because, you know, just like programming languages come and go, uh, libraries come and go, tools come and go. And, uh, I think sort of the, the secret sauce or the, like what differentiates between the ones that have longevity and have a rich user base is all these extra, uh, supplemental add-ons, um, that complement the primary product. That is the castle of logic.

Liam: Okay. (laughs) I'm glad, I'm glad to bring it full circle with the castle of logic. Um, as you were talking, I was also picking up on, you know, some of these supporting elements like, uh, design tooling and guidance, and things like that, um, speaks to a kind of shared language that I think is especially present on Material Design where engineering and design have to work together so closely because we are serving both groups at the same time as a product.

Um, I know that, you know, often in conversations, um, with designers, a topic that comes up is, you know, working with engineering and being kind of accountable for understanding technical concepts, the constraints of the platform that you're working with, things like that, um, so that we can ensure that both of those things are kind of matching up. Um, but I'm interested if there's a similar conversation in software engineering about a shared vocabulary with design and what that looks like?

Matvei: You want to go first, Connie?

Connie: (laughs)

Liam: (laughs)

Connie: I think it's d- a different experience for me and my team because we're so close to a design product than perhaps for you or, um, someone who's on a consumer or business-product focus team. So for me and my team, I think we perhaps were attracted to Material Design because we are, have an affinity for creativity and design. And so I think it's a constant give and take, where we are interested in, you know, being involved early on in the design process.

But we understand that or we try to understand that while it's important for our design counterparts to be aware of the technical constraints, um, sometimes it's could also be hampering, um, because I think just like you push us to figure out how to create and build the tools. Or, you know, create effects that currently do not exist, um, we also don't want to already put boundaries up to prevent you from, you know, thinking beyond what is currently available.

Um, I will say that one of the things that my team has been focused on is to educate new designers who come into the organization who maybe not as familiar, um, with how, especially like the release and lifecycle of a library. And how long that can be, especially for something like Android that has a very long, um, long adoption tail. Um, so we are currently in conversations with our design counterparts to figure out, how do we, not only explain it in terms that an engineer would understand, um, but also, in terms a designer would understand?

So for example, we've tried, in addition to explaining, "Here's our res- re- release cycle. What kind of changes can go into each and why it's important to, for various reasons like user trust, or accessibility, or whatever else?" Um, we try to give concrete examples of, you know, if you wanted to change this aspect of the design system or if you wanted to introduce this new feature. Uh, we don't want to say, "No."

What we're saying ... What we're trying to, um, I guess get to is a common ground, a common ground of understanding of how can we fulfill your amazing vision, but at the same time, make sure that our existing products, and users, and potential new users will see us as a, um, added benefit, instead of an unpredictable churn in their main focus, right, to, to create something worthwhile for their team or users? I hope that sort of (laughs) answers your question.

Liam: Yeah, yeah, totally.

Matvei: I'll try to take a little bit of a different then s- spin on the same question, uh, a little bit 'cause I've been y- um, a big advocate for a designer too, uh, engineer kind of, you know, relationship between design and engineering. I always thought about it as one of the most important alliances I have to make and maintain while working, especially like in the, in the fields where you develop application. Um, when you can, create application for users.

Uh, I feel like it kind of usually building this relationship with design, sharing the same vocabulary, explaining them how I think while, while I'm making their designs happen, and understanding how they think. And like what are they gonna, uh, what all, all the user journeys they want to cover and why is it so important? Uh, makes my job easier and also actually more creative 'cause I can suggest something, right? It's not like, "Here is design. Go make it." It's more like, "Hey, this is the button and it is there because we want to put more attention."

And, uh, and I know. I can, um, I can say and suggest maybe, "Oh, you know what? In our platform, IOS or Android or, and what, uh, and whatnot, there is tool to make it even more, to bring even more attention for some reason. I don't know. We can just kind of add a circle." So it's kind of more, it becomes a conversation. It becomes a creative brainstorm together with, with the developer, between developers and designers. And I think, I think it's like the whole, uh, engineering, the whole like IT industry, we can do so much more, to be honest, uh, in, in, in this regard, kind of talk more, uh, between the engineering, uh, so that would be very, very nice for everyone involved.

Liam: Just to follow up on that briefly, I want to ask, are there things that you wish more design practitioners knew or practiced in that regard?

Matvei: Is this the place where, um, where I say, you know, i- if, uh, if designers that design, for example, m- m- m- m- mobile applications for a particular pl- platform know the platform guidelines and capabilities? I think that usually helps a lot. I mean, I think r- right now, it's mostly the standard, right, um, that kind of everyone kind of more or less aware of what's happening. Um, but I think, I think that, that's a thing we can always use more from the applications, right?

Liam: Yeah.

Matvei: I'm saying, "Okay, this goes for Android because of this and that. This is not possible. This is possible." Um, usually goes a long way.

Connie: One of the things that I noticed, especially with the designers from the Android Org is that oftentimes they'll use the library and use some coding projects. And sometimes even to, um, livestream code-alongs. And I find it to be, uh, always a rewarding experience to watch and see someone who is not, um, primarily in my discipline use the product, especially someone who is a colleague or, you know, is from the field of the, um, person who designed it.

So I think in this particular case, it's a designer using a UI library. But I think it would be, uh, equally interesting just for, you know, uh, like a teacher, to interview a teacher, if this is my previous team to ask, "Oh, how would you create a product to solve this problem that we, you know, to ... How would you surface this feature from a different perspective?" Uh, someone who maybe is not biased based on all the, you know, learnings and, and, uh, best practices of our fields to come at it from a fresh eye.

Um, so, yeah. To circle back, I think it's not a requirement, but certainly we strongly encourage, I think our designer and counterparts to play around with our library or product and, you know, review our documentation 'cause I think sometimes we make assumptions of what people know and do not know 'cause we are steeped in it every day. And it's, um, you know, usually people have very good insights, uh, when they don't make the same assumptions as, um, oftentimes it leads to a better product for everyone involved.

Liam: Yeah. I think, um, going back to something you said earlier, Connie, something else that I'm really interested in across disciplines is recognizing either a piece of work or a body of work as being complete, or finished, or at a good point for, for being considered finished for now, which is often the best we can hope for. I think as you talked about like the lifecycle of something like a library, the release cycles and so on, um, that your discipline may or may not have a more clear answer to this. But (laughs) I'm curious, with the library, with software engineering, is there a way that you can tell that the code is, um, is complete?

Connie: In my experience, there is different definitions to complete. I, I, I think that in order to be a good steward of a product that our users will actually trust, we have a very high bar for, you know, always being backwards compatible and not causing binary incompatibility, not, um, basically abusing or, you know, losing our user's trust. But at the same time, I think with both design and, um, software engineering there's never really ... It's never really like completely done.

It's this is, um, you know, for this version, which I want to, um, target either for, you know, uh, a big public conference or because I think it's important that we have regular updates with fixes and performance improvements. And all the other, um, maybe not as, um, flashy, but very important, uh, work that make my product dependable. Um, I think there's the, there's the question of, "Is it ready for this regular cadence to be released?" And then there's the, "Is this completely done?"

I think that probably it's n- it's never completely done. It's either we're moving on to another major version or, um, we have a new release. But I think it's very important too, for the sake of, you know, the, both the developer and the user audience to not get into a, um, scope-creep situation where because, you know, new ideas and new information always comes up that we hold off releasing, you know, uh, uh, a stable version of the library because our users also have their own deadlines.

And they're also waiting for, you know, whatever changes, or fixes, or futures that we've decided to include. So, um, I think the question maybe is, is this, is the, is the library or is the design system at a place where we're ready for, um, you know, a preview or a general audience to get feedback? And then, be honest about, "Okay, we're gonna make changes, so we're going to be clear that this is a, you know, either minor or major revision based upon like delta from the previous one."

I think we often try to be very intentional about why we change things, but sometimes that doesn't matter because it is still a disruptive change for that, uh, you know, user or developer on the receiving end. And it's unwanted because they didn't opt into it, or they weren't informed, or they thought that there was a different contract of trust between you and them when they decided to use your product.

Liam: Yeah. This goes back also to the idea of kind of the, the boundaries between or within design and engineering in the sense that, you know, we were talking earlier about, um, technical feasibility and trying not to set up unnecessary boundaries around what can be done. Um, but I'm curious like how the boundaries are set up right now, and where they might be set up in the future? Like how do you, how do you make that decision early enough in the process that, that something is, is kind of worth investing this creative energy in or not?

Matvei: Uh, coming from the kind of, uh, if you don't talk, uh, about the material as, uh, as a design library. I'm kind of talking more widely about the whole framework development. I think trying to set as, uh, fewer boundaries as possible, um, is usually a good thing, right? And I think we kind of see this, um, well, you, you, you compose, you, you know, like this new model UI toolkit. We've seen a very big breakthrough even with them, with the creativity that, uh, developers found out, now unlocked them.

Like h- having, um, them having access to basically no restrictions, good tools, good APIs, makes their head explode with ideas. Like developers are free to explore, um, but again, it's more, it's more about the lower-level APIs and kind of engineering work we are doing. Uh, maybe material, in material we try to set a little boundaries a little bit, uh, a little bit more, right, because we're trying to be more opinionated about, uh, what material is and kind of how material application looks like. So I think the answer there is like boundaries are necessary, but I think we're still, we're flawed with them all the time, right? So we're, we're trying to shift it here and there, and adjust as needed.

Liam: Just to close, I'm also always interested in asking about the future. I'm curious how you each see the future of code as a creative medium and the relationship that we've spent a lot of time talking about between code and visual design?

Matvei: I feel like the more we go towards the future of kind of like, you know, programming languages, um, tools, and stuff like that, I f- I feel like the future l- uh, looks bright (laughs) in g- um, in a sense that the creative part is actually what will stay in my opinion. I, uh, I think we have to make a lot of things. We makes, we make a lot of routine, like routinely made operations and calls. And, um, general chores easy for the other person, users, and everyone else involved.

But there is still this need to build mental castles. So complicated logic, um, make it appear on-screen later on. You know, push this change that kind of makes things happen. Um, this is, this is not going anywhere anytime soon, I imagine. So in that sense, I'm very, I'm very hopeful 'cause the juicy bit stays with me and then, you know, the other things I'm lazy to do will be, will be automated at some point.

Connie: I agree with Matvei, and I look forward to that future. I think we've already seen throughout the relatively short history of software engineering that it, uh, you know, at first it was fairly inaccessible both in terms of hardware and I think education. And over time, it's become, you know, much more democratized. It's easily accessible. It brings people together. Um, I think it's one of those disciplines where regardless of age, or geography, or your background, access is available, especially if you can get online, which I hope most people can.

And, you know, things like Android are open-source and largely affordable. And we try to provide tool- tooling that, um, like we spoke about before, that facilitates whatever problems they need to solve. And so I'm looking forward to more sort of design through coding. So I think some things I already saw in school are things like data visualization.

I think conveying information that maybe traditionally do not bring the word, you know, visual or design to mind. And through I guess the ac- the, the increased access that is now available, um, through either, you know, someone manually coding or li- as Matvei is saying, more and more of these automations that we can, um, make discoveries and also consume information in, um, ways that are not as, uh, easily discoverable before.

Liam: Thanks. I think that's a great vision to close on. Thank you again, uh, both of you for joining me today.

Matvei: Thank you.

Connie: Thank you very much.