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.