Developer Experience is a Team Effort at Liberty Mutual

Episode 163 · 40:37 · SRT · archive.org · all Tanzu Talk

all right folks welcome back for another episode of the newly renamed tanzu talk or tanzu tack if you choose to pronounce it that way uh that might be a bit of a stretch we're going to go with tanzu talk for now this is dormaine draywitz and with me today i have a trio of guests all hailing from uh liberty mutual and they bring a uh a set of perspectives thrice perspectives i don't know i i'm committed to trying to use thrice at some point in this podcast in a grammatically correct way i don't think i hit the grammatically correct part so far um so let's do some quick interrupt introductions before we dive into the topic du jour uh kevin why don't you go ahead and kick us off sure um i am kevin ingvalson kind of as described i guess relative to this talk i have been playing platform operator for i think about the last half of a decade or so um before that i've also impersonated database administrators system administrators and uh overall application developer extraordinaire i'm a data modeler um i you know i i i'm the one that's usually on the team that's the the sucker that when everyone else takes a step backward i wasn't paying attention and there i am so here i am yes okay well we appreciate all of your past impersonations um and always interesting to see someone who who's got a database admin background uh showing up on our calls um next up we have miranda leblanc do you want to give us a quick intro sure so i started um with liberty back as an intern and then came in through a rotational program where i worked out on the business side doing all the training to be an insurance agent but came back to the it side and worked in a number of different roles like business analysis and eventually found my way into more software development and found

my passion there uh worked as a developer for a number of years joined our secure devops platforms team and on that team have worked as a developer a product owner an engineering manager and now back to more of a developer role so run the gamut of different types of jobs within it yes indeed that's uh that's like i can imagine your linkedin resume is like where there's you know you have to expand that would you like to see more um and let's keep going just try things out yeah great well-rounded view to bring to tonsu talk all right last up we have matt rule um and correct me if i'm pronouncing your last name incorrectly no that's exactly right it's matt rule and um currently by title i'm a security architect i'm uh aligned with our with our developer experience teams have jumped around a bit at liberty in terms of roles but um the one common thread is that i'm always a developer always developer at heart i've been doing that for as long as i can remember so i've kind of made it my mission in life to uh sort of speak for the developers focus on developer advocacy and trying to make the best experience possible past few years i fell into a bit of a security niche just kind of uh i guess it started out being my biggest uh hindrance in life and it and i just kind of fell on it fell in love with solving all things around security and so sort of i wake up thinking about being you know combining this role of of developer advocate with um with being a security architect so that's kind of my mission in life at the moment and trying to make trying to make life easier for our development community and that that's a great way to kind of tee up our topic which is really around developer experience and and so you know matt you you you set up this mission that you've been on to make the developer lives better but maybe we can kind of hear from everyone about why does developer experience

matter why is it important and you know both from a technical perspective and as well as maybe how you see this connect back to the business anyone can go ahead and jump in but i'm going to look at matt first because you kind of set that one up i think a lot of what we want to solve as a business is really around agility and getting value to production to our customers hands as quickly as possible and that really sits on top of i mean that really that really centers around our ability to improve our software delivery life cycles and get and produce software faster gets take something from idea all the way to a production environment as quickly as possible and obviously that revolves around providing an ultimate you know positive developer experience removing points of friction removing inhibitors and making it not only possible to get things to move at speed but also make it an enjoyable delightful experience for our developers to be able to do that so it really is sort of one of the the cornerstones of of being able to solve our the our objectives overall as a business miranda what would you add to that given you've spent a lot of time as a developer yourself yeah so my biggest passion right now is about developer education and matt and i actually spoke about this at SpringOne platform um is that it's just as important to build out a unique and intuitive experience for your developers with your tools and platforms but it's also important that um developers understand the technology behind what they're using to build their business value so that's where a lot of my focus has been on partnering with different teams across our organization and doing different events to try to have immersive education experiences where people can actually go and try out our tools and platforms and get something up and running and deployed out into the cloud within a matter of minutes and then be able to see it it makes it real for those teams and then they can start

