#165 Grace Jansen on bees and reactive systems
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Grace Jansen 0:00
So cool. Such a cool use of using biology as a inspiration. Because, you know, biology has had literally millennia of evolving to get this right to get it as efficient as possible. So of course, we should be looking at them
Tim Bourguignon 0:22
Hello and welcome to developer's journey, the podcast, bringing you the making of stories of successful software developers. To help you on your upcoming journey. I'm your host team building your own this episode 165. I receive grace Johnson. Grace is a developer advocate at IBM working with open liberty and reactive technologies. She has been with IBM since graduating from Exeter University with a degree in biology. And she enjoys using her knowledge in biological systems to simplify complex software patterns and architecture. And I have to tell us about that. She is an international speaker, and the co author of the book reactive systems explained published by O'Reilly. Grace, welcome to the afternoon.
Grace Jansen 1:07
Thank you so much for having me. I'm excited to join you.
Tim Bourguignon 1:10
Yes, I'm excited to hear the story and about biology we're gonna have we're gonna have to come on. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up. If you would like to join this fine crew, and help me spend more time on finding phenomenal guests, then editing audio tracks, please go to our website, Dev journey dot info, and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guest. So Grace, first thing first, as you know, the show exists to help listeners understand what your story look like, and then imagine how to shape their own story. So let's go back to your beginnings. Where would you place the start of your dev journey,
Grace Jansen 2:09
I would probably have to say the start of my dev journey was actually when I was about 13 years old. So when I was 13, my mum who's our primary school teacher, went to IBM, she took her class on a school trip to IBM, little kids. And she went and she came back after the school trip and said, grace, your love it. They work with computers all day, they don't wear suits, it's very casual, you're gonna love it there. So she ended up encouraging me to actually email them and ask them for some work experience. And this was the first time I'd come across any kind of coding. So I'd never done any coding before that. And in this two weeks of work experience, I got to try. I think it was three different languages. I got to interact with IBM errs, and I essentially fell in love with computing. Following that, unfortunately, just at the time I went through school, and the particular school I went to, I didn't get the opportunity to do coding as something you learn at school. So it was mostly just in my free time, I was sort of dabbling around with like, how do you build a website, just sort of fulfilling my curiosity, trying to think you know, how would I go about doing this, I quite like doing websites and sort of in school, I tried to pick up on any opportunity I could to get hands on with it. So I ended up doing a robotics competition. When I was about 16, where I was coding this robot, we've made it look like Wally from Disney. And we coded it in Python. And we were entering into this competition, where we had to pick up boxes with with QR codes on them. So we had to do visual recognition and things like that. So it was a really cool start to my developer journey. And then it sort of took this twist towards biology, which sounds a little random. So at uni, I was like, Do you know what I enjoy doing coding is a passion. And I will always continue to do coding as a passion. You know, I've managed it throughout school, I'll continue doing it. And I said, I'd like to see. My other passion was biology. And I was like, You know what I'd like to learn more about biology. See, if it's a career path, I'd like to go down and then determine from there after my degree, what do I want to do with my life? What do I want to become? So I went to uni, I studied fish, which isn't particularly technology related, and I have to say hasn't come into my job that much. So yeah, sort of a lot about fish. I studied sort of biological systems all the way from microbes up to sort of macro evolutionary, evolutionary concepts. And it was super interesting. I really enjoyed it. But it was in my, I think, second year university where we had this module where they were like, This is a module you can choose if you'd like to, and it was run by a computer scientist. So it's like, Oh, sounds intriguing. So I looked into this module and it was all about simulate Seeing biological, like issues or problems or scenarios on a computer through programming was like, oh my god says combining my love of biology and my love of coding. So yeah, I immediately signed up for that module and just fell in love. I ended up coding, I started off quite simple, you know, coding, Pac Man coding battleships, that sort of thing. And then worked my way up. And I actually did my dissertation with this professor. And I was actually, ironically, now simulating viral spread through airlines, which is sort of ironic, given the situation we've been in, you know, it was interesting. And I really, really loved the coding aspect of it. So at that point, I made the decision, like I finished my biology degree and said, I've loved it, I would absolutely have loved to have become the next David Attenborough. But that was never going to be because I just decided, You know what coding is for me, I would love to go down the software dev route. So at that point, I took another U turn, and went back to software development and applied for a job at IBM, I actually did a summer internship during my second and third year at uni. So I joined IBM is extreme blue program, which is their summer internship program. I did I think I learned five or six languages in about three weeks, not particularly well, but enough to get by. So yeah, I basically dabbled in things like I'd never used JavaScript before. I was dabbling in Java. I was dabbling in loads of different languages. So it was really good fun. And then afterwards, join them in their grad scheme. And that's where I picked up developer advocacy, which is what I do now. So wow, yeah, it took a lot of turns. But it was definitely an interesting journey.
Tim Bourguignon 6:43
So let's go back all the way to the beginning. You said, your mom came back from this trip into the work with computers. That's what that's going to be for you? How did she know?
Grace Jansen 6:52
So we had when I was younger, I remember one of the best gifts we got for Christmas. And I say we I have two siblings. And often the larger gifts for my family were for everyone. So we got sort of joint gifts. And this joint grift that Santa Claus had brought us for Christmas was this new computer, we'd never had a computer in our house before. And it was this, you know, big white box is huge machine. And I just absolutely fell in love. I did all my homework on it from school, my dad had to kick me off it when he was trying to do his work for work. Like stop playing on the computer, you know, playing around with just Word or PowerPoint or whatever, I was just having a great time. So even though it wasn't particularly technical, as soon as we had that sort of access to that technology in our household, I was hooked. And my mom knew it. I absolutely loved playing around with it.
Tim Bourguignon 7:40
So that was your your vector for creativity and explore curiosity
Grace Jansen 7:45
because I have absolutely no artistic ability whatsoever. And the computer gave that to me. This computer allowed me to make my you know, my homework, my projects, visually appealing, with photos and images. And I went ballistic with all sorts of fonts, but it was great fun. I feel Yeah.
Tim Bourguignon 8:10
When you went through biology and discovered this simulation path, first of all, did the well known virology simulation Pac Man Did it come to your mind as an idea to continue in this? Combining these two these two fields instead of going to IBM? Absolutely.
Grace Jansen 8:27
My professor approached me during my presentation and said, Look, would you fancy doing this as a PhD? And it was it was tempting, I thought about the offer? Because I did find it really interesting. But when I was doing my, my dissertation, so bear in mind, I was using Python to create this program. Bear in mind that I'd had no formal training. My Python wasn't exactly best practice. So I just for me, I thought about, you know, would I want to go through essentially creating this sort of mixture of sort of Python that I just sort of learned on the go and wasn't necessarily the best it could be. And I knew that I actually would rather get some sort of more formalized skill building and training to be able to then utilize that. So I ended up turning it down. Because a I was sort of fed up with the whole writing reports, academia, that sort of thing. And be I wanted some more formal training. I wanted to get that opportunity to learn from others who are skilled in software development in software craftsmanship, and have experience in the real world actually using it for projects and clients. So that's why I chose to go down the sort of job route at IBM rather than continue with my study.
Tim Bourguignon 9:50
How was this this transition from using computer science for biology? And then using computer science for its own sake Stay with us. We'll be
Tim Bourguignon 10:01
right back. Hello imposters, if you work in tech want to work in tech or are tech curious in any way you'll want to listen to this. We've launched a community of professionals who come together to share information and advice about jobs, roles, careers, and the journeys we all take throughout our lives as the designers, builders, fixers, investigators, explainers, and protectors of the world's technology. We call it the impostor syndrome network. And all are welcome. So find the impostor syndrome network, podcast, wherever you listen to find podcasts, and look for the iOS and community on your favorite social platform, hashtag imposter network.
Grace Jansen 10:44
It was interesting, because using it for biology, especially with what I was creating, I was creating a simulation that I could just run on my laptop around fairly quickly, I could see the results immediately. And I was like, oh, no, that's pretty cool. Whereas moving into, I would say, especially enterprise software, you're moving into this realm of an area in which it's very hard sometimes to conceptualize where you fit in this huge network of software developers clients. And also, it's often hard to conceptualize the software itself, because you might not necessarily be the one using that to build something that you could interact with directly. And you might not see the clients who are using it and understand how you contributed and what that means. So I think on a personal level, it required a lot for me to understand and get my head around, moving to this more enterprise were working and understanding where he fit in that. And then on a skills level, understanding that I didn't have to know everything, and I didn't have to be involved in everything, you know, understanding there are lots within the enterprise world that I will not know. And that's why I worked with colleagues because they knew, and it was sort of accepting that and being able to hone in on a particular area or a particular aspect of that enterprise software development to think, yeah, this is what I'm going to be good at. This is where I'm going to specialize and bring value.
Tim Bourguignon 12:10
Do you still? Do you still fight with that?
Grace Jansen 12:13
Yes. Oh, yes, absolutely. I have a massively curious mind. And so I think a lot of software developers do. So as soon as you see something new, you're like, oh, nice and shiny. Yeah. I think I still fight with that a bit in terms of, you know, you want to know everything about everything, because that's what curious minds want to know. But it's limiting yourself and understanding that you can bring value with just a small aspect, especially when things are so large and that sense. And I think being able to the project I was doing at university was very individually run. So it's just me working on it, being able to share that with my colleagues is lovely. Being able to rely on them and be able to help them in return in my particular area of expertise, is, I think, a great benefit that I've gained from moving towards this direction of my career.
Tim Bourguignon 13:03
How did you? Or do you pick and choose what to get into and where to focus your curiosity, and definitely not that one or that one?
Grace Jansen 13:13
That's interesting. And it's changed, right? It's changed as I've moved through my career. So at the start, clearly, I had a very steep learning curve. Moving from, you know, I done a bit of JavaScript a bit of Python, and then moved into this object orientated world of programming, which I had no idea existed, and moving into Java, which I had not used before that. So I had a very steep learning curve. So the first, maybe one or two years of my career, I spent mostly just trying to understand the basics of, Okay, what does my department do? And what am I involved in, you know, understanding the basics of how computing, especially cloud computing worked in terms of like, I've never come across a virtual machine before or a container or things like hypervisors, I just didn't have that basic understanding that a lot of computer science students get within their degree. So I spent a lot of my time, especially in my free time actually, organizing, like lessons with some of the senior developers, organizing study groups was some of the other grad intakes, you didn't come from a traditional computer science background, and just investigating and doing courses. So that was a lot of my time, just just getting up to speed really on on the key technologies and the key components I needed to understand and know, from there, I essentially just sort of thought I, I looked around and thought, right, where is my product going? Where is this particular part of this industry going, looked at some of the newer sort of concepts and methodologies that are that were coming out and thought, oh, that that sounds interesting. That might be where my product would be interested in going forward in the future, where I'm interested in looking forward for the future and sort of clung on to that and went deep. So that was, for me reactive systems. And when I joined IBM, it was sort of just coming to become popular within the sort of enterprise Java world. And so I just deep dive into it, read everything I could on it did some courses. I, you know, stayed late after work, I did it during my lunch break, just because it was interesting. And I wanted to know more. So ended up actually going quite deep into it. There wasn't necessarily anyone else in the, in my department who had. So all of a sudden, I'd gone from getting up to speed to suddenly being the person who knew about it. That was quite a scary transition. Yeah.
Tim Bourguignon 15:40
Before we go deeper, can you briefly describe or define reactive?
Grace Jansen 15:45
Yeah, of course. Yeah. So reactive systems is we say systems because it's looking at the entire system as a whole. So your application and the components within it, whether they be functions, or microservices or microservices, whatever, but also the components that it interacts with in sort of the cloud environment, if it's in a cloud environment, or in any other environment you have it in. So it's looking at that system as a whole, all of those components interacting, and the reactive part of that name is talking about being as reactive as possible. So when we look at definition of reactive, it tends to be like, no matter where, what context it's in, it's about responding to events or to stimulus. So I might react to my hand being on a hot stove, I'm going to take my hand away, obviously. So in an application sort of world, we're looking at, can we respond to events to state changes within applications, and keep that responsiveness throughout the application for every client using it. So it's based on four key behaviors and characteristics. So it's about having asynchronous communication. So really enabling that complete separation and isolation of components within your system. It's about having scalability and elasticity. So being able to elastically scale up and down your resources. So if you have an increase in load to your system, you can increase those resources to deal with that. But also, if you then have a decrease in load, so you're in a quiet period, you're not wasting money with resources, you don't need to be able to scale that back down. Again, it's about resiliency. So being able to be resilient in the face of potential failures, gracefully handling those failures, and being able to keep your system responsive, which is the last behavior. So really being able to respond to those events. So it's those four key characteristics being built into every pot every layer of our application. Really, that's what reactive is all about.
Tim Bourguignon 17:37
And now I start to see the pennant to to biology, you can start to see the link. Yes. Before we get to that, you said you spent two years getting up to speed. And I've seen this countless times already. But one thing that is quite often linked to that is feeling bad of not being at the level you think people expect you to be. Yeah. Imposter syndrome, right? Kind of imposter syndrome. Yes. Yeah. How did you find that?
Grace Jansen 18:09
It was difficult, I think at first i overcompensated. So I did a couple of things. One of my over compensations was to absolutely bury myself in extra reading, which I would not recommend to anyone extra reading is fantastic. But take a break, please, you sent me so much information, you can absorb it once and I dried too much. And it just doesn't go in, right, you need to take it steady, you know, do as much as you can. And I would really encourage people to because there are some fantastic resources that are freely available online. And that can really help you to build those skills that you might need going forward. The other overcompensation I did was, which I would recommend, to a certain extent, just not as much as I did, which was to get involved in voluntary projects. At IBM, we have some really cool initiatives, whether that be for women in tech, whether that be getting kids interested in STEM, whether that be helping out someone else in the labs, who has a project on the side that they're interested in getting some help with. So I basically just flung myself into about 12 Different Voluntary Product projects. And yeah, I absolutely I had a ball, I absolutely loved them. And I learned a lot as I went. So on some of them, I was doing project management on some of them, I was leading teams to skills that I was absolutely not going to get in the next few years through my current role, because I just wasn't at that technical level. But it was skills that I knew would be really important going forward and that I could use in any role I had. So it was nice to go in and do a project that wasn't necessarily requiring particularly technical skills from me, but that I could bring other skills too, like my communication skills or my team leading skills or teamwork skills. So I think for me that really helped me to have some comfort in in work and having a project that I could be involved in that I found important and that I could bring skills to that I didn't feel I was, you know, the the worst in the group, so to say, and that helped to give me that sort of, I guess escapism from the whole, you're the one who knows, at least in the team. And then gradually over time, that volunteering became less and less, because I was getting more and more responsibility in my role. So that balance sort of started to occur. For me, where I was selective, I was being quite selective with the voluntary projects, I was getting involved in selecting those that particularly interested me, or would gain me new skills that I didn't have. And then focusing more of my time on actually giving value back now that I was, as I set up, more up to speed with the skills that I needed, how did
Tim Bourguignon 20:39
your team helped you, during this, this, this transition phase, during this this ramp up phase, maybe they
Grace Jansen 20:45
were extremely understanding, I am so lucky to have such lovely people that I work with, I would say one of the biggest contributing factors to me being able to make that transition. And also just joining the organization with that sort of fear that I didn't have the necessary technical skills was definitely mentorship, my mentors have been incredible. And they're the ones who helped me to realize, I guess, the opportunity and the skills that I bring that I hadn't quite appreciated before, that perhaps other people didn't just because I wasn't from a technical background. So I had I mean, I am a particularly curious person, I think, also for devs generally are, but I think where I differ from perhaps others is just I asked a lot of why's, which I didn't realize before, and one of the product managers had around him. And he was like you ask good questions. So I feel like it's just why all the time. Yeah, being able to question the sort of traditional way of doing things, or perhaps a particular technology they've used and just helping to make them justify it so that they make it clear in their heads. And that was a skill that I brought to the team and I hadn't quite realized. So my mentors helped me to realize that and my mentors were the ones who helped me to transition. And they were the ones who sort of really gave me the confidence that I did know what I was doing that I did have those necessary skills and that I could take on that responsibility. And they're the ones most of the time who pushed me saying, Yeah, go for the promotion or go for that opportunity. Or, yeah, I think you can do that. Why not? And it was definitely without them. I think I would still be very deep in a book somewhere trying to perfect a skill. But yeah, I would definitely say mentors. huge help. For me.
Tim Bourguignon 22:31
We are our own worst critics. Oh, absolutely. Which is under downloading. Yeah, we're criticizing ourselves, way more than anywhere, any other person in the world? Absolutely mentor to get out of it. Or you mentor yourself?
Grace Jansen 22:46
Yes, yeah, I actually mentor a lot of the people who come in as grads who don't come from a computer science background. So when I first joined IBM, I'm sure a lot of people who are part of st larger organizations, who are perhaps quite established or maybe are just more, I guess, maybe business See, I don't know, we tend to have a lot of acronyms in our business. I swear too many acronyms sometimes. So I actually ended up one of my voluntary projects was just for myself mostly, but then I figured it would be helpful for others, making a dictionary of acronyms that we use within my particular organization, and explaining what they were. So just little things because when I first joined scrum was like speaking Latin, I'm saying half the words that were coming out their mouth. So being able to contribute that to grads going forward so that they're more comfortable, and they can look up a word without having to perhaps ask a question that might make them feel silly or stupid when you know it's not but that might make them feel that way to being able to contribute that I've contributed that to the grads and they get given that when they first join, and the I mentor a couple of grads through where they want to go in their career, as well as helping them with other skills because a lot of them come in very technical, far more technical than I was, but perhaps want to expand on some of their softer skills that they don't have that I perhaps had coming from that alternative background especially with things like communication eminence externally and working towards perhaps team leadership roles. Yeah, I mentor mostly career paths for a couple of the sort of grads that come in it's really fun and rewarding I love it.
Tim Bourguignon 24:28
It is it is when you look back on your your story so far. You forget all about the projects that we're seeing you see faces you see faces of that person and that person and that person and that one you helped and that will help you in cetera Absolutely. I have the feeling it's more and more true the further yet
Grace Jansen 24:44
I swear I feel more proud when they get what they like what they particularly wanted then then anything that I ever wanted, because you just feel like oh, I really made a difference for that person and it makes you feel so good inside. So I absolutely love it.
Tim Bourguignon 24:58
Nothing heavy. Let's tear back the discussion toward toward biology. In the bio I read you mentioned, I stole it from somewhere. You mentioned that you're using your knowledge of biological systems to simplify complex software patterns and architectures. Yeah. Can you talk about a bit about that? Well,
Grace Jansen 25:17
I make it sound so huge. So I guess it kind of all started with reactive. So being a developer advocate, obviously, part of my role is to well, almost all my role is to help developers use technologies to make it easier for them, maybe that's through a video tutorial, maybe it's through a presentation, maybe it's through to written article or tutorial. And where I was struggling was, especially with presentations at conferences was I was this fairly new developer, I've been there for maybe two, three years, you know, I've been developing for that long prior to that I came from this rogue biology background. And I was quite a young person, I joined the company at like, 21. So in my head, I was like, why on earth? would someone want to come and hear me speak, when they can come and hear someone who's been working with the language more than I've been alive? As clearly, they're gonna know more than me. So I basically went back and said, and it took a lot of self reflection for me to understand, okay, what could I possibly bring to the table that can help a developer that is only something I could bring, that really helps me to utilize my particular skill set. And so at that point, I thought, you know, what, I have my biology background, maybe this can help people. And also, I love telling stories, as you've probably guessed. So I was like, How can I combine biology with storytelling to be able to help developers? So when I moved into the world of reactive, you know, as I said, I was one of the first people within organizations who really took note of it, who went deep into it. And I thought, okay, how could I help explain this sort of what can be conceived to be this complex architecture style, and really simplify that down to something that people can really take a grasp of, and really conceptually see, because as I said, that's one of the key problems I think we face in software development, especially enterprise is that conceptually, sometimes it can be harder to grasp, because it's not physically there. You're not touching an iPad, or whatever. I was thinking, okay, what can I relate it to, perhaps in biology, to be able to provide that physical component that people can relate to and understand? And remember, don't ask me why. But immediately, I was like, Do you know what reactive systems are like bees, that's what they're like. So I love for you to say, right, I'm just gonna, I'm just gonna combine bees and the social behavior of bees with microservices and reactive systems. And it sort of worked. It sort of went from there. So yeah, I was basically comparing things like the individual microservices, to the individual bees, but the actual application that they make up to the bee hive system, so the fact that all of these individual bees that have their own purpose and their own role within the hive, they might just so many different types of bees. So I found this out in my research afterwards, you can be a caretaker bit, you can be an air conditioning me, I thought that was a cool one. Yeah, who knew? But didn't they circulate air on the hive, which makes complete sense says, Okay, it's really cool. You should read it into bees, I promise. It's very exciting. So yeah, it was basically just comparing, you know, all of them have individual roles, they have an individual purpose. And yet, they work towards that greater good of making the high function just like an microservice does for an application. And it was all about, you know, we talked in reactive systems about this elasticity, for example, this elasticity of being able to scale up our resources depending on where the load is. So in bees, actually, it's amazing if, for example, a predator attacks the hive, at any one time, only about 12% of the hive, I think it's 12% might have gotten that wrong, but double check me, our guard bees, so small percentage, a guard bees, but obviously, if it's a large bear, you're gonna have trouble getting that bear to leave you alone with only a small percentage of bees. So what they do is actually go back into the hive, and they send out a communication to the other bees, asking them to temporarily switch roles. So all of these other roles that the bees play, so nurseries, caretaker bees, air conditioning bees, they switch temporarily to become God bees to deal with that load. And then afterwards, they switch back. So it's the fact that they already have this elasticity built in to their system. And it's being able to, as I said, provide this conceptual model that we want to be following by using something that people can actually physically see and imagine. So that's what I was trying to do with my analogies. And I sort of continued expanding outwards, just not just these other things to do And I've continued to try to do that.
Tim Bourguignon 30:02
Did you experience the other way around saying something in BS and say, Oh, that will be cool if we had that in a way totally. That's this concept
Grace Jansen 30:10
absolute literally. So I was watching when I was younger, I watched a lot of David Attenborough, as I've already said, love, love him love his documentaries. And one of them was looking at complex behavior within social colonies. So bees are one of them. But also things like ants, and I was watching about ants have this amazing ability to like order themselves, for example, in terms of they know, regardless of sort of what happens to it, they have this system, this really efficient system, where the answers that are coming back with heavy loads on are able to take the shortest path to their to their base, because they have already figured out what the shortest path is. And they're able to follow the answer in front of them. And they have the system where they're going round in a loop, essentially. So the ants that don't have load, take a longer journey around the outside, and the answer, have a load, take the shorter journey back into the base to make it more efficient. They were able to figure this out as a site if that was amazing. And I was looking at these different, like ant colonies and their behaviors. And then I actually realized that we've actually got AI algorithms that do similar things, and they're literally cool. They're named after ants. Like, that's amazing. So, and things like, there's been some research recently where I don't know if you've seen it around chips for computers. And they've been looking at completely redesigning chips based on the neuron structure in our brains. Again, so cool. Such a cool use of using biology as an as a inspiration. Because, you know, biology has had literally millennia of evolving to get this right to get it as efficient as possible. So of course, we should be looking at them.
Tim Bourguignon 31:49
How do you balance both sides of your heart biology and so geeky into biology into into computer science
Grace Jansen 31:57
already. I guess for me, it's a case of, I don't feel like it ever have to choose one over the other. And that's the great part of my job is the fact that I get to utilize both. And I think I bring a bit of both to both parties, if that makes sense. So I use my biology knowledge in software to help developers. And you know, I used to, we used to have this fun game back when I first joined IBM, and they were saying how rogue my skill set was in my knowledge of fish. So every week, I do a little fish quiz. And I teach them about fish. So just little things like that bringing in something different, right, and being able to use my skills in a different way. And then on the other side, being able, like I did in my degree to bring the software back and be able to utilize it for biology. So I feel like my experience has allowed me to delve into both, which I've been quite lucky with. And I think the reason I'm able to still do that is because I deliberately make an effort to deliberately make an effort to to make those analogies to utilize my skill set in that way. Sometimes it's hard to get me wrong, because I love geeking out of both, you just have to know your audience. So knowing who's interested in what when to stop and just don't make my like developer lectures or presentations too much of a biology lesson.
Tim Bourguignon 33:13
Limiting is is good. Yeah, too much.
Grace Jansen 33:17
So quantities, yeah.
Tim Bourguignon 33:21
Do you see yourself geeking out further into reactive and and biology and bees? And for for years to come? What do you see your picture your future?
Grace Jansen 33:31
So I guess for me, the bees lasted about a year or so I have to say I did enjoy it. And then I decided actually, you know what other analogies can I use. So more recently, I've been looking into comparing, and I've done a couple of presentations and videos around comparing two cloud technologies with our human anatomy. So looking at, okay, a container is kind of like a sell the idea of containers is to wrap up a particular component within our application or a particular application, and be able to wrap it up in a way that provides easy replication enables it to move easily enable us to sort of be able to say Duplicate it if we need to. It's the same with cells. When you look at the cell in our body, a cell is easily transported, because your DNA isn't just like wandering around your body, which is quite useful. And you can easily replicate it. So when we're working out, our muscles are able to expand because they're able to easily duplicate and replicate those cells. Because it's a it's the same instructions, right? We're just able to utilize that container image again, comparing human anatomy to cloud computing. So that was an interesting one. And I delved into things like the central nervous system and how that relates to things like sto and proxies. And that was super interesting. So I've tried to move away from just B's and look at what other analogies I can use to explain other areas within sort of enterprise software development and cloud native applications. So that's where I'm at currently. I think going forward, I don't see myself losing analogies, because they helped me, I'm a very visual person. And so I need a visual analogy. And so they sort of naturally come to me because I need that that visual link, especially when things are so conceptual, a lot of the time. So I think I will continue to do that, because I just really enjoy it. And it's how I learn. And so I know that it might help other people, too.
Tim Bourguignon 35:28
So what's the end goal for you? Is it to you so that everyone knew, I think granos, scaling elasticity resiliency, and was the last one responsiveness, they all have that imprinted in the mind, and they think about it some, from time to time? Do you want to dig into this deeper and become the world expert, if you're not bad reactive systems, and really advanced the state of the art and this, what's your, your, the angle you're shooting for?
Grace Jansen 35:54
So I think since I started talking about it back in, what 2018, I think it was, or 2019, it's become a lot more popular. So there are many, many more people talking about it at conferences, blogging about it, using it within their own architecture and their own applications. So for me, that's a fantastic step forward in terms of, as you say, more developers actually considering it. A lot of developers asked, you know, is reactive, something everyone should be using? And it's a complicated answer, because sometimes reactive can result in it requires sometimes a lot of effort to be able to implement that in your application, especially if you're aiming for reactive and that asynchronous behavior from end to end across your entire application, that can take quite a lot of effort, quite a lot of sort of rethinking is this sort of paradigm or shift in the way we think about how we're designing and building our applications? So a lot of the time they asked this question, you know, is that effort and that energy, and that those resources worthwhile spending to be able to make this move. And I think, for me, the characteristics and the concepts associated with reactive are almost separate to actually implementing reactive itself. So a lot of there's a lot of libraries and tools out there that claim or do allow applications to sort of become more reactive and, and they help with that. But I would say that, regardless of what your application is, what it does, who it's made, for, how big it is, where it's held, I think every single application out there can benefit from at least one of those reactive characteristics and behaviors. And if we're able to get that those behaviors into people's heads through reactive, then fantastic, that's a great step forward. Because even if they are only able to change a small part of their application, but somehow they make it more resilient, or somehow they make it more asynchronous, or somehow they make it more able to scale easily, or more elastic, just that one small change can make a big difference. So I'd say no matter how much energy or time you have, how limited that may be, I think there are always improvements that you could make by looking at those key characteristics in reactive doesn't necessarily have to be you're using a reactive framework, or toolkit or library, it can just be implementing some of those characteristics and behaviors. And I think you will see an improvement that way, even if it is just small. So that's why I'd love I'd love for people to take that on and improve their applications, because they saw a presentation or a video I did and thought, yeah, you know what, I can implement some of that?
Tim Bourguignon 38:26
Is it something anyone can do with any kind of project?
Grace Jansen 38:29
I think so absolutely. I think in terms of so reactive in general can be really helpful. If you have, say, a large application, and you've got loads of people using it, and you need it to be up all the time, then you need all of those behaviors, because you need it to be resilient because you can't go down, you need it to be elastic, because you've got you might have a huge number of users using all at once need it to be responsive, because, you know, society nowadays expects our applications to be like at the click of a button. I'd say that is why companies like Netflix, for example, are great use cases for reactive. However, not everyone is as large as Netflix, not everyone has an application as complex as Netflix. So I would say that, you know, if you are one of those smaller applications, if you don't have tons of clients, if you don't have the need for it to always be up, then you might not necessarily need all of them. But I'd say that every application needs at least will could could value and improve from at least one of them. So if for example, I'm building, I one point, I was building a website to host my family photos, so I could share them with my extended family. In that case, it doesn't matter if it goes down. It's just for my family, they don't care. So in that case, it probably doesn't matter if I don't have the most particularly robust or resilient behaviors built into my application. Although I might get an angry on the phone. In that case, you know, I could benefit from more resiliency, but perhaps I don't have the energy or the effort or the resources to spend on that. However, maybe I'm able to access them quicker. provide them a better service, if I can have more asynchronicity within that, so I'm not using REST calls all the time. And I'm not creating synchronous blocking. So, in that case, you know, although I don't necessarily need elasticity, because I've not got huge numbers of users, I could benefit from at least one of those behaviors. And I think that's where I want people to focus, can they implement those behaviors in some way or another into their application to help make a better experience for their clients and end users and a better development process for them? Because maybe they're, they don't have to deal with as many outages at 2am in the morning, which would be fantastic. Yeah, no one wants that. Nobody wants that.
Tim Bourguignon 40:39
Where would you send people that heard that term on this show half an hour ago, for the first time and say, Okay, that sounds interesting. Where should I? Where should I go to start with this.
Grace Jansen 40:49
So the reactive manifesto is a good place to start. So the manifesto was essentially, the creation of it was created back in 2013, I think was the first one. And it lists out those key characteristics and why they're important. So that's a great place to start. If you want sort of an overview, I, you said it in my bio, I've written a short book, and it's free. So if you want to go check that out, that's only it's only small, it's like 30 pages, or something. So quite easy to skim through. And that book, which is reactive systems explained, that one is essentially just an overview of what reactive systems are, why you'd want to use them and how you might go about using them. So it's sort of quite a nice intro into that. Apart from that, you can go and check out some of the specific reactive tools and technologies. So you might want to check out vertex, for example, microprofile, reactive messaging, you might want to check out if you're interested in spring, for example, they have spring web flux, you might want to check out project reactor or even Akka, if you're interested in actor based frameworks. So there are quite a few. And if you go to, I've written an article, which basically goes through a lot of them on IBM developers website, so if you just search my name, Bruce Johnson on IBM developer, you'll see a lot of my reactive material there, where I go through various different concepts in more detail.
Tim Bourguignon 42:04
One question I asked him, Do you remember where you heard it from react for the first time? Oh, good question,
Grace Jansen 42:09
do you not I think it was actually because one of my teammates happened to mention it. And I just latched on. I was like, What is this? And then they started explaining it. And I was like, well do this, I'm not explaining it. Like, I was just fantastic new methodology, when we're thinking about like, resiliency, and like, elasticity and scaling. I was like, I'm sorry, I thought that was, they all seem quite obvious to me. And a lot of people will say, totally, a lot of people when I start talking about reactive, they're like, Yeah, we do this. But I think I think the benefit of reactive as a as a methodology is just putting a label to it, being able to say, like, I'm striving for a reactive system, having that label, and being part of that community of people working towards that goal just helps to enable you to be able to use these open source libraries and frameworks, and to put a name to what you're trying to achieve within your organization rather than just in the back of your head or was knowing that you were trying to make a resilient system. That's what I think people gain from that label.
Tim Bourguignon 43:07
But yeah, start the conversation. Yeah, exactly.
Grace Jansen 43:10
So the conversation and be able to have that common language, which is another great benefit. For
Tim Bourguignon 43:15
the advice. I want to scroll back all the way and ask you a question that when you were starting to realize that you during your studies, you had this biology you were following, and you had discovered the simulation part. There was probably a time where he said, Well, I could go in both direction. Yeah. What is the advice you would give someone who's feeling being in some kind of similar situation and interest can decide what would be the advice you would give them?
Grace Jansen 43:39
I would say for me, it almost goes all the way back to when I started with my developer's journey. You know, when I first got to IBM, I first got to try programming, and I loved it. And I thought, when I was choosing my degree, for example, I thought, Do I, which route Do I go down? It felt like this huge weight on me thinking, you know, does this determine my future? Does this basically at the age of 16, determine what I'm going to do for the rest of my life. And it felt massive, this huge decision. And actually, I think the best piece of advice I can give someone is, it's okay to choose and then change your mind. I think that's the best piece of advice I can give. I chose biology, and then changed my mind. And then I thought, You know what, no, this isn't what I do want to do for a career, I've got a great skill set, I've learned a fantastic amount of knowledge, and I can apply that somewhere else. So don't feel like when you're making what might appear to be a huge decision, that it's the only you know, once you've chosen that decision, it is the only path you can go down. You must continue on this path of career development. It's not the case, use the skills that you're building in that career path or in that particular role. With that particular decision. You might have made gain skills from it and then learn how you might be able to apply it if you want to change and change is always possible. I think that's the great thing about our industry is there is no right or wrong way to or right or wrong path when Trying to get to a certain position a certain skill set a certain area or even company, it's about being able to apply skills that you've learned being able to sort of self reflect and think about what's best for you and what you want. And yeah, I'd say when you're making those decisions, don't beat yourself up too much. Because you can always change your mind later.
Tim Bourguignon 45:20
I agree fully. And then after 160 Something episodes, I can say, do the most interesting stories when you started something and then say, well, that's not necessarily for me, you revere and do some, some something else. But at some point, you combine these two knowledges into something else. And when you make the most of those two careers or two path, that's where magic happens. Totally, as you described in less. Awesome, thank you. Thank you very much. Where can our listeners find you online and start a discussion about fish definitely don't fish,
Grace Jansen 45:56
we all want to know. You can find me on Twitter. So my handle is at Grace Johnson 27. Or you can find me on LinkedIn. My name is Grace Johnson. I'm the I will say developer advocate at IBM in the UK. So you should be able to find there was another person called Grace Johnson, IBM, she works in Singapore. So just don't get us confused. That's the only thing. But yeah, LinkedIn and Twitter probably the best team.
Tim Bourguignon 46:18
The other one might be less reactive. Yes, reactive yet
Grace Jansen 46:21
probably just as willing to talk about fish, but
Tim Bourguignon 46:27
anything on your plate coming up in the next month that you want to plug in. So I've got a couple
Grace Jansen 46:30
of conferences coming up. So if you see a conference, I'll be speaking out, I'm doing a bit more around analogies. So as I said, human anatomy, cloud computing, so if any of those topics interests, you, feel free to come along to those, you can find most of them. If you head to my IBM developer profile. Most of the conferences I attend, the you're able to sort of sign up to are listed in the events section there. So come and join if you fancy it.
Tim Bourguignon 46:55
Awesome. And we'll link all that to the show notes so you can find it easier. Thank you very much. It's been a blast. Thanks for having me. And this has been another episode of developer's journey, and we'll see each other next week. Bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you like the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms to show appears on on our website, Dev journey dot info slash subscribe. Creating the show every week takes a lot of time, energy, and of course money. Will you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate. And finally don't hesitate to reach out and tell me how this week story is shaping your future. You can find me on Twitter at @timothep ti m o th e p or per email info at Dev journey dot info. Talk to you soon.