The Place of Creativity in the Tech Industry - Part 1

Samuel: 0:00

Creativity is about solving problems in interesting and innovative ways. There's like obviously there's the traditional sense of creativity with artists and painters and stuff, and people might be tempted to not think of software developers as a very, uh, creative role. But I, I tend to disagree quite a lot, actually. I think, uh, writing software is one of the most creative things that I've done in my entire life. The set of constraint kind of determines which direction you can go, but it doesn't really change how creative you can be, right? You can just it's just that the set of options that you can explore are different. And so, uh, the, the things that you can do with such a huge codebase, with so many people relying on it, are sometimes more limited, but also, uh, they have much more impact.

Nicolas: 0:47

Creativity in development when you work in a big company is actually not only, the. Yeah, the workflow. Exactly. That you have the process and the communication with others.

Olivier: 1:03

Hi everyone, and welcome to this new episode of Planet Odoo. Today we decided to offer you the rebroadcasting of a live from our Twitch channel. In the live series Odoo Unplugged, we had a great conversation about creativity in the tech industry, and we think this might interest you. This time you'll be able to hear the first part of our conversation. Ready? Let's go. Hi everyone and welcome to this first episode of Odoo Unplugged. I am Olivier Colson. I will be the host. Uh, today I'm a developer at Odoo. I'm part of R&D. I work in accounting team and my specialty is really the reports. Uh, but I'm not alone today because we have a very interesting subject to discuss, actually. So we're going to talk about creativity in the world of the industry. And with me are the among the finest members of our R&D. Don't laugh. Self-proclaimed, self-proclaimed. Of course. Uh, otherwise it's not fun. Uh uh. So maybe it's time to introduce you guys. Uh, I suggest you you give a few words about yourself. So, who are you? What's your name? How long have you been there? And what is your. I would say your your your pet baby. Your pet project in Odoo. So, Samuel, you go first.

Samuel: 2:12

Yeah. So I'm Sam. I've been working at Odoo since 2019. Um, and I've been a part of the JavaScript framework team since 2021. Uh, and as part of my work on that team, I've been working on OWL, and more specifically, I was one of the main driving forces behind the new reactivity system in OWL2.

Géry: 2:30

The reactivity system, not the creativity system.

Samuel: 2:32

Yeah, unfortunately, I can't really just write the creativity system, but, uh,

Olivier: 2:38

Maybe someday.

Samuel: 2:38

We'll get the creativity system today.

Olivier: 2:41

If you're creative enough, you never know. Uh, talking about OWL Géry. Hi.

Géry: 2:45

Yes, hello, I'm Géry Debongnie. Uh, I've been working on the web framework team for ten years now, and I'm very happy to have convinced, uh, Anthony to start working on a new framework. Uh, after five years, that was, that what became OWL. So, yeah, you could say that OWL is kind of my baby project.

Olivier: 3:07

And today all of Odoo, uh, uses it.

Géry: 3:09

Yeah. Uh, OWL the base JavaScript framework, base system that we use to do for

Olivier: 3:16

And last but not least, Nicolas.

Nicolas: 3:18

Yeah. So my name is Nicolas Bayet, I'm working, uh, at Odoo for about five I'm always comparing different kind of technologies, frameworks and try to come up with new ideas to, to make it, uh, to make the tech stack even better. So, yeah, that's about it.

Géry: 3:35

And you have your own framework as well?

Nicolas: 3:37

Yes, I have a visual framework to, to make it a fast to, to create interfaces.

Olivier: 3:42

Okay. So let's get started on the subject now, uh, creativity. What are we going to talk about exactly. How would you define that? First, I think it's really important because, well, people have to have an idea what we're talking about. Right. So how would you define that in the in the professional world. What what is that. Because it is something important for a developer, right?

Samuel: 4:01

Yeah. I think creativity is about solving problems in interesting and innovative

Géry: 4:08

And useful ways.

Samuel: 4:09

Yeah. I guess uh, there's like obviously there's the traditional sense of Uh, and people might be tempted to not think of software developers as a very, uh, creative role, but I, I tend to disagree quite a lot, actually. I think, uh, writing software is one of the most creative things that I've done in my entire life.