to think okay how can i start using these tools and how can i start um solving these business problems faster yeah i think solving solving business problems faster is really kind of what it comes down to if if you're on the business side trying to understand like why would we invest in developer experience hopefully that that gets you an answer kevin like let's just take a slightly different tack on this question um because something that i i sometimes notice um for folks who you know as a someone in platform ops and platform engineering um there's sort of this emerging uh kind of class of folks uh that are you know you might call them cloud architects and they may have more of a systems admin background such as yourself um but but sometimes i'll hear them talking about how it's like yeah i want to go i don't want to use some commercial storage offering i want to write my own storage thing and it just it just is one of those things where it's like okay i get it you're you're sort of you have um a lot of like strong infrastructure chops but you also kind of twitch a little bit like i want to write a script for that i want to i want to use the apis and i want to i want to build stuff but sometimes i see it aimed towards something like i'm going to reinvent the wheel on uh you know storage interface sort of feels like you're you're taking your great talents and not really applying them to the right problem so just curious from your perspective as someone who's um kind of in that that type of role with that kind of background why do you see developer experience as important and and maybe how it would compare to you know being able to use kind of your your skills to redesign some clever way of using infrastructure well that's more more a lot of words in one question um yeah i mean it's i guess it does have to i mean kind of like man said i am i am

still a developer at heart and soul out of all of those things that i've done before but i'm also one other thing i i am lazy um so like what you had described uh when you have the ability to use some sort of socialized system um you know whether it's a i need to store a file i don't need to write a file storage system um there's a couple obvious ones that come to mind nfs is not one of them um so hooking things in there it just kind of makes it makes sense i mean the the stuff that we do day in and day out there's there's stuff you hide in the back room but the better you use um something that's been socialized something that shared something that makes sense less time you spend diagnosing and working in those kind of things the stuff i love because my i guess the part where i still get to play developer the most is because we also are the intake for issues um so what will happen is you know i'll get fun things like i'll get a person that worked with that you know she's now here's the same title that we're working on diagnosing pool connections inside of an application because you take the beauty and power of spring and then the way it does the http calls and all that other stuff and then you put that in an enterprise and you get something that's closing off your connections you get to have a fun deep conversation on how do i find which library is actually has the bad pool connections that some of my connections aren't closing correctly so the retry isn't working inside of my application because you get these discoveries of where teams have used the stuff they've used bringing the other stuff to its power where they they use simple code but then you take the enterprise stuff that adds potentially different layers and it's like how do you help how do you help to find them and then the bigger challenge kind of what we're talking about here today how do we take it when we learn that how do we make that available to everyone else because i'd rather talk about that stuff on something like this as opposed to have to have that same conversation again with the next person who ran into that same problem i don't have a real good answer that one but i think that's why we're here today is it's you talk about this stuff you share it you try to figure out how to get to

people those experiences yeah there's there's a common theme there i guess of not wanting to have to redo something right and that includes not needing to reinvent the wheel if there's a file storage system that already exists that'll solve it but also you know once you've solved a problem and and dug it and understand it how do you make that repeatable for um everyone else you don't have to repeat yourself so um let's kind of then then dive in a little bit more to you know now that we understand why the developer experience matters what what are some things that you've each seen from your your respective perspectives that actually move the needle because there's a lot of things that you know probably sound like oh that'd be cool and developers would be happier more productive and um you know we'd get things out faster somehow but what in your experience if you had to kind of pick what was the top thing that you said wow this is what really moved the needle for our developers and we'll we'll rotate back around so kevin let's start with you okay um i'll i guess i'll start with something quite simple start with working um don't don't start with um oh i have hello world when you check your code out of your repository um you better be able to fire it up and have functioning code if you didn't commit it to your source repository in that state and you can't actually deploy it to your environments in that state fix that because that no developer wants to have to start off with oh crap i don't even know if this is the right code that seems like a good place to start yeah because once you have something working then we can talk about all the other great things like you know we can argue do you start with the test first you start with the code first as long as you walk along the beach that's great but if you didn't start from working you're standing and not doing much of anything all right how about you miranda um so the biggest thing for me or that i've seen moving the needle is just putting

