Everyone. Today, we talked about how happy engineers make better products, right? It completely makes sense, but the best way to make them happy in. The first place is really streamlining. The engineering experience. Today's guest is a real Tech Enthusiast and a great open source. Contributor every day just enjoys making Engineers happy in the first place. I'll somehow beat, don't forget to like And subscribe when you're in YouTube and follow us on your favorite podcast
platform. Enjoy Into Beyond coding, a dive into the world of successful people in IIT from your sponsors Z, Bia, creating digital leaders. Here's your host, Patrick akhil. Hey, Hassan. How's it going? Hey, how are you? We've been talking. I think for at least half an hour about breath of the wild and gaming stuff so we thought let's take off the episode. Yeah, anybody want to talk about streamlining? The engineering experience, right? I think as engineer myself it's
an important thing. Sometimes it's hard to communicate why that is important but I do think it's important nonetheless, but Can you explain to us, kind of why that is important in your own words first. That's right. So, so here's the thing, you know, being able to create something great, is very, very related to your experience while you're creating that thing,
right? If we want to build great things we need to enjoy every single minute of it, especially when it comes to software engineering because you know, software today is super involved into every aspect of our life, right? From the moment, you wake up in the morning, all the way Oh way until you go to bed, you know? And even while you're asleep the watch is on your, you know, reveal rest kind of calculating
your heart beats. So, so to software and technology is literally encapsulating a lot of aspects of our lives today. And if we don't, you know, think about being able to produce systematically produce, you know, high-quality, Reliable Software. You know, a lot of problems could happen and, you know, to be honest, to be honest with you, Patrick, you know, a lot of people like, We'll put a lot of time and effort into all, you know, let's find the best software pattern or the best for
software architecture. But I'm looking at this a little bit beyond code, and I'm looking at it, I'm saying, well, you have the great architecture and great pattern. But what if the person that's working with that is not enjoying the process? What is the process self needs a little bit tweaking? Yeah, you know, to make it actually attractive to to the individuals that want to work on this. I even heard some people say things like you know, well, this is this.
The nature of our industry, you know, if people don't like it they may go anywhere else. But that's also not a good approach because at least here in the US, there's over two million open software engineering positions Across the Nation. And there is a reason for that. There is a need right? And they need people with
certain skill sets, right? You probably heard a lot about the no code, low code automating code, and all that kinds of why do people are talking about that because there is you just scaring people. Yeah, exactly. And if we if we go around and tell people, Well, it's hard deal with it. That's your life. What's going to happen? Yeah, you can you can end up
with no with no English rightly. So so my main focus is to basically make building software enjoyable to make it something you look forward to every day, you know, you and I were just talking about the Legend of Zelda breath of the wild and you know how excited people like this, is it?
I I'm a gamer, I left a play video games obviously, you know, as you can see in the background but, you know, I wanted Make Engineers think really hard between playing a game that they really liked or going into working on this exciting project. They're working on. I want, this is my Turing test. Is that you feel just about the same doing either one of these activities, you know what I mean? Get that, but it's it
encompasses so much, right. It encompasses, kind of the daily things engineers are doing from the, the language they work with to the systems, they operate on how easy it is, for example, to deploy a new feature or To develop things how well tested they are or the anxiety. You get when you change a bunch of stuff and no tests fail, for example, and you're like and I probably made a mistake somewhere, is it not covered?
Then can we release this to even the more High over stuff right working together with other people feeding within that organization, the kind of autonomy and responsibility, you get even if it's on purpose, right? We give you this autonomy, you're responsible for this and even accountable for it or accidental. You touch it. You own it basically.
That's not really how it, how it should be it encompasses a lot and I also think developers are engineer, sometimes even have to fight for it versus kind of the business side of things. I guess people that are more product-oriented. Usually want the next feature soon as possible, I put Engineers have more of a long-term mindset. They're like, well, if we do this now in this way, right? A few years down the line few months down the line, we're going to feed it. What does that mean?
Basically, that's such a hard thing to communicate. I think what are some of the advice you would give to kind of communicate and really fight for that engineering experience in La. So the number one thing Engineers need to be, you know, aware of each and every step of the way from the moment, the product requirements needs to be, you know, gathered all the way down to, you know, the moment that product goes out there and being impacted by the
market feedback. Yeah, there's this mindset that, oh, you know, we don't need to have engineers and this business meeting or requirements meeting or, you know, they already build the project then now they're they're not engaged anymore. Let me take it from here and take you to the market. This is one of the biggest things that makes Engineers detached from the work that they're working on, because?
Okay, I'm excited, I'm working on microservices I'm using the latest and greatest Technologies but I don't know where that work is headed. I see some ads you know, every once in a while a I'm will show up and tell us oh look we're doing great is a trajectory, right?
But I might actually in the know In the Heat of it you know some of the happiest Engineers are the engineers that can go on read it at any point in time and see people actually, you know, really recognizing their effort in on the form or any other social media platform or even better.
What GitHub did recently is that they started saying, let me collect all the projects that are using a particular library or a particular Framework. So people can see real time how much adaptation is happening to their products. So, this is a number one thing then. No, you have to let Engineers, you know, see, the entire process. Now, I understand, understandably. Some Engineers don't want to
know the end to end. You just want to come into work, write some code, write some tests and then just go home, eat a sandwich and watch Netflix or something, right? Yeah, you know, at making it available is really, really important because there's a lot of Engineers that be like, I can't So here's the thing, if you are asked to build a feature in a system, right? It has to come from a certain level of conviction that this feature is actually useful. Exactly. Just Kung Fu Patrick and say
make the button blue. Why? That's right. This question. Yeah. Why would you know I'm temping at sometimes? I'm you know, I've been doing this for twenty one years, you know, all the way up until 1997 or something beyond that. And you know they, you know, I've seen people that get really frustrated When you tell them why, right? They'd be like, what do you mean? Why that's what the market was? Why I don't get it. It basically.
So anyway, you know, this is number one thing but but what's more important than this is the engineering experience. And this is Patrick this is this is the thing. I've seen all kinds of different patterns you see silos, you'd see, you know, people kind of going into pair programming sessions, you'll see people that are you know what I call Sam. You know, the Savior architecture model where you have the one guy on a team of eight or ten people.
That knows everything. Yeah. And everybody else is just waiting for that one, guys, blessing for that to have. That's a very dangerous science is. As I said, yes, as I go through the industry, I see all these different patterns. I started collecting that. I gathered all of this in a little book that I called it. 20 years in the tech industry, you know, that talks about, you know, all these different
patterns. But what's more important here is that You know, what I realized is that Engineers. There are three different aspects that if you fulfill for every engineer. Yeah, they going to be happy as they going to come to work and they want to they're very engaged, there's high-level engagement. Like you know, I always tell people as an engineering
manager. I always tell people fill people's hearts with happiness and hope will come to that in a second, fill their heads with smarts and then fill their bellies with food, you know? Yeah, I was It's talking to a peer who is also a manager said. I've never heard anyone say filled their bellies with food. What's that has to do with software and especially everything everything?
Yeah, nobody talking about you, if you're, if you're, if your software Engineers are hungry, your code is going to be hungry, it's going to be angry. So, what, so, what does that mean? You know, filling filling Engineers hearts with hope and happiness? What does that mean? First of all, Engineers, need to always have something to look forward to.
You can't just tell them today is like Yesterday and yesterday is like the day before, you can't do that, you have to Hype people up. You have to go and say, you know, listen guys, this is the next big milestone. If we hit this Milestone, we're going to get bigger and we going to be able to add more features and speak the language of the engineers that you're working with and tell them the future
has more, right? When you say something like this, people start like Engineers will start saying, I do want to grow. I don't want this project. I want to see my work, you know, grow. There is something that makes Engineers happy. They see their work being used and recognized and appreciated, you know, even even criticized. That basically means they hit the street and the street has an option, an opinion to talk about, so there's that guy, hope.
Yeah, right. But also hope includes, you know, Engineers being able to look forward to a brighter future for themselves. So it's not just about the product. Yeah. You know what I mean? It's not just about the project that you're working on. What about me? Where do I stand exactly right in here? Yeah. So so when you tell Engineers, listen man, you know today, you are building apis.
If we grow in this direction, you'll be able to, you know, to be introduced to UI components mobile applications. So now the hope is growing and growing because they're seeing real time, you know, plans for their growth. Yeah, right. It's not just about what they what they have is output. It's also their part in the process within the organization. Right? Right, right. So this is Hope and there. You have happiness. What is this?
Happiness part? This is the hardest part because us as Engineers were a little bit, can be a little bit pessimistic. You know. It come here. Yeah. You gotta you gotta think about that worst-case scenario because you know, whatever can go wrong will go wrong. So let's like, you know, Murphy's lot so, so what is this happiness part? You know, I realized that in any engineering team, if you systematically, you know, makes socializing A fundamental aspect of the development process
itself. Yeah, it has an amazing reflection on the engineers are regardless of, whether they are extroverted or introverted, I'll explain that in a second. Yeah. Like, for instance, in some of the teams that I work with, I instituted pair programming, as a fundamental practice, or any feature to go out. So, two Engineers, you know, we're working remotely. You're sitting on your computer and I'm sitting on mine. Yeah, I will write, I will write a failing test.
Then I will commit the code so you can pull it and make that test pass. And then you write a failing test and then commit that code back to me. So I can make it pass, I call it the ping-pong so you're pairing but you're pushing, you know, a commit and they pushing a commit back to your serving it's like playing a video game you know, against the friend but in reality you're actually getting work done. What did that what does that do?
Even for the most introverted Engineers that you know before going through that experience? The you stay now. I don't want to talk to people. People just annoy me, right? What I realized specially during the pandemic, when socializing is not an option, you need to stay home and this is the only way of communicating. Yeah. When they are programmed, the connections between this team and their understanding of each other and their collaboration, just went through the roof exact.
Right. Because people said, you know, during the pandemic, we're working remotely. Everyone's just sitting in the room, you know, writing code on their own. And then we, At stand up in the morning for like half an hour. And that's it for the rest of the day. I'm in the dark, I'm in the quiet just building code. Yeah. Instead, I socialize that I turned it into a social activity where you get to pair with, you know, I'm pairing with with Patrick and I'm joking with him, you know.
Maybe maybe we'll take a five minute break. Watch a funny YouTube video, you know, while we're working and then get right back into the game, it created the social, fulfills, the social aspect, you know, no, we said in front of computers, for eight to nine hours some Engineers, I've seen they go beyond 10 hours a day. Yeah, you know, it's really important to kind of diversify the content that is coming through that machine, you know, when you're, when you're, when
you're building software. So, that makes that made people happy, but also more important than this establishing a eex, pick tations. Okay, big station. You can't, you know, if you're an engineering manager and people are coming, Over to you and they don't know what you're thinking of their performance. Yeah. On daily basis you're putting their brain. You're kicking off a background process. That's consuming their minds and their resources.
Be like, oh, he thought he said that to me the other day. Is he mad at me? Yeah. Is a boss. Enemy major mad at me instead. I said, listen, guys. It doesn't matter what I think about. You write your contribution to the project and the impact of your code. Yeah. Is what really Determines your performance. So this way, I eliminated, this whole idea of, you know, am I in good terms with my manager or not? I canceled, you know, my you know, my leadership role. Yeah.
And I said I'm just an engineer. Just like you and based on how much impact were contributing to the project, like, let's say, Patrick created Five features and I created two features. Patrick should be rewarded more than Hassan because Patrick contributed more to the project fair and square passionate, you know, for everybody. Man, that's I love first and foremost, the pairing example, right? Because as you said pairing is has a lot of benefits, right?
It increases the quality, the code review process is innate and he creates that social aspect, right? Even when your remote I love the ping pong example I might even try that out within our team just just to figure out how things are basically and how things can be improved in that way. And as you mentioned, a lot of Engineers 8 to 10 hours behind the screen.
You know, going to be productive for those eight to ten hours, right, I don't know anyone who can do that for the full duration of 10 hours and be as effective throughout the whole time frame, right? Just constant productivity. It fluctuates. It's high. It's low. You go into a flow State and it's different. If you have that pairing going on, hearing have that communication, you're probably going to get 100%. You got you probably going to be as productive, but with what's more important?
You're gonna be more happier. Those social dynamics, those conversations are going to bring you closer within the team within the organization and within the thing, you're doing, right? There's a lot of things you look at within a team. And for me, personally, the single most important thing is, who am I doing this with right? Who are my people around me, who sits left from me and write for me in this ship were sailing basically and obviously also
who's the captain, right? And that really boils down to the trust aspect that you mentioned is Our leader pointing and shouting and be like we're going to go with that way. And if you say why you get thrown overboard that's not a ship. You want to be in basically, right? You like what is it that way and why is it not the other route? Because we all we all want to understand our kind of place in this organization or this world. It needs to make sense. We're all smart people were all
humans in a way. I think it should be explained, should be explained in a way we can all understand. And then we can just go ahead and do that full force, right? Yep. To bring it back to kind of the the engineering experience. We talked about Zelda, breath of the wild and me. That's a really great example of something that is just a pure work of passion, right? It's been out for four years now. It's 20 21. Now that's going to be 5 next
year. It has an incredible longevity and replayability and why I think because the people that worked on it, really just love what that what they've been doing. Just yeah, don't give me fell in love with it. Wanted to go above and beyond as you mentioned, It's not something a lot of people do. So it's something a lot of people say, but to truly do that, you need to love what you're doing. And I don't think there was any obstacle in their way of engineering that held them back, right?
Otherwise, they come now, and we have put that out. I don't think yeah, if they ask for something I don't think it would have been questioned as much where they would. Oh, yeah, dialogue. There was there would always be an outcome, but I don't think every single organization has that. Basically, there's a lot of walls and a lot of squares that people fit into or are put into
which is just a shame, right? We all want to work on something, we're passionate about and create the best thing that we can because then also will be happier because of it. Absolutely. And I honestly, you know, I think that whatever we're creating, you know, it's just a reflection of who we are. So if there's a team of Engineers working on a project, right?
The the the project or the product that is an comes, as an outcome of this Engineering Process, is just a reflection of the communication, you know, healthiness status between that team. If the team is not communicating with each other, you're going to end up with a lot of didn't features that. Are incomplete, or we didn't sync up with that team. Why didn't you think up with
that team? Well, we don't really talk to them much, you know, we just assume that they followed the Swagger content, communication communication, communication, you know not just because it makes better engineering teams because we as human beings, we are social beings and we like to communicate and more communication is never a bad thing. You know, a lot of people be like, you know, you know we already got the we really got the Swagger contract right from that.
Yeah, we don't need it anymore. Yeah, exactly. But if you just meant for you, just sing a team member, say hey man, how are you doing? And that's it. That's all you care about, yeah, you know more often than ever and I promise you, this happens all the time if you pink someone in on slack or teams or whatever you're using, you know, they'll say, oh, by the way, thanks for checking in. I also want to let you know that we're changing that in point. Yeah. Engineers are so easily caught
up in their own heads. Yeah. Right and they'd be like, oh, let me just change this endpoint and the later. We'll let that team know but what if you're actually actively doing a heartbeat? Right, you're saying? Hey, hey, Patrick, how are you doing? You know, just checking in today? How is everything if Patrick says? Oh, oh good.
Okay, have a good day. I already won a credit point with Patrick, you know, saying okay, I'm actually reaching out to you genuinely as a human being, you know, are regardless, whether you're my level below me or above me or any of that hierarchical nonsense. Yeah, you know, I'm just a human being communicating with a human being and we are like you said, we are on the ship. Yeah. You know. And we're trying to get from point A, to point B together. Right.
Exactly. But the other thing, the other thing that You mentioned about breath of the wild is that, you know I you know I was just showing you before that podcast. I got the book right here. Yeah. You know anal and and what one of the things that I saw that developers and The Architects on the game they were talking about, you know, we wanted to create as we play create as we
play. And oh, man, this is like you're using something and you're creating worlds, upon roles or one of on upon worlds and towns and cities and monsters. Yeah, as you are playing the game. So your How you feel from an entertainment standpoint from an enjoyment standpoint? Is your actual true guide into the next engineering decision that you're making about this game? That is amazing.
That's crazy. Yeah, you know, that's what makes this game really valuable because what they did is that they said, we want people to be emotionally attached as game, they actually enjoy it. Yeah. So if that's if that's the measure than Engineers have to play the game and put points on every, you know, it experience the they have throughout the game and try to increase that. Exactly. So this is why we keep coming back to the game because it's fun.
Yeah, I would love to see a documentary of how they pulled that off, but it's reflection of what you mentioned earlier in that when you're an engineer part of a team, you need to understand the full chain of things that you're contributing to write. If you're the End customer, it makes it so much easier because you can just pick up the game and play be like. Well, this this is not as smooth as I would hope to Be and then you can fix that, right?
Yeah. The game is a great example of that but in a long chain for example on an e-commerce website somewhere you're building on a feature and you don't even know which people are using it down the line.
How can be that attached? I think we really as either leaders or within organizations we need to kind of narrow that down write that chain and really just bring End customer and the people that are working on the features for those and customers through the bring the Gallo sir, ask them exactly. Have them communicate, they can be like, well, we're really just struggling with this thing from a user perspective, and an engineer can be like, well that's like few minutes of my
time. I can fix that for you. I didn't I didn't even know that was bothering you. And yeah, it makes sense. Right? Because then, you can be like, ha. I don't even have to say why they're already explaining it, right? They're the ones that are using it. So yeah. Why not basically then you get that one. Why not do this? Because it makes them makes them more effective. Makes them more happier and in And you feel like you're contributing contributing, right? You actually make a difference
in kind of that grand scheme. That you're a part of, absolutely. Yeah. I always say like you know, Engineers are the only ones that can tell you what's possible and what's not, you know, let's I always say this don't play telephone games between the engineers and the customers, right? Just get them both on the same table and have them talk to each other, you know, and hopefully you'll be able.
You can facilitate the conversation, let me tell you something, you might find entertaining it. If I can just, you know, hang on to this a little bit longer. So look at, look at the evolution of the tick industry right in the very, very beginning. A long, long time ago, Engineers needed to, you know, have Punch Cards and they needed to wait in line in front of a laboratory.
Someone could pick up that punch card for them and run it on a Mainframe. And when when they ride on a Mainframe, you have to come the next day. So you can get the results of the program that you just submitted yesterday. Yeah. So that's That's that little play button that people take for granted today when you click play on Visual Studio or
something. Yeah, that was, that was a 48-hour process and you needed to be nice to the person that is holding the Mainframe so they can actually, you know, get your stuff done. Yeah. So engineers at early age Engineers, had an obstacle between them, and the axis to the Machinery, the compiler. Yeah. Basically, and then personal computers were introduced to Engineers now had the Direct access to personal computers, you know, and that obstacle were removed. Okay?
Productivity increased. The next obstacle was Engineers being able to have access to the to the internet, you know, being able to deploy their stuff and all that. You know they remember a time where there is an entire devops engineers and you couldn't actually deploy your own code. Yeah. Right. You have to actually be nice to the sequel administrator and build them. Yeah. Right. So prove it basically.
Yeah I need to approve. And then cloud computing was introduced to now Engineers have direct access to provision and create their own resources and deploy. That's another obstacle that was removed. And then the last obstacle today that's holding Engineers, from actually fulfilling their full potential is Engineers having access to customers. Yeah. Right. There's always a metal guy in the middle, it's going back and forth.
Like this between the engineers, this is in no way shape or form any different than an engineer, having access to the Mainframe so they can run their code, the easier and the more faster engineers have access to their customers. The turnaround time on these features will be outstanding Beyond imagination, you know, and not to undermine the role of, you know, the people that run the business.
But, you know, you have to make sure that if you're talking ideas and possibilities, you know, you have to bring the engineers to the table. Just have to have see the customers make the connection. Yeah it's all the brains in the room that we need all the brainpower to come up with the best thing and the engineers can say what what makes sense and what make the what does Make sense, the domains domain experts cannot know the market and if it makes sense for the
company. Yes. Or no. And the customers actually know if they're going to use it and in the right way. But the way that it's intended, if you don't even know that you're going to build something and end users are going to use it in a different way, right? That's right engine. You can never predict all the all the things that can happen with the thing remediation, right. Yeah. About kind of speedrunning in in games and and glitches and you're running through walls and
all that kind of stuff. If you're new. You know, you're probably like, well, we try to block that people figured it out and we're either going to patch a, we're going to allow it, but you would never imagine that in advance, right? Yep. There's also a big portion when you're building features, there's a big portion on being able to put yourself in your
end-user feet. You want to put yourself in their shoes and be able to imagine if I don't know who that customer is and I can't visualize who that customer is. How am I supposed to build a feature that will fit like think of us as Taylor's like we're Tailoring. Suit, or a dress or whatever. Right. If I don't have access to that customer, exactly. How am I supposed to build software that will be beneficial to them and it's it turns out to be a job, you know, believe it
or not. I you probably have heard of this, you know, there are places around the world and that was to my shock, you know, there are places around the world where, you know, Engineers being introduced to the problem. So here's your input and here's your output and here's what needs to happen and they have no idea where that piece of code fits in the larger scheme of things. Yeah, as a product, see, only you don't even know where that fits in. You just know it working this
big company. Yeah, right. And this is all I know that I need to make the function work. Yeah. And even then that, if they even do that, it can still be wrong, right? It can be like, well, that's not what we meant, and you're like, but you said do this, right? You said what I needed to do instead of why I'm needing to do this?
Yeah, it's nice. And and and and then it also kind of reduces You know, the engineer an engineer brain is, you know, you know, we are 0.23 percent of the population of plants after Engineers. Yeah, represent 0.23 percent of the population of the planet and yet over half of that population, relies on the work that the 0.23 percent are doing exactly how important we are. We're doing something really important. Yeah, that looks really hard.
So imagine this. If you're telling an engineer, I only want you to solve the problem. I don't need your opinion. And you're minimizing that like if you're hiring someone that is smart, you want to kind of allow them to fulfill all the potential because that eventually will benefit the product and the company and the team. Yeah. So when you go and say, nope, I just want you as a problem, solver, I don't want anything else from you. That's kind of sad. It'll make the engineer sad, you
know? Yeah, that's a, that's a great analogy, right? Because you have say 100% brain capacity and your motor skills, right? What you're actually hand what your hands do? Understanding the code and typing the actual code that you need to implement is probably only part of that. I don't know the actual percentage, but there's also a
huge part. We can actually help with the solution Direction, figure out about why, and does this make sense from a customer perspective, what I do with different, or even challenge things, right? Even if it's explained why you can still be like, is there not a better way? Can't we do it differently? Can we do a quick win? Now versus a long-term solution versus you always have different options. Even if you're not even part of that conversation, just going to
have one option. And that's it, basically, even within and implementing it, you have multiple options. So even around the solution, there's always multiple options. So, let's just put that on the table, discuss it right, face forward, and just go ahead and do that, then that's right. And then life becomes really boring, like an engineer will say, well, if I'm just writing code here and I'm writing code
anywhere else, why would I stay? You know, it's pretty much the same thing versus and, and Talking about engineering experience the diversification of activities for software
Engineers, right? There's this misunderstanding that for you as a software engineer you're just supposed to sit here and stare at your screen for eight hours every day and only attend a stand-up meeting, maybe a design meeting, maybe a meeting where people just, you know, are angry because something didn't work and then maybe a demo right instead, what if we made you know socializing a fundamental
systemic integrated? Tensional aspect of your day-to-day work Mina. I am pairing with Patrick today that say, you know, Martinez, our customers are going to go. I'm going to go to Mars. Mmm, the say, Hey, you know, I, you know, my team is sending me today to kind of sit down with you and understand your needs, right? You know, I can't explain to you how happy Engineers are every time you tell them, hey, field trip. Let's go. See the customers that are using
our systems. Yeah. Right. Because they start saying oh, well, you know, this is my stuff people. Actually using my stuffing, it brings a little Joy and happiness to an engineer. So, versification, let Engineers sometimes by the way, you know, a lot of Engineers probably might understand this, but for the people who don't practice software engineering and they want to understand our world just because an engineer is not writing code, that doesn't mean
they're not working. It means that they're internally thinking about the problem. Have you ever been playing a video game but in your mind? Hmm. How are we gonna move the data from point A to point B you know have you have you ever been trying to solve a problem and
you stood up? Up and he just went for a walk and when you came back, boom, here's a solution because internally, you're still thinking about the problem and that's not like software engineering is not an 825, kind of job if you're facing a problem. It's consuming your brain around the clock, right? Yeah. So, if for sure. And I mean, the best Engineers are very aware of that, right?
If I'm completely stuck and I'm like, I don't see it, I really do not see it, I don't understand it right now means I'm done for the day. My brain is fried, let me go for a walk. And then the next day I come back at it and I'm like, man, it's clear as day. It is here. Yeah, exactly. Right. And does that mean I'm not productive know? I'm still kind of figuring things out or I'm recharging, right?
Even though that recharge, that walk of fresh air switching up the activity, as you coined it, that's really helpful. And it's hard to measure. Then, how productive are you throughout the day? It's across a nine-to-five. Even, I think the remote work really helps because people Are night owls? Can just really do their stuff at night instead of in the morning? Yeah, and it depends on a person, right?
How they are productive or what works for them, is different from from everyone else, I guess, because we're still dealing with people and their preferences and their that kind of own way of working away. So, let me write, bring it back to kind of streamlining, the engineering experience. I want to do a scenario in which I have an engineering team or I'm part of an engineering team. And I have a product owner and and they're just really pushing features, right?
And I'm seeing some issues within the things that we're doing things can be streamlined. Things can be optimized, we don't get enough time for our testing framework, for example, or even our bill times can be faster by. I love seeing those Twitter posts by buying the latest MacBook Pro, exactly. How can I really just communicate that we need this, right? We need to be more streamlined if we want that that velocity in
the future. Is kind of the product people which are like, no, no, no this feature and right now, please. Yeah, so, so here's the thing, this is, this is something I've been seeing, you know, almost in every other team. I joined, right. You know, streamlining, you know, being able this, the certainty, the certainty Patrick, you know, being able to wake up in the morning and you're not worried about, you know, what are you going to be
hit with today? You know, to stove and and this this ambiguity and vagueness, right? Okay, so so one away. Yeah, it brings up some weird. Yeah, he's right. I get that. So, so, so one of the biggest things I started to realize is that in a lot of different software engineering teams, there is a lack of standardization. Hmm, the standard being able to go and say, hey guys, let's agree. How we going to build integration points? Let's agree. How we going to build processing?
Core Business. Logic UI components. Most of my effort. A lot of people. Hassan, you created this and this and this, until like, my True Legacy is actually that standard the standard. It's on GitHub. It's open source. Just go find it. You know, for people watching us, you know, the standard is a flavor like you, you'll see a lot on YouTube. People talk about oh the Memento pattern and you know dependency injection. But their old teeny tiny things that are not connected to each
other. Yeah, so what I decided to do, I win and said I'm going to build the full framework and entire engineering standard that walks you through the process of Building industrial solid software from the moment you're in the ideation process and purposing all the way to
production. Yeah. Right. And then I started going into every team and saying hey guys let's bring certainty to how we want to establish a pattern of developing components for our system because that will help us in the long run, be able to hit the ground running and deliver features and not have to have take debt and issues in our system, right? The beautiful thing about standardization especially in. After industry is that, this is what I love about this industry.
You know, there is no holy men in the software industry today you would be right to Morrow, your opinion is not worth doing that Cults. Exactly, right. Yeah, which is really important because the only thing that's constant in our industry is, you know, inconsistency like things change all the time. Yeah. And if you're going to standardize, you're going to have to be having open heart and open mind, you know, for people coming back and saying, let's do this better.
Yeah, let's do this better. So, you know, every single engineering team, I go into, they be, they say like, oh no, there's a better way. We can actually build integration points, Brokers or services or controllers, or UI components. And I keep adding that and modifying my standard over and over and over again. Yeah. And then you get to the point where you have to sit down with the business people and say hey guys you know here's the deal, I know you want these features
right now. Yeah. Right. But you know, there are Risks that have to be baked into the delivery of the process like a. I don't know if you're familiar with the word. Robert C, Martin Uncle Bob, you know, clean code clean coder. He's a very is one of the people that invented the agile methodology among 17 or 18 people. One of the things that I used to say is that, you know, you need to bake in the streamlining process in the feature cost itself. Yeah, how is that working?
Let's say a certain team is building an API. In point and their API endpoint is in.net 50k. And now, the business are coming in and they're saying, hey, we want this new API that will allow us to kind of search, you know, through our database, you know, with a fuzzy. Search sure? Okay. Yeah. If the team's plan to upgrade to.net 6 so they can stay up-to-date and take care of security patches and all that. That should be baked into the
feature itself. Now, process of no be like, well, it's going to cost ten days. You know, and here is what these 10 days. Tasks are going to be upgrade to. That net6 is step one. Yeah. And then build your actual feet version is, there is so, and believe me, the business is not going to go like, no, you can't upgrade to that next dotnet six. They'll be like, okay, if that's what we need to do now, to get that feature done.
The problem with, with some Engineers is that the actually go to the business and they tell them, oh, we're going to rewrite everything. And you're not going to get any new features. Yeah. And six months from now, that is that is the worst thing. Thing you can say as a software engineer because the business person is communicating with the person who's writing the chicks. Now paying money, the person who's paying money is saying.
Okay January, we have three features, I expected in June, we going to have 20. Yeah, so if you go to that person that's paying money and tell them hey in June you going to have zero features but you're going to be running on dotnet 6. They'll be like listen man, I don't want this, they will just tell you that I don't want this, you know, instead you know what? If you went to the business person and said, okay we can't get to 20 but we can get five or 10.
You know, at you already baked in that streamlining process. Let me tell you a nice story, you gotta find entertaining. There was a team that I went into and the team basically they had a really crappy system like that really Legacy like the kind of system that you look at and start thinking seriously about Quitting your job and being a Walmart greeter, right? Look at me. Like that's it. That's the end of my career. I'm done here, right?
And when I talked to the engineers on that team, they said to me, well, there has been so many different attempts. Yeah, the modernize right. They said, they haven't been to many many attempts to modernize, right? And, you know, it just got shut down because there's no funding, right? So I said to them, okay? What do you guys think about building another system in parallel? So we're rewriting from scratch, but we're building this new system in parallel.
To Target new scenarios. A new customers that the current system doesn't have. Okay. Interesting. So so system be, yeah, is doing the exact same pipeline that business a is doing, but instead, it's targeting more features. So, this way, business is Happy business saying, wait a second. We're going after, you know, category A and B and C, which is the current system can't do. Yeah. Right. But at the same time, you're building the exact same pipelines.
That system is doing. So, as soon as this feature is done, you can shut down businesses. Have to engineer the Engineering Process, the communication, you know, if you don't do that, you know, Engineers will forever have conflicts with business because they were like, oh, these PMS are not real people, why you're like, well, I'm telling them we need to upgrade without knit six and they're not listening to me. Don't get it, right? You're going to have to change the language.
Just like I tell people, you know II, this is how I explained to software engineer say, okay, if you're on a sequel server, are you going to write in C, sharp or sequel? This, I know I'm going to have to ride in sequence and okay. What if you're on bash that I'm going to write in match? What if you want? Power shell, I said, I say, two Engineers treat pulled the exact same way. If you're talking to a p.m. you're going to have to speak money and you have to speak business.
Yeah. If you're talking to an engineer, you can speak architecture and patterns. If you're talking to a marketer, you're going to have to blow their minds with the latest. And razor, your marketer doesn't care. If you're using string interpolation with a plus sign or your intraplate. We don't care about that. Yeah. But we, but do you know what they care about?
They care about how amazing Easing and fast that new feature that you're building and how much Market can it gained out of that, you have to speak the language of every certain group of people and then you end up with, you know, as an engineer, you end up with being an entrepreneurial Innovative engineering, someone who can talk to everybody but also can build systems on the background. That's the ultimate live.
If you're an entrepreneurial Innovative engineering my book, yeah, you are unstoppable Force. Exactly. You get shit done. Basically, you were lying people in the way you think, is the Best that ain't could be your own thought or a collective thought. That's how you get it done. I love that. You have the contrast right of being like, well now it's too late. Now we have to upgrade, which means a few works of few weeks of only check that, right? Yep. Versus the already baking it in
along the way, right? It's an incremental process. You can see kind of the output, your external quality being the thing that's customer-facing and the internal quality. Kind of the, what's underneath The surface, right? If you only see, the tip of the iceberg, there's a guy that can be a huge Iceberg under the water, and you also need to maintain that, right? Standardizing, it is the start
but then it's incremental. You can be like this can be more efficient, this can be better, this needs to be upgraded, so why push that backwards? In terms of, I think feature fulfillment versus already baking it in. I yeah, already bacon that estimation be like, well, this is a requirement otherwise we can't really do that. Otherwise it is going to hurt us in the long term.
And if it's incremental, then you don't need to catch up because really upgrading and not doing any feature development, not delivering that value for the customer is a catch-up. That's, that's kind of a reflection of it already having gone wrong in the past. Basically, that's truly how it sounds to me. You know, what? You know who I saw do that mechanics people who fix cars,
right? If you go to a mechanic and they tell you, you tell them, oh, please change the tire and they discover that like, maybe there's a dent in your car. Yeah. You like, hey, I also fixed While I'm at it because the, your car needs to be, I need to change the tire by found the bolts, maybe the bolts on your tires, not in good shape. So, I change those as well. They bake it, they do it automatically and these guys, you know, they don't even need to actually have the
conversation. They're just telling you, Hey, listen. And you want me to fix your car. I fixed your car and that's what it took. But, but on the topic of tech did, you know, I had to come up with a new pattern called code, rub code. Rob, you know, when you rub glasses, your cleaning glasses and stuff like that. Yeah, Code Red.
Rob is basically the idea that every single person on the team needs to take 15 minutes every day to look at one file on the project, whether they need to change something in it or not. Interesting. So this practice every day imagine you have a team of eight Engineers. Yeah, right everyday in the morning. Let's say before. Stand up they take 15 minutes and say let me take a look at the file that I haven't looked at before. Yeah, I lay me see.
Can I either clean something real quick in that file or, you know, File is in good shape and I can just mark my task done. You know, what I discovered by the end of any project, you end up with zero, take debt because we're not just going after things that we need to do. We're looking at files that we think are okay. No, you know, and we discover new changes. This is why I always say.
Your engineering standard is evolving, you need a systematic daily intentional, continuous routine that makes you look at the code every single day, whether it has a problem in it or not, Yeah, and it has a lot of residual benefits as well, and that your mental model of how it actually works, gets gets honed as well, right? If you build something, and we're not pairing, I'm probably not going to see that, unless we do kind of a tech demo of how it was built, etcetera, Etc.
So the next I'm going to see that is probably either when you're gone or you're not building the next feature on top of that. And all of a sudden this me and I'm like, man, this could have been done differently or what is this? Yeah, you know there's no comment or documentation how does this work? But if you seen that in advance, you can ask questions, you can improve upon it and you get that mental image of, of how the
codebase actually works. And if it reflects what actually needs to do, which is a different thing as well. So, back to the social social activity, if you're looking at a code, a file that you have never written and you discovered all the variable can be done better and you create a pull request for that change. Now you're striking a conversations about things that are not necessarily too hot of a top. Topic.
But it gets you going with the person who wrote that last line of code while they're reviewing it. You know, you end up with zero check that you have nothing to build on top of which streamlines the engineering experience in a ways. Man. I'm telling you this from experience, it makes things so
much easier. People are familiarize with the code, you know, every time there's an engineering standard change, they can change that real quick because they're already blocked this 15 minutes of my day to sit there and make sure our code lives up to the latest and greatest standard some Change in a, in a c-sharp language or python or whatever.
I can adapt that real quick. Your team is in a continuous state of, not just learning new things, but their act, you know, practicing it, you know, they're actively learning and growing with it. No, that's engineering experience with friends on. I think, I think I'm going to try that out and I really liked how this conversation went, right? Really just the benefits of streamlining that that experience. When you can't communicate it, how you speak that language?
Right, you need to adapt based on. Even the programming languages take that with you and use it versus the people, you're talking to right the different departments, their own agenda and really find it a win-win by a win for you and a win for them. That's the best outcome really reminds me of that one scene in the office, but that's besides the point, uh, you know, you know, the one I'm talking about. The series. Okay, okay, okay. Yeah, yeah.
It's the win-win-win-win-win. And when we accomplish this is not ideal. That's what he says. But yeah, and really just just fighting for it, right? That's how you become happy. That's how you have the joy of what you're doing as engineer and I think the company in the product becomes better of it as well. Is there anything we missed or anything you still want to touch upon as kind of a last thing? Form an inch from an engineering experience. Just just one more thing to add
on top of that. You know, when you go home, you know, you talking to your parents, you don't go tell them. My job is to, you know, build, you know, connections to databases and stuff like that. You just tell them I built software. You're speaking a language that they can understand what I big Engineers do that to actually incorporate that and their day-to-day activity interactions with other partners, you know in the business are not necessarily engineer, you know you know savvy.
Or software Savvy or tech-savvy people, you know, and try to incorporate that. If you do that, the last thing Patrick that I really incorporate food, eat food with your team, you know, I know. I know it sounds weird and it sounds weird coming from an engineer who thinks like, oh, you know, we just need to build systems, but something. Something strange about getting together with your team on an unnecessarily software development activity. Yeah. And just eating food.
With your team. You know, just having a little laugh and try to detach from the day work for a short 15, 30 minutes. Yeah, just you know, hey guys, you want Chinese. Let's go eat Chinese food. Yeah, you know and it's just, you know, it's on me the day today, it's on me. Let's go and eat together and see how the day goes. Yeah. That's like you're living, you know what I mean? Yeah, you really speaking my language, I love food and I think the best thing the best conversations Arise at the
table, I'm a slow eater. Which means, the reason for that is because I talk a lot and it's really just that communication. So different setting different Dynamic. You truly learn about people and have a great meal as well. Yeah. And food for some reason food taste better when you're eating with people, it's looking good. Meaning an accident. Yeah, you're just enjoying it and your brain is, you know, being active.
You know, I'm pretty sure there's a nerd out there that can tell you why food tastes better with people, but all I know is that it just tastes Better, and, you know, doing things with people in. Normally, this is what I say to my team. I say it doesn't matter whether we're building software or making cookies. Yeah, that's focused on building relationships. Exact, no, because here's the thing, Patrick, any software out there, I don't care how great that software is.
Inevitably a will turn into Legacy and it will be Rewritten. Now the you know, what hasn't the relationships that you developed during the process of building that software? Yeah, that doesn't go away, you know. Yeah. So you need an invest in that as a first class A citizen as much as we invest in the quality of our code. Yeah, I fully agree. I love the analogy of the food. Taste better based on the
experience, right? The setting, the people, the things that you're doing it with and the developer experience is just as important, right? The thing that you're actually building becomes better because of the experience around it, I think that really just fully ties it together at the end there. Yeah, I love this conversation. A son I want to really thank you for coming on. Thank you sir. Appreciate you. Phone food, the best. I should, I should I ordered a
pizza? You know, just you delivered all the way over there. Yeah. And Homeland and I got my own pizza here, it was raised some eyebrows. Eating pizza after midnight, but hey you know you only live once YOLO. Let's just do that and would have the same eyebrows here in the morning at 8:00, but yeah. Cool.
Yeah, let's send it off there, then us on Habib, check him out on Twitter. Youtube everywhere we'll put some some links in the description and again, thank you for coming on. Thank you guys. I appreciate you. You have a good day. Have a good day. Everyone else unhappy very one creating digital leaders.