Tales From The Database | All's Well That Ends Well

  |  Compiler Team  
Desenvolvimento profissional

Compiler • • All's Well That Ends Well | Compiler: Tales From The Database

All's Well That Ends Well | Compiler: Tales From The Database

About the episode

Big mistakes. Colossal setbacks. Bad days. We’ve all been there. But how do we find a way forward? The Compiler team shares two stories of unexpected challenges and happy endings. 

Compiler team Red Hat original show

Inscrever-se

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transcrição

When people hit hard times or encounter a difficult situation, they look for the light at the end of the tunnel—or sometimes they call it the darkness before the dawn. But for some of us, during times when stress is really high, it can be challenging to believe that there's a light at all. I left college and the realisms of the real world kicked in immediately, right? I just remember my tutor sitting me down going, "You've got to go make it happen now." And I was like, "But how?" He's like, "I don't know." In my experience, a happy ending isn't always a guarantee, even when you start out with the best intentions. We thought that we knew what our customers would need. They were asking us again and again to build the same thing. Today we're going to hear two stories from two different people in two different parts of the world about how things can turn out okay in the end despite the odds. (00:59): This is Compiler, an original podcast from Red Hat. I'm Kim Huang. And I'm Angela Andrews. We go beyond the buzzwords and the jargon and simplify tech topics. We are sharing stories from industry veterans about how they found their footing in the tech industry. Today, all's well that ends well. I want to bring back Evgeny Predein. He's a guest from a previous episode in the series. Evgeny is based in Spain, so that's where our episode starts. (01:37): Early on in his time as CEO of Apiumhub, his team had a client, a customer like the ones he mentions at the top of the episode. This particular customer asked for the same thing to be built again and again, remember—which was fine, but possibly a bit tedious for the teams involved. (01:57): Evgeny and his crew thought they had a better way. We had an idea and we started to build it, and we created a user management and payment system as well. It was like a bunch of features combined. The team was excited about the work. They had an established use case, and there was a lot of energy around making things simple and more efficient. It really feels like that startup environment, and it sounds innocent enough: a group of ambitious, driven developers making something that would serve their customers better. We spent almost two years building and investing in this product, and once we thought we had it ready, I tried to pitch it to our clients and to offer it even on a free basis. Evgeny and his thoughtful, talented team was ready to take their product to market, but they wanted to see what this customer thought of it first. After all, it was an idea that was born from the work that his team was doing in support of their business. What could go wrong? They refused to use it. I can't help but laugh at that. Yes. Just to kind of break down the situation, Evgeny and his new team, they've been doing what they've been doing maybe for a couple of years. They're a very small company, very small team. They had this customer that was asking for the same thing to be built over and over, and instead of having developers dedicated to that work and doing it—it's fine to have that—but they wanted to make things more efficient and they thought that they would have this really great solution built for this customer and other customers like them. (03:39): So it's not just a situation where they're trying to satisfy one customer; they're trying to build a business off of it. They're seeing maybe they have other customers that have similar pain points or similar challenges. They're trying to take a product to market that can address this particular use case. And when they go and they spend months working on it and they take it to the customer to see what they think of it, they don't get the reaction that they thought they were going to get. (04:08): Angela, what happened here? Other than the trombones playing, "Wah, wah, wah," other than that, you never know how people will receive the work that you do for them. No matter the passion you put in, the time you put in, the resources, you feel like you—Evgeny and his team—were solving said problem. And for the customer to come and say, "Nah, we're not doing that," it feels like your world is closing in on you a little bit, like, "We did all of this and you don't want to use it." (04:49): Now, I don't know what the end game or the end of the story is like, but I know the team was crushed. Yeah. Angela, you would have a lot more frame of reference than me, but imagine putting in so much work and time and energy into building something like this, not just for a client, but for a specific persona or a use case, something that you're going use as maybe a cornerstone for a specific part of your business. From a startup culture perspective, I feel like the response that Evgeny got definitely wasn't the response that they were looking for. They were looking for a kind of approval or excitement about something that they could maybe hang their hats on as far as a business perspective is concerned. The good thing about this and a lot of situations like this, as Jill Scott would say, "Everything ain't for everybody." I'm sure there were probably other customers who thought this was the bee's knees. This product that they delivered, it did something for them for a use case that they had, and I'm sure someone was willing to take this on and try it out and take advantage of all of this hard work. (06:02): I have my fingers crossed that that's where this story is going because just because it doesn't fit for one customer or one persona or whatever, doesn't mean that others cannot find the value. And we're going to see what happens in a moment, but before we get there, Angela, I just have a question for you. Yes. I imagine this happens more often than not. Why would a customer reject a product that kind of answers their questions or solves their problems, especially if it's coming from a trusted source? What reasons could there be? Well, we don't know what's going on behind the scenes for them. Things may be changing for them. Their wants, their needs, their internal use cases, their internal customers may have been the factor as to why this was no longer something that they would be interested in using. So it may have no impact on the team and all of their hard work. It could definitely be internal pressures or things that are changing internally that, us on the outside, we would never be privy to. (07:06): So again, we've done an episode on where projects tend to go by the wayside and they're not a priority and time and money is wasted. And through no fault of Evgeny and his team at all, we don't know what the customer was dealing with at the moment. It could very well have been great maybe two or six months ago for the customer, but as their goalposts are moving, sometimes they may not line up. I'm going to bring back Evgeny because he's going to tell us how it all went down. Yes. When we started to ask why, they started to mention some points that we didn't see at all, if the product that we had in our mind actually made sense for them because it obviously made sense for us. But once we go and we tell them and we try to make them use it, they have a lot of restrictions. And it was like many, many, many, many things that we didn't have into account. Someone didn't do discovery. Yes. And to your point earlier, sometimes it's an internal thing. So discovery is kind of a daunting task because you don't have that perspective internal to the customer. It is. With software, it can be difficult to automate or streamline processes, especially if you're dealing with a customer. It takes more than code. In some industries, there's a lot of regulation, a lot of compliance issues, both with international laws or with local practices, and also with integrations with other software. There's security issues as well. There's governance and training. How long will it take for the customer to learn a new system or a new technology? Will there be any downtime during the rollout? There's so many different things to consider and so many factors at work. What we learned is even if we understood ourselves as experts in a specific area, we needed to approach the customer first to ask them if the idea works. Ultimately, it comes down to communication. If the team had just told the customer what they were thinking from the beginning, it would've saved a lot of heartache for everyone. (09:15): Evgeny suggests, for other teams looking at a similar situation, getting ideas down on paper in kind of a low-fidelity, simple way, and starting the conversation from a safe space. I would start with a single PDF or a PowerPoint and make a presentation to a couple of the clients that you have some trust with them, the ones who would say to your face what they truly think about the product. So as an SA [solution architect], where we run into a lot of conversations with customers where they have a problem and we want to solve their problem, but you always have to listen to the customer. What problem are you trying to solve? If the customer says, "When I flip this switch, it doesn't turn on," what do you want to happen when it turns on? If you're solving for the switch, that may miss the ultimate end goal of the issue that the customer's having. It could be, "Well, this switch kicks off this process that does this thing that queries this API that brings this data back. This is what we're solving for." So it's not the switch; it's all of the other things. (10:28): So when I said before—doing discovery, asking these really open-ended questions where the customer has to explain to you what they're trying to do. What's the end game? What do they want to happen when that switch flips, and what problem are they trying to solve? We hear this in our learnings as solution architects all the time, and we want to solve your problem. Sometimes you go straight to solving without having asked the really important question, and you could be solving the wrong problem and not even realize it. Right, or maybe not even fully understand the problem. Exactly. That really agrees with a lot of the things that I've read, especially about startups and about getting into startup culture. Sometimes teams build to solve problems that either the customer doesn't have or they don't see, or maybe they just don't have that full understanding of what the problem is, and they're really enthusiastic to solve something that they don't quite understand. (11:33): Is that kind of like what you're saying, Angela? Exactly. You want to help. You want to be of service. You want a product that people are going to love and use. But again, if you're not talking to the customer and figuring out their problems, it doesn't matter what you're doing. If you're not solving for their X, you're really wasting your time. Absolutely. (11:58): For the team at Apiumhub, it was a learning experience. There was nothing left to do but put the work aside and move on to newer things, but a lot of effort had been put into that product, and they didn't just want it to be put on a scrap heap. We changed our strategy because we converted it into our open source project, so we offer it for free, most of it. The project is named VYou App. It's open source. You can check it out on GitHub if you're curious about it. Tell them we sent you. (12:29): In the end, trust is a big component of why people adopt new software and new habits. That, and the lesson learned from one bad experience, is what Evgeny keeps top of mind. We know that there is a roadmap that has to be built, but first of all, we are trying to build this community. And this is a big thing because a developer, it's not easy to make him trust you because he has the tools that he has, the tools he's used to, and to make him try something new, it has to come from somebody he knows—somebody he knows, or maybe a couple of them who would recommend it strongly. And this is what we're trying to do with this community and open source project. Wow. The beauty of open source. Yes. (13:15): Next up, the path to success isn't straight, and it's not without any bumps. We'll hear from a person whose story has a great ending, from humble beginnings to one of the biggest names in tech. Stay with us. (13:38): Our next story takes us to the U.K. [United Kingdom] where young Kevin Evans was still in high school. When I was 14, I started working for a managed service provider as a side job when I was in school. So for six weeks at a time, instead of playing basketball or soccer, I'd be actually in there building networks and deploying servers. And at the time, I just thought it was like, "Oh, everyone does this." No, they don't. Not at that age either, right? That's funny. "Everybody does this." Yeah, you're just deploying servers. Yeah, it's just something that you do after school every day. Every 14-year-old. Yeah. I think that's so funny. Yeah, definitely not a traditional hobby choice for a 14-year-old, but Kevin always went against the grain in a way. You see, he came from a working-class family in the UK and he wasn't actually the best student. I wasn't the right fit for school, and school wasn't the right fit for me. So it was probably the best thing my school did for me was put... Maybe they saw it as me removing the problem and giving it to someone else, but it was, to me, it's the only thing I've ever been good at or had an interest. So I really thrived in it because I was learning, and I didn't realize, but I was actually learning my craft that was actually going to set me up for later life. So we have this kid, he's 14 years old, comes from a pretty humble at-home environment. His family doesn't work in tech. He's not doing really well in school. Traditional school is kind of not his thing, but he gets this job, his side job, working... What did he say? He was a service provider, so he was working for a managed service provider. So what would that environment be like for a 14-year-old working there, I wonder? I mean, I think... Let me put on my 14-year-old hat, right? Sure. And I get handed this task of working for a small ISP [internet service provider] somewhere back home, and they need a couple of hands to do some work. And at 14, was he just racking and stacking? Was he doing more of software or was he more hardware? It really doesn't matter because at that age, maybe this is the first time that he's found something that it's like, "Oh my God, this is so cool." Not even knowing what the big picture of this project that he was working on, but he knew that he was interested and he knew that it piqued his interest, and maybe this was the first thing that ever spoke to him or fed his soul in such a way that school could never. And I love the fact that maybe he found his calling at such a really young age because most of us don't know what we want to do when we're 14. That's exactly, I think, what Kevin would say if he were sitting here with us right now. But yeah, it feels like Kevin didn't excel at formal school, but he did have this kind of attraction to technology from a very early age. And when his high school life came to an end, his formal schooling came to an end, he did seek vocational training instead of the regular university track. He went to a technical school and he got certifications in different technologies. (16:59): His parents were surprised. You have to think about, he wasn't a very good student, he was coming home, not very good grades, not good school performance, not high marks. They weren't expecting this level of dedication from him. When you find what you love, you're going to see dedication. You're going to see people put forth effort. It may not be in the traditional realms that we see, but when young folks find their passion, they're always going to give it their all. That's just how it is, and I've seen it time and time again. That's right. Good for him. Yeah. I remember going back to home to my father and handing him the certificate, and he was like, "Did you print this out? Is this real? What's going on?" Just to give you an idea of what kind of kid Kevin was like, he comes home with a certification, the first thing his dad says, "Did you print this out? Did you make this in Photoshop?" I think that's hilarious. It is. And it speaks to just how much maybe they didn't expect him to excel and shine in something, and to actually have proof of him accomplishing something that he was so proud that he had to hold it up in front of Dad. For them, that was probably an awakening, like, "Wow, he found something that he's good at," and now they can get behind it because they see this is where his passion is, and maybe this is where they can actually actively support him because they know this is his thing, and all parents want to see their kids excel. Definitely. (18:32): Kevin, in particular, was really excited about learning operating systems, which makes sense for what's coming. But first, I'm going to throw down the gauntlet. It's time for a debate. Yikes! Put down some debate noise. I don't know, like a signal for debate. (18:53): Okay, formal education versus certifications. All right, let's be real. Let's lay it all out the table. What's the deal? What's really the most advantageous for people wanting to start a tech career? I'm going to upset a whole lot of people. It depends. Right, okay. And I'll tell you why it depends. There are certain fields inside of technology that will require a formal education, that will require higher-level mathematics and computer science and data and things like that. That is such a small subsection of what technology is. (19:35): A bigger part of it, you can learn on YouTube University— Oh, boy. My favorite. ... on all these online learning platforms, getting certifications, joining communities where there's a bunch of people coming together to learn a thing, all of these free tracks out here, learn to cloud, learn Python, learn DevOps, they're out here. It doesn't require you to spend a penny, and if it does, it's very nominal. (20:03): So there are some arms of technology that do require that formal education, but depending, if he's talking about racking and stacking and installing operating systems and managing systems, I don't think you need a formal education for that. I think what you need is this base understanding. First, you need the passion. That's important. The rest of it'll come. If that's where you want to put your focus, you put your heart into it, get the certs, learn the OSs, learn what makes them sing, and that's how you can build a successful career. And replace operating systems with anything, with whatever your passion is. (20:42): So I'm going to go with the age-old, "It depends," but I really do think there's a lot of arms in technology where you do not need to fork out hundreds and thousands of dollars to be successful. I agree, and I feel like you said it a lot better than I ever could, but I just wanted to just put that out there because I know that a lot of our listeners are making these decisions. We're talking about them objectively, but there are people who are listening who are making decisions between, should I go for this certification? Should I learn this? Red Hat has their own training and certifications, if you want to check that out. Should I go for that? Or they want to go to a regular CS [computer science] program or a regular network admin program or anything. And really, the proper answer is—just like you said—it depends. It depends on what you want to do. (21:29): And also, just a little bit of a shameless plug for our continuing education episode that we just did a few weeks ago, it's not like a finish line. It's not a race that has a specific ending. You can still choose your own adventure or choose your own path and put together both a formal kind of education and also certifications that you get at your own pace. (21:51): Honestly, that looks a lot like the people that I know personally. But again, you're absolutely right. It does depend, and you don't have to feel like you have to put yourself out a kidney and a mortgage in order to get yourself on the right track. That's happening less and less nowadays. I like that. Not to say that it's gone away, but know that there is a path for you that won't break the bank to move into this field. It's very welcoming, and more and more folks are putting out content that they've used and they've learned and they've compiled it, and they're sharing it for free or creating courses. The world is our oyster at this point. If there's something that you want to learn, it is out there for the taking. Absolutely. So good luck to everybody out there that's on this path of finding their career or changing careers or trying to upskill. The time is yours. Yes, absolutely. (22:50): And speaking of time, at this point of the story, Kevin's training program is coming to an end. It was time for him to get an actual job. So now he's out of high school, out of vocational training, and that's where he is at the top of the episode where you hear his voice for the first time. He's feeling a lot of pressure to make it all work, and he's kind of uncertain of what to do next. I managed to get a job on a help desk, and I was basically troubleshooting servers, that kind of thing, basic networking. And that was about 2007, 2008. In between then, I had random jobs, whatever I can do, working at supermarkets, that kind of thing. Okay. I see where this is going. Do you? I don't know. I'm remembering 2007, 2008. There's a lot happening back then. So where's his story going? Well, we talked about this at length in our tech support episode from last year. Kevin's taking the same track that a lot of technologists find themselves in. They're doing tech support, they're on a help desk. It all seems legit. Everything seems like it's going well. But Angela, you kind of caught it. The dates that are involved, 2008, and we all know what's coming. Yes. Then the global recession happened, and it affected absolutely everybody on the planet in some way, and it was really deep and it was really fast, and I lost my job. I got laid off. So yeah, here we are in 2008, and the world in 2008, especially for anyone working in tech or basically any industry at that time— At that point, yeah. ... kind of got hit with quite a challenge, quite a hit from out of nowhere. And he was hit hard, just like so many other people like him who were starting their careers at that time. I must have gone for 200 job interviews. At the time, you're just like, "I'm never going to get a job." Oh. Yeah. Why does his story sound like people's story today? Yeah, it's eerily familiar. This sounds familiar, this feels familiar. We're at a time right now where things are so uncertain, and I'm hearing him and I can hear it in his voice, and folks are getting desperate. They were desperate back then. People are desperate now. Trying to get that job and having tons and tons of interviews and no callbacks seems to be happening to a lot of folks right now. Yeah, definitely. Throwing back again to the episode we did on economic uncertainty, it felt like it was so easy back then to lose hope and to feel like you were playing a game that the rules were changing as you were playing it. (25:57): But for Kevin, he had very specific goals. He wanted his career to take him outside the U.K. He wanted to work on what he was passionate about, so he didn't give up. It was like, well, what do I do next? So I went back to the supermarket that I had a job in, and oh, I had job in a bar. I had job in another retail store. I didn't realize, but having that perseverance would actually become one of my superpowers later on. Sounds very familiar, too familiar for your humble producer, ahem. But it was that perseverance that would land Kevin in his current role as a cloud solutions architect at Microsoft. It took a lot of work, multiple attempts, multiple rejections, even from Microsoft, and like I said at the top of the episode, it wasn't a smooth journey. (26:56): Looking back, Kevin knows how many other people are out there with stories like this back from 2008, and even today. That's why you'll find him speaking, streaming, and doing podcasts even, trying to educate people on new trends and developments in the industry. It's his way of paying it forward, giving people the help he wished he had back then. When I started out in the industry, I had a lot of older senior people that were like, "Go and read the book." Which book? "I'm not going to tell you which book it is, but go and read the book." And we've all been there. So I'm like, "This is the book you need to read. By the way, I took all the good bits out of it, and this is what you need to know." Concise it down. (27:39): So I'm really big on mentorship and giving back as well because I just feel like it's something that everyone can do and it doesn't cost anything. Oh, he's so right. I know. Good for him. I love the fact that he knew that it was his responsibility to pay it forward, making the path easier for folks that are coming behind him and for those folks not to lose hope. So kudos to Kevin for all of his hard work. I know how important it is right now for people who are listening to hear a success story like Kevin's. (28:14): When I said goodbye to him, I left it off by asking what he thought of his own story, his own career journey. This is what he had to say. I looked at every section of my career where it hasn't worked out, and it hasn't worked out a lot. Because the one thing I get asked is, "Oh, it seems like it's been amazing for you." It's like, "It's not. It's been a car crash sometimes." That's the way I look at it. (28:38): Always consider that. There's always a silver lining, I suppose, is what I'm trying to say. A feel-good story. Yeah, one that I think is really needed right now. You know? Yeah, I do. This was very timely, Kim. Thanks for putting this together. I think people need to hear this and feel it like I'm feeling it. It felt familiar, the kind of despair, and you're taking any job. You have to keep a roof over your head and food in your stomach, so you'll do what needs doing, but you know where your craft lies and you want to work your craft, and it's not outside of the realm of possibility that it will be hard to get back on that horse and start riding again and getting back out there and being successful in your craft. It's not easy. There's always going to be a silver lining, so I'm glad he said that because folks should not give up. Absolutely. For Evgeny, his team situation was a learning opportunity. It was one that kind of set him and his company up for success, especially with a new path in open source. For Kevin, it wasn't so much a mistake or misstep as it was bad timing, but he kept going and kept doing what he loved and it served him well in the end. (29:55): Today, both of these professionals are giving back in their own ways. I think what this says about disasters and big blunders—it can seem insurmountable and really painful when they're close up, but giving it the proper time, the proper space, and the proper perspective can let you move forward and succeed and give you a whole new outlook on what's important and where your role really is, and what your path can truly be. Don't give up. That's right. That's all you can tell people. Keep your head up, as they say. Yes. Yes, indeed. (30:34): I really enjoyed hearing these two stories. We feel like sometimes that our backs are against the wall and things are kind of against us, but as you can see, sometimes there is a silver lining. Most times, there's going to be a silver lining. Perseverance matters, staying the course matters, being true to yourself matters. Just keep doing the thing. Don't give up. (31:06): Again, as we're hearing, all's well that ends well, and I just want folks to take that away from this episode. And tell us your story. We would love to hear what you've gone through that may not have started out so well, and you hit a little road bump, we want to hear it. So hit us up on social media @RedHat. Use the hashtag #CompilerPodcast. I know you see yourself in this story somewhere, so definitely share it with us because we would love to hear it. And that does it for today's episode of Compiler. Today's episode was produced by Kim Huang, Johan Philippine, and Caroline Creaghead. I asked Victoria Lawton what to write for this outro, and she said, "Go and read the book." And I was like, "Which book?" We've all been there, right? That sounds like her. Our audio engineer is Kristie Chan. Our theme song was composed by Mary Ancheta. Our audio team includes Brent Simoneaux, Leigh Day, Stephanie Wonderlick, Mike Esser, Nick Burns, Aaron Williamson, Karen King, Jared Oates, Rachel Ertel, Devin Pope, Mike Compton, Ocean Matthews, Paige Johnson, Alex Traboulsi, and the marvelous Mira Cyril. Yes. If you liked today's episode, please follow the show, rate the show, leave us a review, let us know what you think, and most important, share it with someone you know. It really does help the show. All right, take care, everybody. Until next time. Until next time. See you.

More about professional development

Keeping up with changes in technology requires training and and engagement with learning opportunities—either in a traditional setting, or individually.

Publicações no blog

Friday Five — August 15, 2025 | Red Hat

15 de agosto de 2025  |  Red Hat Corporate Communications

...

Publicações no blog

Developing a standard AI OS: Unlocking production-grade AI at enterprise scale

14 de agosto de 2025  |  Brian Stevens

...

AI inference

About the show

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.