the power into developers hands through self-service so whatever you know going through and mapping that value stream of what does it take to go from an idea to working software and mapping along that stream and just trying to find what are the manual handoffs where developers need to ask someone else to do the work and what can we do to automate those um so that's kind of just a huge theme i've seen over the years the more that we can get into our customers hands and our customers are the developers and the faster we've seen adoption the faster we've seen growth um the more we've seen people really understanding the tools because they're getting in and diving in and kind of doing it themselves and taking that ownership and is that something like that value stream mapping process is that kind of a one and done or do you have to continuously come back to reassess what the current value stream is for your developers yeah that's a continual reassessment and matt actually is phenomenal at doing that and he does that every day with customers um i kind of come in at more of the problems and helping customers troubleshoot their issues once they're in our platform he's out there trying to find what are the next blockers to solve so all right so matt uh you've been teed up as the expert in the value stream mapping process but if you were to step back how would you what would you look at as um you've clearly done this a number of times are there any patterns that have emerged for you in terms of what's what moves the needle the most yeah well i was going to talk all about value stream mapping and automation and developer empowerment but you know miranda kind of beat me to the punch there since you went in reverse order yeah you know there's i can build off of that though right so we we talk about i i remember days

when we had a lot of stuff automated and that we we'd still run into tickets and and that would take one two three weeks a month to get done and we were told plan ahead do a better job planning and that shows a severe lack of understanding of what it's like to be a member of an agile product team here where we make mistakes we're fallible you know humans are fallible and not everything is perfect as planned um you know we've we've learned that for decades now right so to kind of get away from some of those traditional mindsets and realize that we need to pivot we need to make changes and we need to automate everything everything so you know as we're doing that value stream mapping we we pinpoint those those uh hindrances those points of friction in the process and we and we target those ones that are causing the most amount of pain so we shift left right we start to automate those things and put more power into the hands of the developers but it doesn't stop there um at this point you know we've shifted left and now developers have more responsibility responsibilities they have all the tools to deliver software faster but they also have a much greater responsibility so let's look at you know specifically around the area of security you can't just shift left and say you're done all right all the security all the um secure code is in your hands now it's up to you guys right so you have to build in you have to you have to revisit that you have to look at empowering teams not through not just through tools but providing access to expertise you know people who understand application security not just these centralized teams that lay all the groundwork and then hand the tools over to developers so for me it's a lot about building a support system building all of the um all the things that a developer needs to be able to deliver software not just the tools but providing educational opportunities access to other expertise one of the big things i've been focusing on lately is really around inner sourcing and taking the best of breed ideas and making them more reusable so taking these things that developers are building and make sure that we don't we're not building it time and time again in the same way on different teams so the long answer a lot of different things piled within there but it's about shifting left and it's about providing the structure that developers need to be able to

you know provide an environment where developers can be successful at delivering software not just giving them all the right tools yeah so what's some of the um when you think about creating access to expertise that's a really interesting uh concept and i can imagine when you have a lot of developers how do you manage access to expertise in a scalable way it's definitely been a challenge i mean it's there's still a tendency to fall back into tickets and service desks and you know structured means of communication across teams a big part of where i see that we're being successful is really the more of the informal types of stuff you know we're out there and in slack and we're making ourselves ourselves available to talk to each other across teams kind of breaking down some of those traditional boundaries so it's definitely easier said than done but you find the people that are really proving to be successful to show the people that are really demonstrating both the expertise and the um willingness the appetite to help across teams and you put them in a position where they're able to do that um allow them to um get involved where applications are experiencing that pain and where application teams are experiencing that pain and where they need some additional support so it's a little bit about just uh breaking down some of the barriers and identifying you know people who are who are best fit to be able to do that we're still you know still something that we struggle with to this day so we don't have it completely solved when you find someone who has some useful experience that you think would be wow this this person really needs to get in front of more of our developers and anyone feel free to chime in but um what do you do next does that person do you have to talk to their manager and say listen we we want this person to be able to spend some of their time uh being available to other teams kind of make it part of their job or