Olivier: 4:32

I think it's very true. Uh, a lot of people, actually, for Non-developers, uh uh, it's not obvious that you need to be creative for that job, because a lot of people just see the, the, the job as, uh, being in front of a computer and doing crazy math stuff, which is, is not at all what we're doing. Right?

Géry: 4:50

Yeah. I think it's a challenge when I try to explain my job, uh, to my friends

Olivier: 4:56

I gave up a long time ago.

Géry: 4:58

Yeah, I kind of give up. I try to stay quite vague. I usually have to, uh. But, uh, they always think of me as working on my, uh, computer and just writing code, but without, like, a, like a machine, you know? And that's not really, uh, the reality of, uh, the day to day job.

Olivier: 5:17

And how would you describe the reality of the day to day job? Hahaha.

Géry: 5:21

It's a challenge I told you. Uh, yeah, yeah.

Olivier: 5:25

We have an audience of experts here. Come on. It's all right.

Géry: 5:28

It's. It's hard to describe. It's, uh, it's a mix of, uh, talking to people, of understanding problems, of reading code and sometimes writing code, but, uh, even, even then, it's, uh, sometimes you are writing, uh, you're, you're trying to solve a problem. And that's I think that's what the topic of this, uh, this session is about. Uh, but sometimes you have to, you know, how to solve the problem. You have to do it yourself as well. So it's there is no really no one way to to describe, uh, our, our day to day life.

Nicolas: 6:00

And it's always different every time when we come to work, we have different And we also have to tap into different kind of creativity, creativity to be useful and sometimes creativity to kind of explore things. We don't know yet if it's going to have, uh, some usefulness in the future, but we explore and then, uh, sometimes we just need to to make the job work, but we also need to to be creative in the process of deliverable development. So yeah, creativity is very broad.

Olivier: 6:29

Of course there is the R in research and development in R&D and well you need to So to try something that is hopefully interesting, but you don't know and you need to try and you will need to adapt it while doing it. And maybe at some point it will it will be groundbreaking, but you don't know when you start. You might have an idea, but you don't know it. Uh, I have a, a pretty funny way to to to explain what, what development is to to non-developers that I, that I like actually because it's a bit, uh, it's a bit of poetry like that. Uh, it's essentially development and just programming in general. I like to say that it's like the, the magic that mankind invented, uh, because, come on, you have a bunch of people, uh, knowing, like, formulas and ways of, of writing weird things that they, they are the only ones to understand, to produce some effects in the real world. There is one word for that. And it's magic. Definitely. And like for any kind of magic, you need to have this kind of guys, you know, with. Just imagine a wizard, okay? The, the the Baldur's Gate wizard, you know, the typical Dungeons and Dragons things. Uh, well, this is a creative profile. Okay. That's a, that's a guy that that, that will that will be a bit weird, that will talk a lot and so on. So this is definitely the kind of guy that is interesting, uh, in programming as well, I think.

Géry: 7:55

So you're saying writing software is like casting a spell or something?

Samuel: 7:58

Yeah. I mean, it is you're literally writing arcane incantations and you don't Uh, symbols. And I think, like, it's also not just the wizard inside the universe of Dungeons and Dragons, but it's also very much like playing Dungeons and Dragons. Sometimes you just you have some tools that are in your toolkit. You know what spells you have and you're trying to find interesting ways to use them. And I think it's also very much the case for software development. You have these concepts that you had to learn, and these seem like very, uh, boring concepts. And then depending on the problem that you're trying to solve and how you are chaining these concepts together, you can get a very interesting result, like, uh, with spells in Dungeons and Dragons sometimes, like that's the entire point, right? You're creating an interesting scenario. And in software you're using building blocks to create an interesting solution that solves the problem and gets to your goal.

Olivier: 8:49

Mhm, mhm. And that brings us actually to the like the, the, the biggest part I drive uh creativity. And I think we can start with unless you have something to say.

Géry: 9:02

I wanted to come back to the, to your video game, uh, idea as you were talking software. Another aspect of that is, like building stuff. So it's more to me. It's more, maybe more like a building game where you try to make a complex system, uh, out of basic ideas. So to combine them together. Uh, yeah. I think there is like a very intellectually interesting, uh, attraction to, to build stuff. We like building stuff.

