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.