As people, as individuals, we need to change our ways of
working, where we give importance to the work that we
do in terms of the quality that we deliver and ensure that we
keep raising our bar. So software craftsmanship is
something that we need to work on as individuals and also pass
it on to the next generation of developers who work with you in
your respective organizations so that they get to learn from you.
I mean you lead by example. Hey everyone, my name is Henry
Surya Virawan and you're listening to the Technically
Journal Podcast, the show where I'll be bringing you the
greatest technical leaders, practitioners and thought
leaders in the industry to discuss about their journey,
ideas and practices that we all can learn and apply to build a
highly performing technical team and to make an impact in your
personal work. So let's dive into our journal.
Hey everyone, you're listening to the Technically Journal
Podcast, the podcast where you can learn about technical
leadership and excellence from my conversations with great
thought leaders in the tech industry.
If this is your first time listening, don't forget to
subscribe on your favorite podcast app to get notified for
future episodes. Also, subscribe to Technically
Journal's various other contents on LinkedIn, Twitter, Instagram,
YouTube, and Tiktok. And if you have been enjoying
this podcast and its contents, support my work by either buying
me a coffee at techledjournal dot dev tip or becoming a patron
at techledjournal dot dev Patron.
My guest for today's episode is Srihari Sridharan.
Srihari is a software architect and the author of Craft Your
Code. In this episode we discussed
software craftsmanship and how to become better software
engineers. Srihari first began by sharing
the relationship between software craftsmanship and high
quality code. He described some practices for
improving code quality, such as establishing coding standards,
improving code readability, doing effective code review, and
managing technical depth. He also explained the importance
of software engineers understanding different
architectural styles and domain knowledge.
Srihari also shared strategies for creating high performing
teams. By establishing psychological
safety and trust. I hope you enjoy listening to
this episode and learn some insights about software
craftsmanship and becoming a better software engineer.
If you enjoy listening to this episode, please share with your
colleagues, your friends and communities and leave a 5 star
rating and review on Apple Podcast and Spotify.
Your small help will help me a lot in getting more people to
discover and listen to this podcast and I really appreciate
it. So let's now go to my
conversation with Srihari. Welcome to Technically Journal
Podcast Show. Today we have Srihari here.
Really looking forward to discuss things about software
craftsmanship, how to make your software quality higher and
things like that. So welcome to the show, Srihari.
Hi, Henry. Thanks for the opportunity.
So Srihari, in the beginning I would like to ask you first to
share your career journey. Maybe if you can give us some
highlights or turning points that you think we all can learn
from you. Sure, Henry.
So I'm close to two decades of industry experience working
across different products and services organizations I've been
in both in product development as well as in the services side
of things. We're doing consulting with the
clients on different domains and trying to solve complex
problems. So that is my journey across
this two decades across seven different operations.
And apart from my day job, I do reviews and proofreading for
Manning publications, which I started back in 2017.
So I get to review the titles of interest and try to proofread
them and provide feedback to the authors and closely interact
with them. And that is why I think we also
got connected through LinkedIn discussing about books and
stuff. And apart from that, as a pro
bono activity, I do connect with the university here in Chennai
where I get to decide the curriculum for the students who
are doing engineering as part of their studies.
So this is to bridge the gap between the academic curriculum
that is there today and what the industry actually wants.
I mean, the curriculum should actually help them in two ways.
Either it should help them find a job or help them for their
higher studies. So I'm just trying to bridge the
gap because the industry is very fast moving and there are a lot
of changes that are coming our way.
So that's the idea, Henry. I mean, that's a short summary
of what I'm doing. This episode is brought to you
by Miro, as you will hear in this episode later about the
power of mind maps and note taking finding a tool that can
support creating comprehensive mind maps.
While also supporting collaboration can be quite a
challenge, one tool I find that allows us to do so effectively
and in a fun way is Miro Miro. At a first glance, it might seem
just like a simple digital whiteboard, but Miro's
capabilities run far beyond that.
It's a visual collaboration tool where the whole team can build
on each other's ideas and create something innovative together
from anywhere. Brainstorming and strategic
planning become easier when it's visual and accessible, and it
can all happen across teams. In mirror, you can quickly start
collaborating within 90 seconds without having everyone
registered as a mirror user before.
There are also more than 300 predefined templates you can use
to kick start your collaboration within seconds.
So the next time you are looking for a digital tool to support
your brainstorming, designing, planning, and online
collaboration. Do give Mirror a try.
You can Sign up today at mirror.com/podcast,
miro.com/podcast, and your first three mirror boards.
Are free forever when you sign up now.
And now let's get back to our episode.
Thank you so much. Very interesting.
You have a day job in a consulting company.
You also review books, right? I think you you are part of the
reviewers of many great titles from Manning.
And the last one you do pro bono for university.
So maybe a little bit, if I can ask about your pro bono part,
right. So you have been helping the
university to bridge the gap and you are also now the author of
the Craft Your Code. Where do you see the biggest gap
between university students and also from the practical side of
view, when they go into the job as a software developer?
Yeah, that's right. I mean, things have improved a
lot in the current situation. I mean, a lot of students get to
study about programming languages and stuff early in
their school days. When back then when we used to
study, probably we were not so lucky to read programming
languages early. But again today I see students
are reading much earlier. So what happens when they come
to the university, the subjects so need a revision.
I mean revision in the sense what is going to make you do
things practically, like how will you be able to work, apply
your skills that you learn in the industry, how you get
industry ready because the industry is moving at a very
fast pace. Given that you have generative
AI and other stuff today, how do we equip students to adjust to
the new curriculum? Forget students, even
professionals, as we need to adjust ourselves to the new
modern world in terms of the current demands, right.
So that is where I tried to look into the existing syllabus that
is there in the university and try to work closely with the
professors and the lecturers out there.
Trying to share what to do from an industry perspective and what
are the industry trends. And see if we could incorporate
certain subjects in the curriculum which actually
bridges the gap between what is there and what is there today.
So for example, when I studied, we never had papers on data
science we know as such data sense did not exist back then,
but data warehousing, other stuff was there.
I'm talking about 20 gets ago. So data warehousing was there,
database were there. I think we were lucky enough to
grow along with the languages and frameworks.
But today, those who get into the industry, they have a huge
mountain to climb in terms of learning, because every language
has become very mature, every framework has matured, a lot of
features have come into the frameworks and languages and
there are a lot of streams as well.
I mean, we are looking more at specialization, right?
I mean, the subjects and the streams are getting very
specialized from a education standpoint.
So that is when we need to see the bigger picture, give them
the bigger picture first of all, like give students a picture of
what exists, what you can choose from and where do you want to
place yourself in the overall journey, right?
Maybe towards them. When we discuss about
architecture, we'll discuss about the importance of having
the bigger picture, right? But the essence is how and what
exists. Because when you take the
triangle of knowledge, right, there are things that you know,
they exist, and there are things that you know but you don't
know. Basically, you don't know that
such a thing exists, but you know something exists but you
don't know about it. And the third thing is you don't
know and you don't know. You don't know what exists and
you don't know such a thing exists, right?
So to help students start with things that they know they exist
but they don't know about it and try to educate them and bring
that awareness and take it forward.
So that's the idea of bridging this gap, Henry.
Yeah, a little bit empathy as well for those students or the
new people who just graduated, right?
So there are so many things in technology these days, right?
You just mentioned generative AI.
Maybe that's the buzzwords this day previously.
Data science, right, Previously blockchain and so many other
things that keep coming along, right.
I think it's really, really a big challenge for all those
people, including me, myself. I can't keep up.
With all these changes as well. So I think your work is really,
really tremendous in terms of helping them bridging the gap.
So moving on to maybe that's why you write this book, right,
Craft your code, because I, I had a look and read off your
book in a glance, right. So you cover the breadth of the
technology from software engineering point of view,
right. So maybe if you can share a
little bit what was your motivation behind writing this
book, right? So maybe we can learn from that
story itself. Definitely.
So one cool thing that happened is it was back in 2018 when I
was actually having this idea of writing this book and just to
explain that journey, right? I would had the idea, had the
proposal to write the book. But again, maybe I wasn't so
popular. I would say like I did not have
enough connection in the industry or the publishing front
where I found it difficult to actually sell this idea of
writing a book on Crafty Code. Because you have industry
stalwarts like Robert C Martin who wrote Clean Code, you have
Steve McConnell who wrote Code Complete, you have paid good
life, who wrote Code Craft and a lot of things, right?
And when you as an engineer, as a person want to write something
about it, I mean, all of this is about your experience.
Again, knowledge is borrowed, but the experiences are unique.
The experience that I wanted to share in this book was about
what I went through as a developer during my early days,
what I learned from my mentors, and what I learned from
experience. I just want to share that
knowledge with others and make it available.
So that is the whole motivation of actually coming up with this
idea of writing a book. And I wanted to make it a
polyglot in the sense give examples from multiple
languages, right? Actually, I'm working with
Manning on a proposal to actually write a book on the
next generation offered Crafty of Good with Generative AI where
I tried to explore the possibilities of using Gen.
AI for software development and traffic code.
So that's the idea. Again, it's in the service
stages, so I cannot comment more on it, but the idea is about
sharing that knowledge, which is the core.
And as you know, authors don't write books to become rich.
They intend us not to make money, but the intent is to
share the knowledge. So that is the background of
this book, Henry. Yeah.
Thanks for sharing the background, right.
So, yeah, I mean, for people who don't know yet, authors write
book not to get rich, right? Maybe some authors do because of
the royalties and all the other things outside of the book,
right. But I think the first thing is
about instilling their knowledge and share it with other people.
It's also about the legacy. Yeah, Sorry to cut you.
I mean, it's also about the legacy, Henry.
I mean leaving behind something for others to consume, right?
That's correct. And also, yeah, like you
mentioned, I find something interesting about your book,
right? You actually use Polygon
languages, right? So this is I think quite rare as
well. I don't see much technical books
also using multiple languages. There's pros and cons to that.
But I think, yeah, this is quite unique in, in a sense.
So if I read. Your book I think, if I can pick
a theme, one is about software craftsmanship and the other one
is about high quality code. So maybe if you can touch on a
little bit from your industry experience 2 decades, right?
Well what do you see? Why it is important for
engineers to look into the aspects of software
craftsmanship and also high quality code?
Definitely so the first thing, right?
I mean writing code that works, I mean that's very lowest, but I
mean anybody can cross that path of writing code.
Again, writing code that you yourself understand after six
months of being in a project or somewhere is vital.
I mean you're not going to do a good to others, but do good to
yourself by writing some clean code which you can understand in
six months time, right? I mean as as prominent authors
like Robert used to say, so the essence of a software
craftsmanship. As such, if we just rewind the
whole 2 decades of the industry or three decades of it, right
back then we did not have cloud, we did not have sophisticated
systems, we did not have lot of RAM and lot of processing power,
We did not have SSDs, right, We did not have anything.
We did not have powerful IDs. But today we have all of them.
But still projects fail. Still the cost of software
development is pretty high and still getting it right is very
rare, right. The success rate is like hardly
1516 or less than 20% maximum. Either it shows by budget or by
time or by any resource, right. So why does that happen?
So the problem lies with us as individuals, as people, as
individuals. We need to change our ways of
working where we give importance to the work that we do in terms
of the quality that we deliver and ensure that we keep raising
our bar. Again, here probably I would
like to quote an example of ample right.
Apple never compares themselves to other products.
They compare themselves with their own products.
So if you see iPhone 15, it's better than iPhone 14 by so and
so terms, right? I mean same way the code that
you write, the software that you write, the development, don't
compare with this, just compare yourself with your own work,
right? Try delivering better quality in
terms of the code that you write, the documentation that
you generate, the attention to, detail that you provide, the cab
that you take that shows how much you love your profession or
how much you give importance to the quality, right?
I mean it is all about again passion meeting profession.
It happens for a few people. At the same time you can also
use your profession to fuel your passion right either ways.
So software craftsmanship is something that we need to work
on as individuals and also pass it on to the next generation of
developers who work with you in your respective organizations so
that they get to learn from you. I mean you lead by example, I
mean all of these principles you'd have seen in management
books. I'm just trying to connect the
dots how from a software development dangle and a
craftsmanship dangle. You can lead by example and also
learn from them. So learning is always a two way
St. the fresh minds who come into the industry.
They have a fresh perspective looking at the code in the
system and they can do their feedback.
So be open to feedback. So learn from people who are
younger than you. They are much faster in learning
something than you. Possibly you might have the
experience but they have the speed.
So instead of competing it's like complementing each other
together you solve a problem right?
So that is my view about software craftsmanship and
writing clean code. Right.
So I think when you explain that, it intrigued me, right,
the fact that the technologies have moved so advanced so
rapidly. We have so many choices,
programming languages, cloud, infrastructure, I don't know, so
many exotic things happening, right?
But still we have the fact that projects fail, The cost of the
project is really, really high. And yeah, sometimes it also
doesn't meet the user requirements right.
So I think it's a true fact. Plus one thing that I just want
to add, we have these kind of resources, the books that are
available since long time as well, you know, like those clean
code, refactoring, TDDXP all exists like I don't know how
many decades ago, right? But still we have this problem
that software engineering is sometimes tricky to deliver
right. So maybe in your view, right,
maybe also touch on from your books what are the some of the
root causes of low quality code. Maybe if you can highlight some
of the categories for us here to remind ourselves.
So low quantity code in the sense I mean again first things,
the code should align with the architecture, the overall
architecture, the bigger picture, right?
So that is where I mean we'll again touch upon visualizing
architecture for the developers towards the end.
But again, since you want to connect the dots, if developers
understand what they're trying to achieve, say developers are
going to be probably working on a given component or a
particular module or a feature to deliver something.
So you have a feature, a set of modules work together to provide
you the feature. So within the module you will
have players and components that interact with each other and
then you get it working right. So they need to connect the dots
in terms of where their work fits in, which actually helps
them to go ahead and deliver the feature meeting all the
criterion, the acceptance criteria, whatever you call it,
right, so that it meets the requirements of the user.
So in a sense, the overrun quality depends upon the
understanding that people have. Like the moment you understand
the problem, you can easily design it.
You can. I mean, in my opinion, you need
to invest more time in design than writing code, because once
your design is robust, translating that into the code
is going to be a matter of time, right?
Again with Gen. AI and other tools that you get
the pair programming assistance which is going to help you code
faster is what we observe. At least that's the claim today.
Again, we need to validate this claim with more data as we
practice more with this coding assistance.
But definitely they are a way forward.
We cannot ignore and move on right.
People who embrace these assistance, they will get to
code faster. So maintaining that code quality
is important. Having coding standards within
the team and the project is important and most importantly
trying to automate these coding standards.
I mean having coding standards. Not every human being can or
developer can remember all of these standards day in day out,
right? We need to see how we can
provide faster feedback by automating these coding
standards. So let's say you get a coding
standard, you have some PMD, Textile kind of stuff.
Or you have the effects COP and style copandthe.net trend.
Or some linters in terms of JavaScript and TypeScript which
provides developers with immediate feedback on code
quality. Once they get the immediate
feedback, once they understand what is going on, because
getting a feedback from a CICD server or a downstream system is
going to increase your cycle time.
Instead, if you try to get that feedback ahead of time, that is
going to be much more useful to developers.
So that's the whole idea. Thank you for sharing that,
right. I think it's very interesting
when you said that, you know, understanding is the first
thing, right. Sometimes all engineers just
want, you know, to. Straight away write the code,
You give me what you want and I'll just write the code.
But I think in so many good practices that is advocated by
the thought leaders out there, understanding the problem,
understanding the requirements, coming up with the right design.
Of course, it doesn't have to be very heavyweight and, you know,
take a long time to come up with, right?
But actually you do need to take time to actually understand what
kind of software that you want to build.
And I think from my experience as well, right, building a good
robust system, you know, yeah, you need to plan it, right?
You cannot just come up with the perfect software design by just
writing the code all the way from the low level, right?
So I think that's a very good thing.
One part I would like to add to that Henry, I mean design 1
pages are definitely helpful. I mean you need to write the
design one pager, write a wiki page or a Confluence page, which
actually helps you share your thought process with the team.
Let's say you're doing power programming as a prior and you
want to communicate your design and get it solved with your
technical lead. Write A1 pager which contains or
outlines the overall design that you're thinking for solving the
problem and also document how it is staying in line with the
existing architecture that is there right and present it to
the audience. Get to the feedback and then
probably get into coding it. Then it's going to decrease your
back and forth loops that you'll have and rework and all this
stuff. Right.
And you mentioned just now about coding standards, right?
And that we have to automate it. I think that's the first thing.
In the past I used to do it manually.
So I think it really, really relies heavily on your brain
power, right, to actually align with the coding standards.
Don't do that, right. Use automation as much as
possible. And I also find something
related to standards that I just want to highlight from your
book, right. You mentioned that high quality
code. If you follow the coding
standards right, it is as if written by a single developer,
even on one file that is, you know, modified by multiple
people. So why I said that?
Yeah, I can explain you. So one of the important thing is
consistency when it comes to looking at code.
When it comes to aesthetics of your code, our brain usually
forms patterns. Take this example right?
You see somebody, say your childhood friend, after 10
years. You are able to recognize this
person, right? Hey, how are you?
So how the brain works. It works based on pattern
matching. So it matches the pattern of the
person and the kind of calculates, OK, this is how this
person looks. Now I can see the resemblance.
That resemblance is the important factor with respect to
code in terms of familiarity. And that familiarity is nothing
but standards, right? You see a piece of code that
adheres to a standard. You know what it does, how it
does. Easy to read.
Let's say you have certain ways of structuring your conditionals
and loops and all this stuff. The fundamental elements.
Even though let's say for example you write streams or
link code and streams in Java and link in C#, the way you
formulate your query and the way you write your query, right?
Imagine you write a SQL query. If you put your columns in a
single line, it's going to be very difficult to read
everything. Instead, if you put them in
different lines, one column name per line, and then write the
select statement with one join per line and then formulate it
accordingly, it helps you to easily grasp and understand the
concept of what you're trying to do because code is written once.
A study that claims that the code is written once for 310
times. So this kind of a pattern
matching is crucial for understanding your code.
And now when it comes to the standard, at times you get to
modify legacy code. Legacy code in the sense a code
that is old are brownfield applications for that matter,
right? I have huge respect for legacy
systems, I'll get to that shortly.
But when you see the brownfield code or existing application,
the best thing that you can do is to adhere to the standards
that is there at that particular file level at least.
Minimum the file level because that is the consistency
boundary. I look at the code 1 file at a
time. So you can at least ensure that
the minimum amount of consistency is maintained at the
file level so that the key is to be consistent.
The reason is, let's say you want to fix something.
You can go and fix it in all the places in one go because you
know the consistent pattern where it is written in a
consistent manner and let us say that needs to be addressed.
You can go and address it. When there is lack of
consistency, it's going to make things difficult.
There is another angle to consistency, which is following
industry standards. Why should teams follow industry
standards? Because let us say you have a
new person joining your team. Now this new person joining the
team is going to be the lowest common denominator.
So when you communicate something, when you share
knowledge, when you discuss about your problem domain or
discuss about a solution, you need to ensure that this person
understands. That is why you build a
inclusive environment where the person understands this whole
thing so. Doing something that is
consistent with industry standards and maintaining the
consistency at the file level to start with and then at the
project level and then at the code base level will help you
ensure that people can quickly come in from outside and grasp
and start being productive. So that's the reason I wrote
about that consistency boundary within the file.
And then you slowly expand it to the project and then to the
entire code base, right? So that's the idea.
Yeah, it's very interesting. And you mentioned about
consistency boundaries, we're talking about how to write code
consistently well, you know, within your code base.
So I think that's really, really powerful, right, If you get it
right within the team and it will be even more powerful
within the company, right. I know that in Google, right,
they all have this coding standards, they can automate it
and it's a safe ride. The whole company is written by
same kind of styles and same kind of a people, right.
I think that's really, really powerful.
And you touch on a little bit about aesthetics part of the
code base when you say about you know formatting your stream or
maybe the way you write queries. So maybe not all software
engineers are taught about this aesthetics part, right?
Maybe a little bit touch on elaborate more why aesthetics so
so much important? How can they start doing it
right? Sure.
I mean, aesthetics again ties down to your visual appeal of
the code base. So as I mentioned earlier, I
spoke about pattern matching. So there is a very good book
that I would suggest folks to take a look at which is Thinking
and Learning Refactor Your Hardware, which is about how the
brain works and the pattern matching and all this stuff.
So the moment you have that consistency and the way you
layout your code, say for example all the variables that
are used in a class, say in object oriented programming
paradigm should be organized properly at the top.
So, as Robert C Martin calls it, he also gives that newspaper
analogy right when you read a newspaper article.
He speaks about having the various gist of the news and
then going into the details of the time summarizing.
So people who have a lack of time, who are not so interested
in your news, they're just going to read the first paragraph or
the headline and probably move on.
Those who are interested will dive deep into it.
The same is applicable to the code.
When you put your public methods that are implemented by an
interface or this particular class that implements the
interface, you're going to have this at the top of the file, so
you clearly. Demarcate and communicate like
this is what this class is doing.
These are the responsibilities class and if somebody is more
interested, they'll probably drive into the stuff that is
below, which is the private methods and other stuff, right?
So aesthetically you need to organize your codes as that if
the concepts are well encapsulated, well split within
the file. So let's say you have a class in
a file and then you have the members, properties, methods,
the construct of the methods and then the private methods.
That is a neat way to organize it aesthetically, and the
aesthetics also boils down to. Putting things together in terms
of stuff that is related and putting things that are not
related separately, in a sense, let us say you're trying to do
something within the loop, or a for loop or a while loop or
whatever, right? What we are doing within that
loop is a very kind of a closed construct, right?
What you're trying to do within the iteration, what is outside
of it? If you leave a blank line next
to this, loop the line very dense and then leave a blank
line and then start the next possible line clearly gives you
a separation between this. On the next concept that is
coming up right, so the same is applicable to if blocks, else
blocks, switch cases and all this stuff.
All this constructs. So anytime there is an
indentation, the indentation that takes your code towards the
right. If you take Python, there are no
brackets, it's all indentation right?
So the way you write your code it should be.
There should be a clear demarcation between these
concepts. So that is your vertical way of
organizing your code aesthetically when it comes to
horizontally organizing, as you might know.
Living spaces between operators and variables and then
assignment and variable living spaces wherever required.
Writing the comments in a very clean manner in a very concise
and understanding. And all of this boils down to
aesthetics. So visually when you see the
code, when it is aesthetically pleasing, it is easier to work
with it. It's welcoming for the
developers who are new to the system rather than that.
If your code is not visually consistent or aesthetically
pleasant, then probably you take a step back and say OK, it takes
me some time to understand this. So make your life easier, right?
I mean, make everyone's life easier.
After all, software development should be fun in my opinion.
So giving importance to aesthetics is really crucian
when reading code is done more frequently than writing it,
right? You mentioned about visually
appealing. I think it also helps a lot for
your cognitive load, for your brain, right to actually read
the code because or you mentioned that the code is
written once, read 10 times or even more, right?
So you you need to help yourself, right?
In order to actually understand what you read.
I mean another thing, right? It's about writing code that is
understandable by everybody. Meaning say for example, why are
we using English in programming more?
The reason is English kind of is a widespread language that many
of us understand, right? At least the majority
understands English and using variable names that can be
spelled properly is very important.
I mean, back then we had challenges with memory and other
things where we used to shorten the variable names and a lot of
the things in the past. But given that those things are
no more a problem even you have typing assistance from your
Ides, even if you give a meaningful name, it is not very
hard to type. You just put a control space and
the command space and move on right.
So giving meaningful variable names that are readable is
crucial for understanding your code.
I mean naming as you know naming and caching.
The though important problems are difficult problems to solve
is when to invalidate the cache and naming things right.
So naming. Definitely invest time in giving
proper names and never. Worry about revisiting your
names. Meaning once you name something
the way you get a better domain understanding down the line.
You need to revise your ubiquitous Language from a
Domain Driven Design standpoint to see if a better word or a
better term unveils that meaning in a better way.
So that is another piece of input I just want to add on,
maybe as part of the aesthetics, right.
So the few things that I feel some engineers do not actually
realize yet are actually powerful.
So things like vertical new line, like you mentioned,
vertical space, sometimes just adding new lines in between some
sections of your code, actually, that's really powerful.
And the second thing is about maximum width that you can
expand to the right, right. So I think some teams actually
enforce the maximum width so that you don't scroll to the
right. I have some interesting stories
there. So Once Upon a time, there is
one of the developers who I was working with, two stories in
fact. One is one of the developers who
I was working with. He used to write very long
methods. I mean this is back when I was
in US. Like I used to ask him why is
that your methods are long. Then he told me like, OK, my
methods are long because whenever it crosses my screen
limit, I tend to break into a new method.
OK, that thing should be a very interesting yardstick to break
into a new method. Then I thought even then you
should be breaking it. So half the size of it, or even
3 by 4th of it, Why are it taking so long?
Then I went and visited his desk.
So he had the monitoring portrait board where the monitor
was actually in a portrait board and he was trying to break a
line where it does the next screen.
So I mean, well it might sound funny, right?
I mean, the most important thing is to add it to single
responsibility principle, right? Single responsibility is not
that it crosses your screen limit, but instead try to see
how to have a well defined responsibility for a given
method that you're writing. I mean, don't do more than one
thing, as Roberts is. Another instance was I was again
working with a set of folks who actually write long lines which
make you scroll to the right and then read the code and then come
back. So it feels like you are doing
typewriting work where the head goes to the right and then comes
back to the reset. I mean those who have seen
typewriters. So the comment that came was
like, I was asking like, why do you do that?
There are very wide monitors. We don't find any challenges in
working with such a code. It was like, OK, you might have
wide monitors, but doesn't mean you should make others suffer.
I mean, some people might have smaller screens, right?
Not only that, I mean, research has shown that beyond the point,
the cognitive load increases when you keep scrolling and
going back and forth and then all of the stuff, right?
When you write long methods or when you write horizontally long
lines, cognitive load on readability is going to be more
on the reader. It's very difficult to
understand the whole stuff. I mean, even I would say for
methods if the number of arguments is more than three.
In my view, I think the method is doing more than what it is
supposed to do. And your app probably folding
things into a data structure and then sending it to the method.
Initially you are sending in arguments that are separated.
So try to see how we can make it coercive in terms of method
arguments that go into a method. At the same time try to see if
you can stick to it 60 to 80 character limit.
Again, this is all proven by research.
I think that I researched. But again, people before me,
they have done the research and given the results.
Thank you for such a fun stories, right.
I think that's completely right. So the reason why you don't want
to have like a too long to the right is because yeah, you have
to be inclusive, right? Not everyone has the same set of
monitors and resolutions as you. Sometimes we work on laptops,
right, Because we travel. So yeah, please do set mix with
the other thing I just want to add right not to not to start a
debate or something right. Tab versus space for
indentation, right. So I think need to be
consistently set, even though ID now helps you no matter whether
you set tabs or you know, space. But sometimes you have to go to
terminal, sometimes you go VI right.
I have another fun story, I guess.
I have a solution. No, no, not a fun story.
I have a solution. So the solution is see don't
debate. First of all because you're
using your productive time depending on trivial things,
right? Especially tabs and spaces.
So the essence is. Try to use spot formatters that
are built for specific languages right?
Say for example Visual Studio Extensions like Prettier do a
great job in formatting your code.
My solution is to use a pre commit hook.
Write a pre commit hook which formats the code in a uniform
manner for every developer. So before they commit this hook
runs formatted in a very consistent way.
Because I don't want to see this in the code which is actually
not modified just because of formatting, you will see a lot
of DIF here and there. But actually there have been a
couple of lines that got modified end of the day.
So what really happens is the consistency is maintained when
you use this kind of formatting tool and a pre commit hook which
helps you achieve that consistency across the board.
I mean everybody in the team, they can have their own settings
and their own ideas, which is fine.
You put touch bases, whatever you want to do it.
There's no point to debate. I'll just as a ticket, I'll just
go ahead and set a pre commit hook which does the job.
Yeah, that's very powerful advice right?
So automate as much as possible and do set convention within
your team. Right.
And no debates, right? Like you shouldn't debate so
much about it. I mean like it's not to say
that. No debate.
I mean, debate is healthy. Yeah, I just debates are
healthy. Definitely debate, but on worthy
things, correct? OK, so let's move on to maybe
other aspects of software engineering where it also
determines the code quality, right?
So I'm talking about code reviews.
Now that you maybe follow convention, follow standards,
you write the code right? The other aspects is actually
someone reviewing it. Is there anything that you want
to elaborate here on how we can become a better software
Craftsman? Definitely for code reviews.
Before touching upon code reviews, I'll probably touch
upon the version control strategies or the approaches
that you take. Because version control
strategies and your programming approach actually has an impact
on code reviews. The First things first, Pad
programming is an excellent concept which actually you have
a programmer, you have a driver and you have a person who is
padding along with you who's a navigator who keeps looking at
your code in real time. Again, for team startup pad
programming, you need certain amount of maturity because there
are some pad programming IT patterns.
So you should have a fair timeshare between both the
developers who are writing code. So it's not like one person will
always be writing and the other person is always a navigator.
Those kind of things cannot happen.
You should not be having pad affinity where the same
developer gets to pad with the other person, right?
Those kind of things cannot happen when you do this pad
programming. The other person gets to review
the code on the fly, gives you the feedback, so it actually
essentially cuts down in your cycle time.
What is a pro and a con? The Pro is that you get to ask
the feedback and you can easily incorporate the feedback in
terms of the review comments that might potentially come.
Three requisite is the expertise.
Developers who are pairing at least should have a fair amount
of understanding of the coding standards followed in the
project. It'll understand things.
Let us say you cannot let 2 new developers to a team pair
because they might not know the coding standards that are
adopted by the team. When there is new developer
coming in as a pair, you can probably pair them with an
existing developer who knows the standards very well and they can
act as a navigator to let the new developer write the code and
train them on the job by providing the feedback on code
reviews. So this goes well with front
based development where you commit to the main line instead
of having feature branches or short load branches as you might
know. But again, this might not be
possible in certain scenarios like regulatory environments or
public sector work that you're getting to do.
And these kind of things don't let you work with.
Recall trunk based development, it's not possible to be used in
those bases. So that is when you have to do a
feature branch based development, which requires a
separate code review process before you merge your branch
into the release branch or a development branch or a master
whatever, right? Typically we cut from master.
We have a development branch and from the development you have a
release branch. You keep committing to release
and development and then once that release goes out then the
main. Hot fixes when bug fixes happen
in the master and then they are merged back into this.
So all of these steps require you to have proper code reviews
being done and the most important thing is to
decentralize this whole process in my view.
I mean one person should not be responsible for code reviews
which actually increases the cycle time and more developers
have the challenges of going back and forth in a sense.
Like let's say there is a dev pad who is working on waiting
for a review and then by the time you.
Indeed, let us say you're reviewing that you are the
single point of failure then right?
So you go on off, then the reviews get piled up and you
cannot review and respond to it in a timely manner.
And what happens? These devs keep waiting for you.
And then once you get to the review of it and it's your other
responsibilities, because code review is not the sole
responsibility. So once you get to the review,
you approve it and then you let these developers or the dev per
merge. But once these people merge,
other folks, let us say they are the critical path.
They need to again down merge and resolve the merge conflicts
that might arise, ensure that there are no merge conflicts and
then try to resubmit it for a review.
By then you will be elsewhere so the cycle continues.
So the developers have that back and forth in terms of reviewing,
waiting for a review, merging conflicts again waiting for a
review. So that keeps on going right?
So we need to see how to decentralize it.
I'm not saying feature brands based development is bad or
trunk based is good, It's all trade-offs right?
It depends upon the specific project, depends upon the
scenario. The essence is try to see how
you can decentralize it, how more people who have the
authority review and approve. And these people should be the
core members who understand the code very well, who understand
the process very well, understand the standards very
well. So they are the long time
members and in the process of time also groom the newer
members to become those reviewers or champions, right?
And don't just have one person review it and approve it and it
can go ahead. No, you should at least have two
people or another paraphrase looking at the code.
Before it gets reviewed and approved, another thing that at
least we have followed in my team just to see if we can do it
once in iteration. Let us say we have the
developers present their code and chain to the team.
I mean what they have done in the given iteration.
Go through the features with everyone.
What are the changes that were made in a given component or the
code based on the specific project.
That way the familiarity about the changes increases within the
team and everybody has a fair understanding of what it is
based on the time and interest they can go ahead and read
further and make themselves. Today.
So these are my ideas. And yeah, I mean these are my
views on board reviews. Henry, thanks for sharing all
these different variations permutations, right.
And you are right when you touch on different, first of all it's
about different version control strategy, right.
Sometimes you use strong based development.
The way you review is slightly different than if you do you
know branching strategies. So thank you for sharing all
that. So other aspects of
craftsmanship that I think is really, really important is that
how do you control technical depth?
So sometimes you know when you write software, after a few
weeks, few months, right, you'll accumulate some debt.
Is there anything from your site to actually advise us how we can
manage technical debt? The first and foremost thing is
to know that you are absorbing technical debt.
If you don't know that you are absorbing technical debt, then
it's hard to save, right? So technical debt can be
classified into code debt designed at an architectural
debt, right? Let's say on the code front you
want to do something from a. Coding style or a programming
construct standpoint. But due to the delivery pressure
or the lack of knowledge or the lack of fairness of existence of
such a feature in your language and framework to write some
code, you deliver it, you get it working, then you understand
that OK, if instead of handcrafting this I have a
better way of doing this with the framework and the base class
library in a given language, I can very well try to do that.
I can, instead of doing it handcrafting it.
I can very well go out and use that framework feature and get
it done. So once that is the thing,
capturing that is crucial. Meaning, once you identify that,
immediately you need to create a backlog item or a recall JIRA
item or something. Wherever you have your backlog,
whether it's Azure DevOps or JIRA or whatever, capture as a
ticket in the system and ensure that it gets prioritized.
Because again, capturing alone doesn't take you anywhere.
As a team, you need to convince your product folks, convince
your product managers and engineering managers to ensure
that we are going to implement product features at the same
time. Handling technical, that is
important as you know, right? So you need to have a fine
balance within technical debt, repaying the technical debt and
project side of things, the feature side of things.
So for example, or probably a analogy that I would like to
quote is woodcutter example, right?
As a woodcutter you go and cut your wood.
Sometimes you need to sharpen your axe.
You're going to use the same axe to keep on cutting at the same
pace, right? You need to slow down, sharpen
your axe and then that's part of your profession.
This is applicable to both technical debt and engineers in
terms of learning. Whatever on software
craftsmanship, whatever on learning you need to learn.
This learning is nothing but sharpening your axe.
The same is applicable to technical debt.
So you need to repay the technical debt in a timely
manner which lets you and faster.
Again. There is an excellent book I
came across As far as technical debt is concerned.
I don't remember the title on top of my head.
I think it's Refactoring Design Smells.
It's a wonderful book which actually talks about these
aspects of and smells and technical debt and how to repay
them. And one more thing is from a
people's standpoint, people standpoint, you need to ensure
that you convince the folks the organizational buy in should be
there. The leadership should understand
the importance of technical debt and repaying it in a timely
manner. I mean this includes
architectural debt and redesigning stuff as well.
Let's say with the particular understanding of a given domain
or a sub domain. You designed it in a certain
way, you architected that in a certain way.
But let us say down there and you discover that, OK, this is a
better way to actually communicate between these two
bounded contexts. I can probably refactor this
design and redesign this and it's better to get it done, or
at least explore the possibilities of doing it again.
The pros and cons, do the analysis, do the groundwork,
have the facts ready so that they can present these facts to
the leadership and then get their buy in.
In terms of the benefits, the pros and cons of doing that and
ultimately right, people don't see technical debt.
I mean, users might not see, end user might not worry, they might
not see, but where they will feel is all about the quality.
You have a car, The car keeps running every day.
You are not appreciating your car that wow, I started you.
You got started the moment I started.
Excellent. But the lack of that, when it
doesn't start, you feel the pain.
Same goes with technical debt under the hood.
Technical debt keeps on building.
You won't realize it one fine day.
It is like changing the oil for your car engine, right?
It just ceases to run. And then you realize, Oh no, I
should not have delayed it this much.
Only that is the time where it is too late to handle it right,
and again it goes into a cycle. The problem is there are systems
that have so much technical debt you decide to rewrite the
system. I've been through this.
You decide to rewrite the system.
When you rewrite the system, possibly you don't have the
original developers who wrote the system, no more with you.
So there is a lack of domain understanding or a lack of
knowledge. You have a newer team, newer set
of folks trying to reverse engineer the old system by
understanding the behavior and then trying to break it apart
and implement it. Now without that understanding,
without that level of background, they will start
designing the system with technical debt from day one or a
design debt from day one and it never meets because you need to
keep repaying the technical debt that is there in the existing
system because you have users who are using it and you'll make
changes to it and this new system is going to play a catch
up game with the old one which is already getting changed.
It's very difficult. I mean the essence is pay
technical debt as soon as possible and then maintain a
backlog, revise the backlog, revisit the backlog and keep
reducing the backlog, right. It is never going to be 0.
Let me tell you that. You cannot do away with
technical debt entirely because people keep moving across
projects, people keep moving across organizations, people
come and go. So when new people come in,
there might be an increased technical debt because they are
understanding our system, they need time to themselves, to the
system, right? But as they learn, they will
understand the nuances, they will learn the system and they
will start working. So this technical debt that you
incur, I'm not saying every new person will bring in a technical
debt, but there is a possibility, right?
So once that happens you try to repay that and ensure that as a
team you support this new person so that there is no technical
debt. That's a better way to put it.
Try to see how you can repay the technical debt and stay on top
of it. Meaning have know that you are
absorbing technical debt. First of all.
That is where trade off analysis and understanding trade-offs is
vital. That is where understanding
design, understanding the architectural styles and
awareness of these possibilities that you have is important.
The lower most level you have probably have the design
patterns and to have a fair understanding of design
patterns, like which one to apply when.
It is not about knowing the patterns, it's about applying
the pattern right. It's about knowing what to apply
when in a given context. So these are some thoughts on
technical debt, Henry. Right.
Thank you for sharing your thoughts about technical debt.
I think all what you said is really insightful, right So and
you mentioned also about rewrites, right?
Sometimes. Software engineers, especially
the new software engineers, when they deal with legacy code, oh,
we need to rewrite this. You know, like I think you
mentioned that the first day that they do that, right.
They probably have lost much of the knowledge behind why the
code was written that way and they will incur that in the 1st
place itself, right. Unless you can maybe restructure
what kind of domain knowledge that was maybe behind all those
code, right. So I think that's a very, very
key lesson as well. So now.
Let's say assume you know individuals, teams and all that
have this kind of high quality code, they are software
Craftsman. I think the next is about how we
can transform the team into a highly performing engineering
teams, right? I think here you also have some
stories that you want to share right, about how you actually
transform the team to become a highly performing or software
Craftsman all around, right. So maybe if you can touch on a
little bit on this, that will be great.
Definitely. I mean, there's an existing
model you might find online as well, like which actually show
psychological safety and performance and accountability
in a graph, right. So I'll probably, before jumping
into that, so many teams that I've met a touch upon
psychological safety. So one of the key aspects today
at least is to give equal importance to mental health
compared to, I mean as important as physical health because this
is going to also impact your physical health in a way.
So as leaders, as technical leads, the first thing that I
would probably request folks to do is to create a
psychologically safe environment for your developers wherein they
can be their true selves, they can speak without any vision,
they can be open about their issues that they are facing on a
daily basis because psychological safety forms the
foundation of anything right On top of it, I would recommend
transparency, which is be transparent one the behavior
that you can observe which is more than work and life.
People are hesitant to tell the truth, but they don't think
twice. To lie about something, be true
to yourself and be true to others, I mean tell the truth.
And the truth comes only with transparency.
You try to be transparent. Let us say you have a personal
appointment that is actually coming on your way.
Be transparent about it. Let others understand.
Everybody has a life, right? You might be undergoing a tough
time. You don't need to take a
loudspeaker and tell it to everybody.
But you can definitely communicate with your leadership
about the challenges that you are facing as individual.
Because I see that many individuals today need that
emotional support, need that emotional bonding to connect
with them. Don't say that work is a family
or something, right? I don't want to use such fancy
words. Family is family.
Work is work. It's a professional environment,
right? Stay professional.
At the same time, people definitely are social beings who
need that emotional support to try to see how we can provide
that psychologically safe environment with transparency.
And these are the two foundational layers for you to
build trust. As you know, trust is going to
take time to build within the team.
So one of the situations is like I had a a project where we had a
team of individuals, really good individuals, handpicked for the
project, but the project was really a tough one to achieve in
a given time frame. So happened that the team was
actually very good. I mean in terms of psychological
safety and performance accountability, there were some
challenges. We tried to fix it as a team.
So what happens is not specific to that team, right.
In general, it is split into four zones.
When there is no psychological safety and low performance
accountability, you are there in the data zone.
So the data zone is where developers don't understand what
they're doing, why they are even going to work, What is it that
is going on with them? They don't understand the
dynamics and the politics and the all the organizational fancy
stuff that's going on right. The next one is actually a
anxiety zone. Let us say there is no
psychological safety, but there is more performance and
accountability. You have a lot of performance
and accountability expectations on the individuals become
anxious, how am I going to deliver?
How am I going to achieve this? There is a huge deadline that is
looming over me or the team, right?
How are we going to solve this as a team that makes them
anxious? The third zone on the top left
is about low performance accountability, but high cycle
is considered this kind of a very comfort safe zone.
People are laid back, OK, nobody questions.
There is some legacy system which is paying our bills.
It is generating the revenue and a lot of time for developed
software delivered. Some kind of.
I'm just giving the cooking of an example, right, some kind of
a situation like that where people are very laid back, they
know they won't get fired. There is no hard motivation or
something to actually run and keep yourself up to date with
stuff and you just keep doing in a very slow manner, right.
So that is the comfort zone and finally the learning zone where
there's high performance, high accountability and also high
psychological safety. So we want our teams to actually
go from these three zones mentioned earlier, which is the
detached comfort zone and the anxiety zone into the learning
zone. So how to take these teams?
There are two parts you can see. Either you take them through the
comfort zone or through the ANSID zone.
So the first one is don't take the ANSID zone.
That is, don't increase the performance and accountability
without increasing the psychological safety and trust.
Work on psychological safety, work on trust, try to increase
it. So when you keep your
performance and accountability expectations constant for a
moment and then try to focus on improving the performance and
accountability for some time, you take the team into the
comfort zone, meaning it is not a permanent comfort zone but the
temporary pathway, right. Instead of going through the
anxious zone, you take them to the comfort zone and once you
know they are there, they are the psychological safety, they
have the transparency and trust. Then you start increasing your
performance and accountability bars.
When you raise that bar, the team naturally transforms.
Again. This was done with a set of
individuals by working with them and theoretical right.
So we worked as a team to apply these concepts.
Concepts are in new. I mean, as I told earlier,
knowledge is everywhere, knowledge is borrowed, but the
experiences are unique, right? So there's one such experience
where we got an opportunity to transform a team and it has
worked in more than one this entry in my opinion.
So connecting with the individuals and improving the
psychological safety is the fundamental to building a
stronger team. Right.
So I think it's really insightful for people who are
interested to see these quadrants, as Rihari just now
mentioned, right? Some of you may not be able to
follow, but I'll put it in the show notes if we can find a
link. And also I saw Srihari come up
with a mind maps for these kind of things, including this.
How to actually go into learning zone?
How to transform teams right? And also in the software
architecture of software craftsmanship, you also have
another mind maps, right? Maybe tell us a little bit more
why do you love creating mind maps?
How does your brain actually work with mind maps?
Maybe a little bit of intrigue here.
Mind maps is an idea is always about how your brain organizes
information. So you have neurons which are
actually 3 dimensional in connection and let you retain
and remember a lot of things. So mind maps as a concept or as
an approach capturing knowledge. Just to give you an example,
Boeing captured their entire 747 details in a mind map that was
25 feet long. So a 25 feet long mind map was
used by Boeing to capture the entire knowledge about 747.
So the essence of mind map is to capture a lot of information and
try to present in a way it can be recollected easily.
That is you have a central concept and then you have other
concepts that are linked to it and then there is a linking
between these sub concepts as well at times.
So it's like a three-dimensional graph where concepts and things
are linked together right. So that is how I found interest
in creating mind maps and I tried to create mind maps
whenever I have a complex concept that I want to share
with my team and then present it to them and share it with them.
And it helps in multiple ways. One is to share knowledge in a
very concise manner. Second, it also helps me in
teaching and learning. And 3rd it also helps you
reconnect faster. I mean if you want to reconnect
the concept, the mind map is something that will help you to
collect faster. So that is a road that mind maps
in shop and. Sometimes you also see it in the
movie, right? When you have a detective
investigation, you have all these, you know, lines on the
wall, right? It's kind of kind of like that
as well, to recollect all the threads, threads connecting the
photographs and pins and everything.
Yeah. So about software craftsmanship,
right, I think we have covered about code base, a little bit of
practices, right. We also touched on about teams,
right, going to learning zone. The other aspect of good high
quality software or product is actually about architecture and
the domain knowledge that you mentioned, right.
So maybe we can touch on a little bit as well to become a
good software Craftsman or what aspects of architecture and
domain knowledge that we have to actually adhere to as sort of
architecture is concerned. As you know there are a lot of
different architectural styles from layered to monolith to
micro services to space based, even based even driven in all of
this architecture, service oriented kind of architectural
sites out there. As such we have as an industry
we have undergone translation in terms of these architecture.
In my view if you see this back then we used to have layered
architecture. As convey's law says, the
creature will be very team structure and inverse Convey
manualist, this is your architecture that you want to
achieve. Then probably you try to
structure your teams this way. Right back then we used to have
layered architecture, we used to have client server right, we
take web pages, we had server side rendering as such, we had
server side rendering which servers used to render.
But in my view, right, if you take the advent of smartphones
again, the iPhone and iPad in 20/10/2011 timeframe actually
changed things from even the impact of the development
ecosystem in my view. Because back then when server
side rendering was so prominent, the number and devices hitting
these servers was actually a finite set.
But with the proliferation of mobile devices, the number of
devices hitting these servers became exorbitant wherein the
servers could not keep up with that load and they eventually
had to scale right, scale horizontally as well as try to
offload the responsibility of rendering into the client, use
the client side power to render right.
Which gave a way to the kind of simple page applications and
frameworks and all these JavaScript frameworks and stuff,
right? Then you also have the mobile
apps and other things that are communicating with the server.
So there is more computing power that got distributed from a
computational perspective. So all of these are different
events that shaped up newer architectural styles.
So from layered we got into service oriented which resulted
in some distribution and then from there it became micro
service on the server side and then micro front ends on the
client side. Now I mean not that every
architecture is suitable for every problem, right?
I mean first of all you need to understand one thing very
clearly. No architectural style is
superior or inferior. I see a lot of debates online
where probably I have stepped in and given my suggestions that I
learned from different authors and different people in the
industry by reviewing these books and expanding my
knowledge. Not that it's my personal view
and I have also learned from others and also seen an
experience both put together. Architectural stylist, superior
or inferior you'll be wondering, I mean working in a fancy micro
service based project, but it might be some humble legacy
system which will be sitting in the back Rd. and funding your
project. But that will be the cash code
from a management perspective which gives you the cash and the
funding for the R&D division to invest in micro services and
develop a new version of your product, right.
So we need to see, I mean I have huge respect for this legacy
system because the developers who wrote it, they didn't have
all these fancy things back then, not have faster missions,
they did not have a lot of RAM, they did not have cloud, they
did not have fancy IDs and all this stuff.
But even then they produce something that's of great
quality, right? They are are pioneers in terms
of software craftsmanship. Those who wrote such systems,
they need to get their fair share of respect.
And every time I see people complaining about legacy systems
but also try to look at the positives of legacy system, it
is giving you the funding that you need today.
In essence, understand the different architectural styles,
try to see how it is going to fit together.
And no single architectural style might be helping you solve
a very complex problem. Let's say you take a example
like Amazon, a part of it might be micro services, a part of it
might be a mobile app, a part of it might be a layered stuff.
It depends upon the problem of domain and the subdomains that
are interacting and working together.
So these architectural sites some part might be event driven
write these architectural styles should actually work together in
tandem to solve the business problem wherein you can even go
ahead and apply a given architectural child for a given
problem or a bounded context and then solve it that way and the
way it interacts with another bounded context.
So again it boils. It has a close link to Domain
Driven Design as such because in my view Domain Driven Design is
kind of an eternal concept in software timeframe because it
was written in 2003, 2004 by Eric Evans.
But I feel there is more traction in the last few years
or last decade or so where people have started looking back
into the literature of Domain Driven Design and they're trying
to take these concepts like stuff that is there in books
like Accelerates, stuff that is there in books like team
topologies, some there is in every microservice book, stuff
that is there in all the architecture and books.
Everything boils down to Domain Driven Design, the strategic
patterns of Domain Driven Design and the tactical patterns of
Domain Driven Design. So an organization for leaders,
I feel it is important for leaders to read about Domain
Driven design, especially the strategic part of it, because
that is going to give you a lot of insights on what work remains
within the organization. Where do you put the best people
in your organization or the best minds, right?
I mean, we don't have an inclusive environment.
As I mentioned earlier, people differ by their own knowledge
levels and abilities, but it is not a matter of learning.
Everybody can learn and work. It is just a matter of
experience, not a question about ability.
It's just a matter of learning and time, right?
So given that, people will learn and they will definitely get up
to speed. So if you take an organization
where you have the best minds or the most experienced folks, they
should be trying to solve the core problem.
An organization, the core domain and this knowledge should not be
going out of the organization to other folks who are like say you
have a conducting firm or a subcontracting or an outsourcing
firm. Sometimes the problem is complex
enough where you need specialized skin sets from an
outsourcing firm. I'm not saying don't outsource
your core domain, but also have some people in your organization
who pad with these people to solve the complex problem
together. So that is a supporting domain
which is not a off the shelf solution, but I need to build
it. That is where you can actually
probably give an opportunity to your younger developers or the
junior developers or people who are new to the organizations.
You can put these people into these areas and they will have
to know the application, how to develop it and how to move
forward with the supporting domain.
And of course for the things that are not going to give you a
competitive advantage like the generic domain, something like
authentication, authorization, don't read when they will just
go ahead and buy something off the shelf, say for authorization
use after. So it depends.
So all of all of this stuff try to get that perspective.
So when leaders, they read about Domain Driven design and these
kind of concepts that we discussed about architecture,
the styles and stuff, you need to connect the dots.
So I'm probably trying to cover these as well in my next book.
So I'll be writing about these and much more in the coming
days. So I think if we look back the
whole episode right, we cover a lot of things for all software
engineers to actually upscale and become a better Craftsman,
right? We start from the code we start
then for some practices. And also transforming the teams
into learning zones and things like that.
We also touch on about mind maps, a little bit of how you
could recollect knowledge. And then lastly we talk about
architectural styles and also understanding domain driven
design. So all these, I feel, I agree
with you that these are all very, very important aspects for
us to become a much better software engineer.
I want to touch on one more thing but just to take notes.
I mean have a notebook and a pen next to you.
Whenever you read a book, either you write it in the book itself
in the sidebar or underline or mark it or write notes
definitely. I request folks who are learning
to take notes. Visual note taking is a concept
that you can explore which I am also collecting a lot of visual
note taking samples nowadays. So whenever I find something
interesting I just take a quick screenshot or I just save the
image. And I have a library of visual
notes now which I can refer back to different styles of visual
note. Taking it also like mind maps
helps you capture complex concepts and it helps you in
storytelling. So my two cents, always learn.
Take notes of what you learn. Right.
Thanks for the plug as well. So, Sri Hari, I think we have
covered a lot of things unfortunately due to the time we
we have to you know leave soon. But I have one last question
that I would like to ask you, which is a custom question that
I, I have to to ask for all my guests.
I call this 3 technical leadership wisdom.
So you can think of it just like advice that you want to give to
us to learn from you. So what will be your 3 technical
leadership system? Not every problem is technical
in nature. Many of the time it's people,
right? So give respect to people and
treat them with immense respect. And everybody should get their
share of respect irrespective of their background, irrespective
of anything, right? So respect your folks who are
working with you and your team. That will go a long way in
building a working relationship, but it's not about who is right
or who is wrong, it's about the working relationship.
So gracious behavior is one of the key aspects that I would
recommend to folks. I'm also in the process of
learning. Not that I'm perfect, so always
try to be gracious. Let the other person save face
and keep moving. That is one thing.
Second advice that I would not an advice, an input, or a wisdom
I would like to share is to learn something every day.
I mean you cannot conquer without practice, right?
It might not be a new piece of wisdom, but as technical folks
or technical leads or architects, we need to keep
learning and capture your learning so that you can share
and recollect and teach others. Always share what you learn, as
Yoda said. So that is one thing.
And the third piece of input would be try to bring in variety
in your learning. I mean, don't learn the same
kind of stuff. Let us say you're learning a
programming language in a given paradigm, say object oriented.
The next language try to learn in a functional way.
This gives you different set of tools that you can apply for
specific problems. Because it is not the
programming language that determines a given project that
they're going to work on, but it is the problem domain that
demands a given technology stack, right?
Let's say you want to develop an enterprise app.
You are better off doing it with javaor.net or something.
And if you want to do something in data engineering, you are
better off doing it with Python. Let us say you want to do
something with statistical computing.
You want to better off doing it with R or Python.
And if you go, probably if you go and use some of the text
stack which is not appropriate, you will burn your fingers,
right? So use the right tool for the
right problem and the right domain, which actually helps you
become a better person. So have that variety in terms of
learning and try to apply your learning and share your
learning. I like the last part, right?
So you also need to know the variety and the options that you
do have, right? So that you can tackle the
problem with the right tool. So thank you so much Sihari for
this conversation. If people would like to connect
and find you online or ask you about questions, is there a
place where they can find you? Yeah, they can find me on top.
Meet as well as LinkedIn and I'm happy to you wanna break with
folks and try to provide any help that I can all.
Right. Thank you so much again for your
time. I hope everyone who listens to
this episode can become a better software Craftsman and thank you
for your opportunity. Henry and I'm also learning in
the process. It was a great conversation and
thank you for interesting your time and having this
conversation. Thank you for listening to this
episode and for staying right until the end if you highly
enjoyed it. I would appreciate if you share
it with your friends and colleagues who you think would
also benefit from listening to this episode.
And if you're new to the podcast, make sure to subscribe
and leave me your valuable review and feedback.
It helps me a lot in order to grow this podcast better.
You can also find the full show notes of this conversation on
the episode page at Technically journal dot dev website,
including the full transcript, interesting quotes and links to
the resources mentioned from the conversation.
And lastly. Make sure to subscribe to the
shows mailing list on Techly Juno dot dev to get notified for
any future episodes. Stay tuned for the next Techly
Juno episode, and until then, goodbye.