Olivier: 9:33

And indeed. So, uh, it goes very, very well with, with what I was going to say, One big element that will actually build your creativity from a programming perspective at least, is when you're learning already. So you both talked about the the basic building blocks and the concepts that you learn at university, at school, or in books or on the internet or whatever. You don't need to go to school to learn that. Uh, it's, you know, the moment where you learn them and you start being like, hmm, I could use that to do something for for Dungeons and Dragons. Why not? Uh, that's something a lot of people do, actually. Uh, or for for some, some, some other purpose you have in your life next to, uh, studies, next to all that for some personal projects. And I think that's where things start to, to get interesting, because that's the moment where you start inventing things. And I think it's really part of the process for, I think any developer actually.

Géry: 10:29

Maybe any creative activity, uh, I think there is a drive to make something, uh, what, uh, pushes us to, to do something. We like it.

Olivier: 10:45

And then you start working. Uh, and is it something that I think it's something that can disappear? Uh, right. Not maybe not disappear entirely, but it's something that, you know, you have a the environment is not the same anymore. And you let's let's say you're less free than before. You have to spend time working on something that maybe you don't really that much care about. Uh, what would be then the, the, the, the elements that would keep you creative in such a context. Haha. Good question.

Samuel: 11:18

Kind of stumped there. Um, I think there's a lot of things that that can keep you creative, but mostly just the problems themselves. They keep you creative because you have to solve them. And obviously if you have to solve them, they're not already solved. You have to find something. So there is this iterative process where you're tasked with something, you have a problem to solve, and then you have to try various things. Some things you already know will work or won't work, depending on your experience. So that's one of the things in your toolkit. Uh, and then the rest, you have to just try them. Also talk with the people whose problem you're solving to make sure that what you're doing actually solves their problem. Um, so yeah, I guess there's like the constraints to me are a big driver of creativity, right? If you have, uh, the, the world as your options, then you don't really know where to go. And sometimes just having some, some sense of direction, it really propels you forward. And it lets you know, uh, it lets you just really let the rubber hit the road. Right.

Olivier: 12:18

Mhm. Because indeed, uh, in, in your first projects, that's something that will different directions at the same time. And essentially it goes nowhere. And you learn that I think after doing that a few times, you're like, okay, I need to stay reasonable and just put constraints on myself.

Géry: 12:37

Uh, on the other way, if you have too many constraints, uh, then it's the And you just cannot solve a problem if, if you're told how to solve the problem. Yeah, well, you can do it, but it's not a creative, uh, activity if you are, if you just have to, to write, uh, to, to to develop that feature in that specific way. And you are already constrained so much by the framework and by maybe your manager or something, then, uh, it's not really, uh, so creative anymore.

Olivier: 13:05

So is it not, then...

Géry: 13:06

It's like a balance.

Nicolas: 13:07

And I think there is also the, uh, we have to choose wisely the set of constraint when we if we have a deadline, then we will focus on maybe the most essential things for reaching that deadline, which will drive us just to do the necessary work to, to make it, uh, reach the deadline. But on the other way, if we don't have a deadline, it lets us it lets us explore, uh, the ground and allow us to. Yeah, to to find new, new ways to, to develop it. So yeah, it's just about the time constraints. So finding just the right set and exploring different set of constraints can be useful. So it's an art in and of itself to, to know what what should be the constraint here.

Géry: 13:58

I think the time constraint is very important as well. Uh, you need I think in many cases you need a constraint. Maybe not a hard line like like a before, uh, an important release. You need you need code to work. But still, it's very important to, to to have that sense of progression.

Olivier: 14:16