you know what what's the next step when you sort of identify those those experts out there personally for me i try to get them more engaged and more involved we've seen people with a good idea something that they're building out um that i think others other people could benefit from and i ask them to uh you know contribute something to our inner source library let's make this let's package this up and make it um make it reusable or or um or i might start a i might ask them to do a blog post on the topic and then i'll try to get some more i'll leverage that and try to get some more return on the investment so to speak to make sure that we're taking that that skill set and getting getting the most mileage from it whether it's through direct involvement across teams or just having them commit in ways that we can uh benefit from more broadly without without asking for a bunch of time or a large commitment so it's really just trying to give them a voice and get them out there in the community and get them engaged to where they feel recognized and they feel value in what they're doing it it doesn't feel like just another job assignment yeah yeah that recognition can be a really a great motivator for you know humans and stuff um okay so coming back to um you know developer experience there's there's something that recently i've seen come up a lot that i'm curious what y'all's perspective i don't know if that's an appropriate use of y'all but uh we're just gonna we're just gonna go okay oh okay great um wait twice or thrice we had to bring in thrice so you know thank you no that was like we're on like a volleyball team i don't know if you're goose and i'm maverick but someone just set and someone just spike it's something like that it's great um team work so this this kind of notion coming up we're trying to connect the dots between some you know some technologies out there stuff like kubernetes and then developer experience and helping people understand what's the connective tissue

between these two things what needs to happen between them and one thing that i i'd love to get y'all's perspective on there we go that was at least twice maybe thrice um is what's the what's the the connection what what is it about containerizing applications uh and then getting them on some kind of platform that enhances the developer experience that helps it um and on the flip side where are some things that where it maybe creates some challenges as well like different challenges that didn't exist before but can can we help connect the dots for folks between okay containerizing apps it's been something that's happened for a long time um how does that help how is that better than what folks did before i'll look at you kevin because i know you're you work on the platform side of things absolutely so in kind of like you're describing with essentially all the talk about kubernetes now and especially in context of cloud foundry comparing that to the diego runtime um one of the things that i guess it's kind of hit me somewhere along the way is the whole spirit of a pause is that that's not a part of the equation and good or bad i believe that delivery has happened in such a way that the developers that you know are essentially working on the applications that are great fix fit for a you know platform as a service don't even realize that they're taking advantage of it because it's just it's a run detail um i i have yet to actually find um actually probably anyone that would call themselves a developer that actually enjoys networking you know so kind of in that same spirit creating your your your your you know your code that's running to to actually do that you don't really know or care necessarily that it's in a container the beauty of the container is exactly the same thing you started with your manifest you declared exactly what version of stuff you want in there um we have a little bit of abstractions in there that kind of help us out from the security