And I think what you said was, was very interesting, uh, because indeed the, the So maybe there is a time question on the time constraint. Uh, uh, and the fact that sometimes you may be a little more free to, to just take the time to do something properly. And that's sometimes. Okay. You need indeed to have this, this like this timer, this okay. This needs to be ready for that moment. If I take the example in Odoo, uh, we have the release every year, which is basically always the deadline. Uh, it's it's really, really rare that we have something that we spend months working on before the release and that is not released for this release, and that will need to wait for the year after that. Uh, it can happen for very, very, very, uh, complex stuff, but usually it's not the case at all. And I think, uh, it it's a good thing, actually, because it forces you at some point to be like, okay, maybe I should just prioritize, uh, and do this first, that, that, that second, and maybe leave some room to improve that in future versions. But I think getting a result is also important because it's it's rewarding. And so if you don't get any reward for creating things, do you still create as much?

Géry: 15:30

But now this is more specific to software development. But...

Olivier: 15:34

I think it's true for every field.

Géry: 15:35

Yeah. No, that was true. Uh, we're talking about release schedule. And, uh, this is, uh, important to have uh, some quick feedback as well. So when you release, uh, some project and people start using it, they will, uh, discover a lot of features, a lot of, uh, business flaws, a lot of bugs that you would not expect. They would do something in a very creative way also, and not necessarily positive and don't mean that as a positive, but still, uh, you need that feedback to iterate. And I think that's really a for software and maybe for everything else. For software you need that, uh, iterate, uh, iterating process.

Olivier: 16:14

Yeah. Because it adds challenge. Uh, sometimes, uh, really hard constraints as well, because there is something buggy or something, you know, uh, you have something that is working in, but you discover that it's only working well in 80% of the cases. And, uh, and for the 20 other percent, it's not just not working, it's doing something wrong. Then you have to fix it. And sometimes it's not that it's not that obvious. It's not always just adding a comma somewhere or, I don't know, uh, it might be just reworking a whole part of the mechanism to make that thing work and fit the need. Uh, but I think it's also something that will bring you to, to to new ideas. And maybe in the future, it will also make you realize, okay, uh, we did we modeled that this way, but actually, we we should have gone for this other option. And let's redo everything to do it like that. Uh, so maybe bugs also then are a source of inspiration, uh. Somewhere.

Géry: 17:03

But that's true. You need to solve, to fix, uh, in a proper way for the proper So if in a stable release, you need to find a way to hook your, your bug fix in the proper way without breaking, uh, the system, uh, without any breaking change, because the rest of the, uh, the software ecosystem may use your system. And if you change something, it will break. Of course. So. But of course, this is not the correct way usually. So you need to find a way to do it properly in a stable release and in master release. You can, uh, do it in a proper way if you find the one.

Olivier: 17:39

And it's something we face a lot to do. Right? Because we have this very modular, uh, architecture and we have the community using our software and so on. And so even if we ourselves know that we could change this function and totally replace it with someone, something else, because basically it's called in only two places. And it's very simple. You're never sure that it wasn't used by some partners somewhere to do something that was correct with it, but that relied on the thing you're trying to fix and that you will not essentially break his software.

Géry: 18:11

Uh, talking about constraints, we talked about time constraints. Now this is more like a constraint for, uh, a system such as Odoo, which is a like a platform for applications. So we have like many layers of, of code that builds on the bottom layers, and they need to be stable in a way.

Olivier: 18:29

And does it add something for the for, I mean, the codebase itself and the size Does it add something also to to to creative options you might get, or is it more like something that is restraining you?

Samuel: 18:41

So I think as I was saying earlier, uh, the set of constraint kind of determines be. Right? You can just it's just that the set of options that you can explore are different. And so, uh, the, the things that you can do with such a huge codebase, with so many people relying on it, are sometimes more limited, but also, uh, they have much more impact. Right? Because you're changing a little bit of the code that that might be a small turn in some somebody's side. But when you have thousands and thousands of other developers relying on your code, then maybe, uh, it's really worth the effort doing it. Uh, and I think that's one of the main drivers behind the, behind OWL right. When you're working with a small team and a small codebase, having this the previous system that we had before with the widgets and this very imperative API, um, it's kind of manageable when you're working on small projects. And then as we're growing, it becomes harder and harder to understand how all of the code is interacting with one another, because we have, um, modules that are patching, modifying widgets in place to, to make their behavior different with some module installed. Um, and then we also have these widgets that are becoming bigger and bigger, and it's becoming harder and harder to keep all of the state of the, the widget inside of your, your head. And so that's one of the main driving forces behind. Well, we need something that's more declarative, that lets you just think about the state. And the UI is just handled automatically. And so it's kind of a it's one of the main reasons why we even think that it was necessary to rewrite the framework. Whereas I'm pretty sure if Odoo was still a 15 person company, then this idea would have never even been allowed to bloom.

Olivier: 20:28

Mhm. Mhm.

Géry: 20:29

Yeah. It has a cost of course. Uh, and it depends on the size of the project. So I would argue in a way that if you have a larger codebase, I guess, uh, maybe if you work on some subsystem that is well isolated from the rest, you can easily, uh, change it, modify it, update it, fix it, understand it. But when you're working on a, on a, on a framework layer that, that the rest of the application, uh, builds upon, uh, you, you need to be careful. And a larger code size means that, uh, it takes a lot of effort, and we need to be careful about changing it. So, uh, I think some large software companies use, uh, code mods and, uh, and system to automatically update part of the codebase when they need to change. And it's a, it's a challenge. So yeah, you can be creative, but it's still, uh, you feel the weight of the codebase on you.

Olivier: 21:23

On the other hand, uh, the fact that you have this, this, this whole codebase think it's also an incentive for yourself, you know, tell to yourself, okay, they're doing that. They're doing that. They're doing that. We need to do something as well. Uh, you know, it's it's a matter of, I don't know, pride. Uh, uh, and just, you know, you you're in the, in this, this atmosphere that brings you to, to to to propose new ideas and to make big changes, uh, uh, as well. I think it's important as well.

Samuel: 21:57

Yeah. Another thing that goes with the size of the codebase, I think Géry Uh, when the size of the codebase is sufficiently big, then now you have a reason to build good tools to work with the large size of the codebase. Whereas when you have a small codebase, just the need just isn't there, right? So there are new problems that come and that you have to solve. And that's also a creative process. And just realizing that, uh, a lot of people are relying on, uh, a bad system and that you might need some tooling to deal with it then now you have a new problem to solve, and you can be creative about it and solve it in an interesting way and make everybody's life easier. Also, going back on the on the framework side, uh, of things. So when you're making really a framework and you want to to change everything and, well, it will impact everyone and you need to be careful. I think that's also and that's also something that Non-developers might forget actually about the job, because there is creativity to be expressed in the way you you will organize the development. So not in the development itself, but for this kind of thing, you need to find a way to update the codebase without breaking everything and without forgetting things and communicate on that as well. Uh, it's a it's.

Géry: 23:10

Really a challenge in itself. So I think I want to comment on that, uh, about the transition to OWL. So basically we have I don't I'm not sure about the size like more than one 100,000 lines of code. We add 100 lines of code, more than that, uh, on JavaScript codebase. And we want we had to change that to update that to, to use OWL, our new framework. And it's a it's a big change. It's not really uh, it's even worse than going from a modern framework to another modern framework where you have like a kind of the same ideas, the same, uh, declarative system. Now, uh, moving from the widget system to OWL was moving from an imperative system to a declarative one, and it basically means rewriting the complete codebase. And so it took it took us, I think, three years, uh, to, to do that. Uh, and it was really a big challenge, not only for our team, but for, uh, other teams as well. So it was a communication challenge. We had to coordinate with other teams to update some parts of the of the codebase. Uh, we had to make it. We had no choice but to make it, uh, in multiple steps. We cannot have, uh, like a big pull request that we maintain for three years and then merge it. That's not possible. Uh, we have more than 200 developers or even more than that working on the codebase, uh, while we were working on it. And so really, we were converting some code. And at the same time, you have hundreds of developers adding new code in the OWL system. So how do you manage that? Uh, so for, for this case, we had to imagine a way to write, uh, all components into, uh, into widgets and the other way around. And then we try to convert some part of it. And then we decided that we had to do the other way around. We converted the web client and then the rest. And we we had to to find a lot of ways to, to make it work. So it's really it creates additional complexity. We had to have in, in your mind, the previous codebase, the new codebase and all the intermediary system that all the layers that make them communicate properly. And it's really a really big deal. Uh.

Nicolas: 25:25