space where hopefully you know the apis are compliant and the stuff runs you just you create your code and you put it out there and runs and then you put it in this native environment where you have multiple instances so you care about the fact that your app is up and running and to a certain degree you don't care if there's one running two running or 200 running as long as your app sustaining your workload and as long as you don't have an outage you're happy you're delivering what that application is supposed to do containers at the back end allow us to do a lot of those things i teased in there it allows us to potentially swap out security layers you never even knew or never even cared um it allows you to keep isolation in the sense that like when the rolling platform upgrades are rolling um the actual virtual machines themselves successfully shut down because they're in a container you don't have the hung processes that used to exist in the past we're now pushing where we want to have ross is running hopefully closer to hours at a time where um you know a couple of decades ago i almost made an uptime of over a year and i actually almost saw that on one of my running servers but that's like two decades ago now i'd rather see that thing destroyed in a matter of a couple hours because you know the spirit is to get it to zero so the the part of the beauty of the containerization to me is all of that stuff is it is a backroom detail of which i've kind of been a backroom guy and even there me personally i don't really it doesn't matter to me that much what matters to me is the haiku give me your code i will run it and you don't need to know how so the container is the answer in that today and if that container happens to be purple great if it happens to be yellow awesome if it's multi-color make it a rainbow put a unicorn in it i see what you're doing there but i'm not taking the bait yet um okay so so matt any perspective on from the the security architecture side kevin alluded to the fact that you know while it's it's really kind of a an implementation detail that ideally developers don't have to worry about don't have to know about but it does allow for some

interesting things to happen behind the scenes um some isolation and uh the ability to make some security changes so from that perspective does it help the developer experience because it allows you to create an environment where they don't know about it yeah i mean absolutely helps with um you know taking some of that away from the developer's responsibility but there's been a little bit of a cultural shift there as well you i mean when we started moving more towards these disposable containers developers wanted to keep control wait a minute why are you why are you applying the latest build pack why are you doing these upgrades this is going to break my system when i when i don't expect it right well that you're trying to take away one of the main advantage of shifting towards these containers is it allows us to do these ongoing upgrades every time you deploy your app you're going to get the latest security patches and we're going to make sure that you're running in a safe and secure environment so there's a little it took a little bit of uh of adjustment to get used to but we're at that point now where we're really benefiting from that when you you know making sure that we're applying all the latest security patches keeping um applications isolated um upgrading certificates and there's really a lot that's handled by the underlying platform and building out those containers that we can take care of on the fly like kevin said earlier you know he's he's lazy i can i can uh i can relate to that i think we all are on some level right so we don't want to have to do all those things ourselves every month we don't want to have to deal with that the life cycle updates just to keep our applications up to date we just want to deliver value and so the containers really help us get to that point i remember going back a few years when we're teaching people what's a blue green deployment what does that mean to be able to deliver with zero downtime and we're past that now we're talking about sort of that next level some of the next level challenges and um i'm able to deliver software at speed and a large part of that is really our ability to take advantage of containers okay um yeah that's okay that's starting to connect the dots and i think you're you're touching on what that real value of developer experience in the first place right if we

always come back to that that's our north star which is we're we're delivering value to our end users right we're getting that value to production if this helps us get there um then great it's uh it's supporting that that goal um i wanted to sort of poke a little bit more also on the security side because there's another aspect to the developer experience that comes up a lot which is sort of thinking about talking about getting value to production right and it's like that's very deliberate um that like just building the code and getting it working right to kevin's point of like let's start with working um yeah that's important that allows us to then you know do things more repeatedly right if we if we have a working state but getting it to production has a higher bar and i know that one of the things that's in that uh that raises the bar is certainly a lot of security requirements so when you think about okay what's helping us deliver that value to customers we have to get all the way to production what are some of the things that you see help improve the developer experience um by looking at that path to production and maybe matt you can comment on the security side and miranda and kevin can comment on some of the other aspects yeah for me it's like i always make the assumption that developers want to do the right thing they always have the the right intentions i mean it's certainly not true 100 of the time but um it helps to think of it that way in in terms of like we have to make it easy to do the right thing and developers will do it they want to do what's right but they'll take the path of least resistance to get there so when it comes to getting an application to production and this process gets me there in a in a month and this other process gets me there in six months you know which path we're going to take right um so to me it's a lot about um you know looking at that at the points of friction and trying to and looking at the path of

least resistance and trying to make it make it easy to do what's right and it ties back to a lot to developer empowerment and automation of all the capabilities that we need people to be you know need to be following and a lot of the practices that we want people to be following and making it easy to build that into applications yeah and that that also makes the case for that value stream mapping process that it helps to know how long it takes to get to production some other way um because then then now you have your target it's like i've got to be less than that less friction less time uh fewer tickets whatever whatever the the measure of friction you want to have but it's got to it's got to be easier than that and then that's how that's how i'm going to shift developer behavior Miranda how about you uh what do you see in terms of the the distinction of getting to production and what is how does that change the the developer experience bar yeah so i think um something that i've noticed about getting to production that's interesting is kind of each summer when we bring in our new interns or our new hires um at least for the interns the challenge i have whenever i'm entering an intern is within their first day they release something out to production and it's like years ago you know everyone would be so excited like oh i got some code running in production today that's amazing and now the interns are like okay that's great you know next what's next so it's funny to like have that changing perspective every year of seeing the shift of um new people coming in because they haven't felt that pain of waiting weeks or months to get something up and running into production so it's like i'm over here having a party and you know they're not quite as excited so trying to yeah try to find like okay what's that next bar that we have to measure to and what's that it's almost like a continuous journey of how can we improve dev experience because people coming in have totally different perspectives on what

developer experience is like compared to you know those of us who have been working in this field for a little while yeah that's an interesting perspective on our you know like some i'm sure you could ascribe some generational commentary on uh on that we won't quite go there but um who needs labels uh but but yeah that's true where you know over time like this kind of amounts to just a completely different set of expectations where folks uh don't remember the olden days when you used to have to get in a horse and buggy to get your code to production um but all right so kevin how about you what do you what do you think in terms of uh thinking all the way through to production what does that mean for the developer experience for you it's going to be basically a lot of the sentiment the way matt described it but i think one of the best ways i've heard it secure by default i'm going to make it hard for you to actually remove the security control that was already there for you in place you know like one simple thing feel free to hit our um services with an http call it's not going to work everything's encrypted it's just easier you you don't just do you know there's a couple of key simple things like that um how about we sign our certificates with a public signer that's already in all of these other common trust stores you know how much work that eliminates it's kind of awesome secure by default it's already part of an existing trust state little simple things like that all the way through you know same like in spring security if you just add it to your spring boot app in the palm you have security turned on awesome you know to me that's the best way to describe all of that stuff figure out how to embed it in from your your your working starting point and make it hard to actually remove it because we're all lazy and i'm not going to remove it because it doesn't actually have any value for me to remove security and if you make it hard you know you deliver from that obviously those words a lot easier to say than it is to actually execute on um but that's you know the spirit of how we approach everything kind of in the

makes a ton of sense and and some the way that you're kind of describing this of like okay if i i have to make it harder to like turn off the secure by default um features or attributes right uh that it triggered something for me thinking about like how do you stay in touch with what what are developers thinking what are some of the practices you use kevin to just kind of stay in touch with that like do you sit by side side by side with developers how do you kind of stay in their their head and build empathy for what they're doing the i guess when you say it that way i guess it's really shoulder to shoulder so okay i said i'm i'm kind of the on the back side of that equation if you will so i don't get to do as much of the hey i'm starting a fresh project with from the developer perspective you know here's my fresh new spring boot app um we use that a lot for ourselves for testing out the foundations and all the work that we do but what comes down to most of my interactions with developers it's on that other side of the equation so i don't get that nearly as much but quite simply that what comes down to is when a problem comes it's exactly that we just sit shoulder to shoulder and we start pounding at that code and you know for those that happen to be the same offices to me shoulder to shoulder is awesome obviously literally but virtually um you know we we we have at least three different failing types of video technology that we could fall back over to the other one when one of them's not working you know so we just get together and throw some code figure it out yeah no single point of video conferencing failure that's uh that's a good takeaway um and it's redundancy or other great terms of yes yeah when uh when physical shoulder to shoulder doesn't work um miranda matt what what else would you add in terms of how do you maintain or or build empathy for developers i know you you're both everyone's sort of described as a developer at heart but you know but people sometimes think different do different if for me for me personally i do spend