Yeah. And, uh, creativity in development when you work in a big company is the software that you create, but also the workflow, the. Yeah, the workflow that you have, the process and the communication with others. And, uh, that's something very specific with companies. And the bigger it is, the bigger the challenges. And I think for beginner developers, uh, we don't realize when we, when we start how much time we will spend just to, just to, to figure out what is the, the proper workflow and also how to communicate with, uh, with the colleagues. And it's always changing because we're always new task. When we finish one, we have a new challenge, and it's a new kind of, uh, things to think about.

Olivier: 26:12

And it can become really hard because, uh, also my personal example is the But we had this kind of problems as well. Uh, uh, and, you know, you you're doing your thing. You have something that works on every case that you checked. Cool. And then you check the cases that you haven't checked yet and you realize that it will not work. Uh, so, uh, we had that a lot. And, um, I think, uh, uh, a big thing, uh, for, for, for, for. When you're doing some kind of of big technical change like that. It's also the contact with, uh, like your management because I think in every company it's normal. At some, at some point someone is going to ask you, what are you doing? And, uh, and, and when you're on something that big, uh, it might be a bit complex to communicate on that. Also, you have to, to, to teach it to people while you're working on it. Uh, and that is also a big challenge because, you know, you have people using basically what you're doing to create new things that will come just after yours or at the same time, uh, but they need to learn to use the thing that you haven't yet finished to design. Uh, and so that is also also a big challenge. So maybe on these points, uh, do you have, like, personal anecdotes, maybe, uh, about that or what does it inspire you?

Géry: 27:37

Uh, and I want to say that, uh, yeah. To come back to what you said, like at the beginning, uh, where people think about, uh, developing as, like, being on a computer and and writing code. Yes, of course, that's that's what you said. Uh, at some point, it's not it's no longer true. We need to communicate, to teach, to, to explain to, to to ask for feedback. And I can tell, uh, for my team, we had a lot of challenges in the last, uh, previous years. Um, and I think the problem is that since we work at, uh, at, uh, framework layer, everything, everyone is impacted by our code. And when we, uh, do some change, it's it kind of comes as we are imposing our change to the rest of Odoo. And if you don't, uh, if you just write code and then ask everyone to convert their code to your codebase, uh, it will not come. It will not be so friendly. And you had a lot of hostility at some point, uh, on Odoo internally. And I think one of the main, uh, solution to that problem was to basically to talk to each other. So we ask we have like some, some official channels where we can ask for feedback. And, uh, I try to explain to him what I was trying to do and to ask if what, what their feelings about that were. And usually, uh, the tone was much more, much, much more friendlier, much more productive. So there is like that, uh, communication, uh, diplomacy skills that you need. And everyone needs to, uh, to understand that we are not working on just our small codebase. We are working in a larger ecosystem, and we need to work with each other.

Nicolas: 29:24

Especially when we are creating new things when, uh, because the the more new friction because it's a new system. And so they. When your communication is really...

Olivier: 29:38

When you're changing something, actually fundamentally changing something And so everybody is thinking in terms of the old system. And so, uh, you're, you're the one responsible to change it and say, okay, we don't do that anymore. Now it's totally different. But then you need to convince people that or at least explain them why it's better, and at least that it's not worse than before.

Géry: 29:58

And maybe for for them for their use case. It's not. It's not even better. Maybe we we change something to to improve the life of 80% of our developers. And in some rare cases, it maybe it's worse. I don't know, it could happen. And for their use case, it's maybe it's it's more difficult to accept that we change. Uh, something.

Olivier: 30:20

Indeed. Indeed. Uh, and I think it's a perfect time to do a little break. Uh, now, actually. So we'll be back in, like, five minutes. And, uh, I've seen we had a question in the in the chat, and I think it will be interesting to answer it in the, in the second part of this discussion. So see you in a few minutes. And that's a wrap for today's episode. This first part interest you to listen to the second part. Be there next week as we'll post the rest of the conversation in which we answer some of our viewers questions. If you want to join us live next time, don't hesitate to follow us on Twitch to receive the notification of our next programs. The link is in the description, and if you're in the mood for more captivating content, I highly recommend checking out our other episodes. Until next time. Cheers!