a portion of my time in the trenches so to speak shoulder to shoulder with our developers in our our community our customer base and it's not uncommon for me to go to cavins and have you ever seen somebody try to use this right let's look at this experience but i i try to um i i guess i make a personal sacrifice to spend a lot of time keeping a wide open door and having people bring me bring me problems um a lot of times you discover things that you don't know uh customers are doing just to work around the things that we put in place we don't even they don't even you know i guess until you spend time in in their shoes you don't understand what it's like to work with some of the experiences that we put in place so i i personally try to help them actually solve their problems not just talk to them and ask them via surveys what are the biggest pain points but rather sit down with them and try to solve the problem together and that way you can kind of experience what they're going through why they're doing it the way they are um and that sort of stuff so i spend a lot of time doing that that's the only way that i'm i think i'm successful able successfully able to advocate for the needs of our developers is by actually spending time in their shoes and trying to work with our tools that we put in place yeah that makes a lot of sense mirenda how about you yeah so i spend pretty much all day every day with developers customers across the organization um so my part of our department is our what we call customer success so we're handling all the um support tickets that are coming in so we're seeing all that we're working with customers every day through that but then also my personal passion is with education so i'm working with a lot of our training department helping develop curriculums helping run hackathons run workshops so i sit in on a lot of that training just to see you know how people are experiencing our platform for the first time so in that way i do a lot of shoulder to shoulder kind of getting those first impressions yeah those are really valuable because like once someone gets used

to uh a way of doing things the you know human brains just start to cluster together sets of uh behaviors and uh tasks into a meta task like you know brush my teeth as opposed to get out toothbrush get out toothpaste remove cap blah blah blah so um you know that those those first time experiences that's that's a great point of how you get you know imagine someone brushing their teeth for the first time like you're gonna see all the things they're like why do i have to do this how much toothpaste do i put on so um that's great all right my last question is something that came up in our prep call um that that got my attention uh matt you described having some unicorn stickers that are uh sort of coveted awards and recognition speaking of recognizing and humans to tell us about these unicorn stickers yeah um interesting question the uh the uh we talked about this a little bit earlier actually my my desire to kind of combine this um this uh developer advocacy with security architecture and try to recognize those people with that expertise to help out help break down some of those boundaries and uh helping across teams and i've noticed that it's pretty hard to find people that are skilled in both development and security in fact when i was going after my current position i remember coming across some naysayers and it seemed like they were there was going to be a desire to find somebody with some deep textbook security expertise and instead of being afraid of that i kind of embraced it and i said this is this is what i bring to the table this is what our organization needs right now to kind of shift left and start to put that support system in place to be able to help our application teams deliver secure code and when i ended up kind of landing the job and and taking that taking on that role my wife actually got me a pack of unicorn stickers unicorns with with computers

because um you know this was like uh i guess everybody told me that it was a that the someone who knows development and security is a bit of a unicorn in our industry so i got this pack of uh unicorn stickers to give out and the way i chose to use that was you know when somebody does something chose demonstrates some secure coding practices um i give them a little unicorn sticker to put on their laptop so it's uh just a little form of recognition that somebody's um doing the right thing and um learning something new at the same time yeah that's that's quite a a club to gain membership into is the uh the unicorn sticker club so i imagine there's lots of folks at liberty mutual proudly displaying their unicorn uh computer stickers i've given out a few but they're not they're not easy to come by so yeah well that's what i hear about unicorns you know i keep looking but i found a lot of rhinos uh instead um all right well thank you everyone for for joining us today it's been a an enlightening discussion about developer experience and content connecting a bunch of dots across uh what that means from technology and practices and people and teams uh and and automating all the processes in between so thank you and uh talk to you again soon Thank you.

Tanzu Talk · 🍕 Get more pizza.