#152 - Craft Your Code with Software Craftsmanship - Srihari Sridharan

[00:01:02] Episode Introduction

Henry Suryawirawan: Hey, everyone. You’re listening to the Tech Lead 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 Tech Lead 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 techleadjournal.dev/tip or becoming a patron at techleadjournal.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 debt. 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 five star rating and review on Apple Podcasts 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.

[00:02:53] Introduction

Henry Suryawirawan: Welcome to Tech Lead 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.

Srihari Sridharan: Hi, Henry. Thanks for the opportunity.

[00:03:08] Career Journey

Henry Suryawirawan: 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.

Srihari Sridharan: Sure, Henry. So, I have 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 organizations. 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, uh, 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.

Henry Suryawirawan: Thank you so much. Very interesting. You have a day job in a consulting company. You also review books, right? I think you are part of the reviewers of many great titles from Manning. And the last one, you do pro bono for university.

[00:06:11] Bridging the Students Gap With Industry

Henry Suryawirawan: 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?

Srihari Sridharan: Yeah, definitely. I mean, uh, things have improved a lot in the current situation, meaning 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 still 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 try 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 we 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, as in data science did not exist back then, but data warehousing and other stuff was there. I’m talking about two decades ago. So data warehousing was there. Databases 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. Lots 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 in the streams are getting very specialized from an 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 then 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.

Henry Suryawirawan: 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.

[00:09:36] Writing “Craft Your Code”

Henry Suryawirawan: So moving on to, maybe that’s why you write this book, right, Craft Your Code. Because I had a look and read of 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.

Srihari Sridharan: 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 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 practical. Because you have industry stalwarts like Robert C. Martin who wrote Clean Code. You have Steve McConnell who wrote Code Complete. You have Pete Goodliffe who wrote Code Craft. 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 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 of it, Craft Your Code with Generative AI, where I tried to explore the possibilities of using GenAI for software development and draft your code. So that’s the idea, again. It’s in its early 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. The intent is not to make money, but the intent is to share the knowledge. So that is the background of this book, Henry.

Henry Suryawirawan: 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.

Srihari Sridharan: And 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?

Henry Suryawirawan: That’s correct. And also, yeah, like you mentioned, I find something interesting about your book, right. You actually use polyglot 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 a sense.

[00:12:18] Software Craftsmanship and High Quality Code

Henry Suryawirawan: 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, two decades, right? What do you see why it is important for engineers to look into the aspects of software craftsmanship and also high quality code?

Srihari Sridharan: Definitely. So the first thing, right? I mean, writing code that works, I mean, that’s the very lowest bar. I mean, anybody can cross that bar 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 just do 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 software craftsmanship as such.

If you just rewind the whole two 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 a lot of RAM and a lot of processing power. We did not have SSDs, right? We did not have anything. We did not have powerful IDEs. 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 15, 16 or less than 20 percent maximum. Either it shoots 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’d like to quote an example of Apple, right? Apple never compares themselves to other products. They compare themselves to 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 others. 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 care 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 angle and a craftsmanship angle, you can lead by example.

And also learn from them. So learning is always a two way street. The fresh minds who come into the industry, they have a fresh perspective looking at the code and the system and they can do their feedback. So be open to feedback. So you’ll 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 complimenting each other. Together you solve a problem, right? So that is my view about software craftsmanship and writing clean code.

[00:15:26] Root Causes of Low Quality Code

Henry Suryawirawan: Right, so I think when you explained that, it intrigued me, right, the fact that the technologies have moved so advanced, so rapidly. We have so many choices, programming languages, cloud, you know, infrastructure. I don’t know, so many exotic things happening, right? But still, we have the fact that projects failed. 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, TDD, XP. All exist, 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 some of the root causes of low quality code? Maybe if you can highlight some of the categories for us here to remind ourselves.

Srihari Sridharan: So low quality 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’ll have class 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 criteria and acceptance criteria, whatever you call it, right? So that it meets the requirements of the user. So, in essence, the overall 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 code is going to be a matter of time, right?

Again, with GenAI and other tools that you get, the Pair Programming Assistants, it is going to help you code faster is what we observed. At least, that’s the claim today. Again, we need to validate this claim with more data as we practice more with these coding assistants. But definitely, they are a way forward. We cannot ignore and move on, right? People who embrace these assistants, they’ll 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, Checkstyle kind of stuff, or you have the FXcop and Stylecop on the .NET front, 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 CI/CD 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.

Henry Suryawirawan: 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, 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.

Srihari Sridharan: One thought I would like to add to that, Henry. I mean, design one pager 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 pair programming as a pair, and you want to communicate your design and get it sorted out with your technical lead. Write a one 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 the feedback. And then probably get into coding it. Then it’s going to decrease your back and forth loops that you will have in rework and all this stuff.

[00:20:15] Coding Standards

Henry Suryawirawan: 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 brainpower, 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 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.

Srihari Sridharan: 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 it kind of calculates, okay, 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 the, let’s say, for example, you write streams or LINQ code–streams in Java and LINQ 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 but read 10 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 of code that is old or 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 one file at a time. So you can at least ensure that the minimum amount of consistency is maintained at the file level. So 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 how you build an inclusive environment where the person understands this whole thing.

So doing something that is consistent with the industry standards and maintaining that 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, Henry.

Henry Suryawirawan: Yeah, it’s very interesting when you mentioned about consistency boundaries, right? 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 these coding standards. They can automate it. And it’s as if, right, the whole company is written by same kind of styles and same kind of people, right? So I think that’s really, really powerful.

[00:24:17] Code Aesthetics

Henry Suryawirawan: 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?

Srihari Sridharan: 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 “Pragmatic Thinking and Learning: Refactor Your Wetware”, 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 lay out your code, say, for example, all the variables that are used in a class, say an object oriented programming paradigm, should be organized properly at the top.

So as Robert C. Martin calls it, he also gives the 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 it and then the summaries. 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 gonna 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 of this 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 code such that 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 constructor, the methods, and then the private methods. That is a neat way to organize it aesthetically. And 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? Whatever you’re 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 where it ends and then leave a blank line and then start the next possible line. It clearly use a separation between this and the next concept that is coming up, right. So the same is applicable to if blocks, else blocks, switch cases and all these stuffs, all these constructs. So anytime there is an indentation, the indentation that takes your code towards 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 two concepts. So that is your vertical way of organizing your code aesthetically.

When it comes to horizontally organizing, as you might know, leaving spaces between operators and variables, and then assignment and variable, leaving spaces wherever required, writing the comments in a very clean manner, in a very concise and understanding manner. 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 if your code is not visually consistent or aesthetically pleasant, then probably you take a step back and say, okay, 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 crucial when reading code is done more frequently than writing it.

Henry Suryawirawan: 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, you mentioned that the code is written once, read 10 times or even more, right? So you need to help yourself, right? In order to actually understand what you read.

[00:28:09] Code Readability

Srihari Sridharan: I mean, one other 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 a 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 two important problems or difficult problems to solve is to when to invalidate a 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 that 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 conveys that meaning in a better way. So that is another piece of input.

Henry Suryawirawan: I just want to add on maybe as part of the aesthetics, right? So the few things that I feel that 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.

Srihari Sridharan: I have some interesting stories there. So once upon a time, there was 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 it your methods are long? Then he told me like, okay, my methods are long because whenever it crosses my screen limit, I tend to break it to a new method. Okay, that seems to be a very interesting yardstick to break into a new method. Then I thought, even then you should be breaking it about half the size of it or even 3 by 4th of it. Why are you taking so long? Then I went and sit at his desk. He had the monitor in portrait mode where the monitor was actually in a portrait mode and he was trying to break a line when it enters the next screen.

And while it might sound funny, right? I mean, the most important thing is to adhere to single responsibility principle, right? Single responsibility is not that it crosses your screen limit, but instead you 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 Robert says.

Another instance is, 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? We have very wide monitors. We don’t find any challenges in working with such a code. I was like, okay, 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 a point, the cognitive load increases when you keep scrolling and going back and forth, and then all of this stuff, right? When you write long methods or when you write horizontally long lines, the 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. Or you are not probably folding things into a data structure and then sending it into the method. Instead, you are sending in arguments that are separated.

So try to see how you can make it cohesive in terms of method arguments that go into a method. At the same time, try to see if you can stick to that 60 to 80 character limit. Again, this is all proven by research. Nothing that I researched, but again, people before me, they have done the research and given the results.

Henry Suryawirawan: Thank you for such 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 max width.

[00:32:31] Tabs vs Spaces

Henry Suryawirawan: 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 IDE 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?

Srihari Sridharan: I have…

Henry Suryawirawan: Another fun story, I guess.

Srihari Sridharan: 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 killing your productive time debating on trivial things, right? Especially tabs and spaces. So the essence is, try to use code 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 suggestion 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 diff in the code which was actually not modified.

Just because of formatting, you will see a lot of diff here and there. But actually it would 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 a 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 in their own IDEs, which is fine. You put tab spaces, whatever you want to do it. There is no point to debate. I’ll just, as a tech lead, I’ll just go ahead and set up pre-commit hook, which does the job.

Henry Suryawirawan: 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…

Srihari Sridharan: No. Debate. I mean, debate is healthy. Debates are healthy. Definitely debate, but on worthy things.

[00:34:12] Code Review

Henry Suryawirawan: Yep, correct. Okay, 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 conventions, 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?

Srihari Sridharan: Yeah, definitely. For code reviews, before touching upon code reviews, I’ll probably touch upon the version control strategies for the approaches that you take. Because version control strategies and your programming approach actually has an impact on code reviews. So first things first, pair programming is an excellent concept, which actually you have a programmer, you have a driver, and you have a person who is pairing along with you who is a navigator, who keeps looking at your code in real time. But again, for teams to adopt pair programming, you need a certain amount of maturity, because there are some pair programming anti patterns.

So you should have a fair time share between both the developers who are writing code. So it’s not like one person who will always be writing and the other person is always a navigator. Those kind of things cannot happen. You should not be having pair affinity where the same developer gets to pair with the other person, right? Those kind of things cannot happen. But when you do this pair programming, the other person gets to review the code on the fly, gives you the feedback. So it actually essentially cuts down on your cycle time.

But what is the pro and the con? The pro is that you get faster feedback and you can easily incorporate the feedback in terms of the review comments that might potentially come. But the prerequisite is the expertise. The developers who are pairing at least should have a fair amount of understanding of the coding standards followed in the project. They need to understand things, let us say you cannot let two new developers to a team pair, because they might not know the coding standards that are adopted by the team. When there is a 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 trunk based development, where you commit to the mainline, instead of having feature branches, or possibly you need to have short lived 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 what I call trunk based development, is not possible to be used in those places. So that is when you need 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 hotfixes and bugfixes 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 the sense, like, let’s say there is a dev or a dev pair who is working on waiting for a review. And then by the time you, as a lead, let us say you’re reviewing it, you are the single point of failure then. Let’s say 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 review it, amidst your other responsibilities, because code reviewing is not the sole responsibility.

So, once you get a review, you approve it and then you let these developers or the dev pair merge. But once these people merge, the other folks, let us say they are on a 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 branch based development is bad or trunk based is good. It’s all trade off, right? It depends upon the specific project. It depends upon the scenario.

But the essence is try to see how you can decentralize it. Have more people who have the authority to review and approve. And these people should be the core members who understand the code very well, who understand the process very well, who understand the standards very well. So they are the longtime members. And in the process of time, also groom the newer members to become those reviewers or champions. 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 pair of eyes looking at the code before it gets reviewed and approved.

Another thing that at least we have followed in my teams is to see if we can do once in an iteration, let us say we have the developers present their code in front of 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 base of the specific project. That way, the familiarity about the changes increases within the team and everybody has a fair understanding of what it is. And based on the time and interest, they can go ahead and read further and make themselves up to date. So these are my ideas. And yeah, I mean, these are my views on code reviews, Henry.

Henry Suryawirawan: Thanks for sharing all these different variations, permutations, right. And you’re right when you touch on different, first of all, it’s about different version control strategy, right? Sometimes you use trunk based development, the way you review is slightly different than if you do, you know, branching strategies. So thank you for sharing all that.

[00:39:36] Managing Technical Debt

Henry Suryawirawan: So other aspects of craftsmanship that I think is really, really important is that how do you control technical debt? 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 side to actually advise us how we can manage technical debt?

Srihari Sridharan: 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, design debt, and architectural debt. 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 awareness of existence of such a feature in your language and framework.

You write some code, you deliver it, you get it working, but then you understand that okay, if instead of hand crafting 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, hand crafting it, I can very well go ahead and use that framework feature and get it done.

So once that is the thing, capturing it is crucial. Meaning once you identify a debt, immediately you need to create a backlog item or what do you call a 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 debt is important, as you know. So you need to have a fine balance between technical debt, repaying the technical debt and the project side of things, the feature side of things.

So one more example or probably a analogy that I would like to quote is a woodcutter example, right? As a woodcutter, you go and cut your wood. Sometimes you need to sharpen your axe. You cannot 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.

And same is applicable to technical debt. So you need to repay the technical debt in a timely manner, which lets you run faster. Again, there is an excellent book that 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 design smells and technical debt and how to repay them.

And one more thing is from a people’s standpoint. From a 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 subdomain, you designed it in a certain way, you architected that in a certain way. But let us say down the line you discover that, okay, this is a better way to actually communicate between these two bounded contexts. I can probably refactor this design and redesign this. Then 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 ground work, have the facts ready, so that you 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. The 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 got started the moment I started. Excellent. But the lack of that, when it doesn’t start, you feel the pain. The 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. Probably that is the time when it is too, 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. But 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 a system with technical debt from day one. Or a design debt from day one, right?

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 make changes to it, and this new system is going to play a catch up game with the old one, which is already getting changes. So, it’s very difficult. So 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 zero, 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 their understanding of the system, they need time to get accustomed 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. 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, know that you are absorbing technical debt first of all. And that is where trade off analysis and understanding trade offs is vital. And that is where understanding design, understanding the architectural styles. The awareness of these possibilities that you have is important. At the lowermost level you have, probably, you have the design patterns. You need to have a fair understanding of design patterns, like which one to apply, when. It is not about knowing the pattern, 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.

Henry Suryawirawan: Right. Thank you for sharing your thoughts about technical debt. I think all what you said is really insightful, right? So when 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 debt in the first 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.

[00:46:23] Psychological Safety & Trust

Henry Suryawirawan: So now, let’s say assume, you know, individuals, teams, and all that have this kind of high quality code. They are a 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 would be great.

Srihari Sridharan: Definitely. I mean, there’s an existing model that you might find online as well, like, which actually shows psychological safety and performance and accountability in a graph. So I’ll probably, before jumping into that transforming teams, right, I’d like to 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 self, they can speak without inhibition, they can be open about their issues that they are facing on a daily basis. Because, psychological safety forms the foundation of any team.

On top of it, I would recommend transparency, which is, try to be transparent. There is one standard behavior that you can observe, which is both in 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 it’s actually coming in 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’re facing as an 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. So try to see how you 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 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 timeframe. It 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 low psychological safety and low performance and accountability, you are there in the detached zone. So the detached zone is where developers don’t understand what they are 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 all the organizational fancy stuff that’s going on.

The next one is actually a anxiety zone. Let us say there is no low psychological safety, but there is more performance and accountability. You have a lot of performance and accountability expectations on the individuals. They 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. How am I 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 psychological safety. This is kind of a very comfort, safe zone where people are laid back. Okay, nobody questions. There is some legacy system which is paying our bills. It is generating the revenue. I have a lot of time to develop software and deliver. Some kind of, I’m just giving a cooking up 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, the comfort zone, and the anxiety zone into the learning zone.

So how to take these teams? So, there are two paths that you can see. Either you take them through the comfort zone or through the anxiety zone. So the first one is don’t take the anxiety 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 a temporary pathway.

Instead of going through the anxious zone, you take them to the comfort zone. And once you know they are there, they have the psychological safety, they have the transparency and trust, then you start increasing your performance and accountability bars. So when you raise that bar, the team naturally transforms. Again, this was done with a set of individuals by working with them and not just theoretical, right? So we worked as a team to apply these concepts.

The concepts aren’t new. I mean, as I told earlier, knowledge is everywhere. Knowledge is borrowed, but the experiences are unique. So this one such experience where we got an opportunity to transform a team, and it has worked in more than one case, Henry, in opinion. So connecting with the individuals and improving the psychological safety is the fundamental to building a stronger team.

Henry Suryawirawan: Right. So I think it’s really insightful for people who are interested to see these quadrants, as Srihari just now mentioned, right. Some of you may not be able to follow, but I’ll put it in the show notes if you can find a link.

[00:52:09] Mind Maps

Henry Suryawirawan: 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 or 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 intrigued here.

Srihari Sridharan: So mindmaps as an idea is always about how your brain organizes information. So you have neurons, which are actually three dimensional in connection. And it helps you retain and remember a lot of things. So mindmaps as a concept or as an approach to 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.

So that is how I found interest in creating mindmaps and I try to create mindmaps 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 third, it also helps you reconnect faster. If you want to reconnect a concept, a mind map is something that will help you recollect faster. So that is about mind maps in short.

Henry Suryawirawan: 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.

Srihari Sridharan: All the threads. Threads connecting the photographs and pins and everything.

[00:54:00] Architecture & Domain Knowledge

Henry Suryawirawan: Yeah, so about software craftsmanship, right, I think we have covered about codebase, 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, what aspects of architecture and domain knowledge that we have to actually adhere to?

Srihari Sridharan: As far as architecture is concerned, as you know, there are a lot of different architectural styles, from layered to monolith to microservices to space based, event based, event driven, and all of these architectures, service oriented. There are a lot of architectural styles out there. As such, we have, as an industry, we have undergone transformation in terms of these architectures. In my view, if you see this, back then we used to have layered architecture. As Conway’s Law says, the architecture will mirror your team structure. And Inverse Conway Manoeuvre is, if this is the target architecture that you want to achieve, then probably you try to structure your teams this way, right?

So back then we used to have layered architecture, we used to have client server, right. If you take webpages, 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 2010-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 of 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. To use the client side power to render. Which gave a way to the kind of single page applications and frameworks and all this JavaScript frameworks and stuff. And 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 computational perspectives. So all of these are the 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 microservices on the server side and then micro frontends on the client side.

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 I’ve probably I’ve 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, I’ve also learned from others and also seen an experience both put together. No architectural style is superior or inferior.

You might be wondering, I mean, working in a fancy microservice based project. But there might be some humble legacy system which will be sitting in the background and funding your project. That will be the cash cow from a management perspective which gives you the cash and the funding required for your R&D division to invest in microservices and develop a new version of your product. 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. They did not have faster machines, they did not have a lot of RAM, they did not have cloud, they did not have fancy IDEs and all this stuff. But even then they produced something that’s of great quality. They are our 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 systems. 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 an example like Amazon. A part of it might be microservices, a part of it might be a mobile app, a part of it might be a layout stuff. It depends upon the problem domain and the subdomains that are interacting and working together. So these architectural styles, some part might be event driven. All of 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 style 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 aspect, 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 half a 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 Accelerate, stuff that is there in books like Team Topologies, stuff that is in every microservice book, stuff that is there in all the architecture books, everything boils down to domain driven design, the strategic patterns of domain driven design and the tactical patterns of domain driven design.

So as 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? I mean, we need to 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 is 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 within 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 contracting firm or a subcontracting or an outsourcing firm. Sometimes the problem is complex enough where you need specialized skillset from an outsourcing firm. I’m not saying don’t outsource your core domain, but also have some people in your organization who pair with these people to solve the complex problem together.

Stuff that is a supporting domain, which is not an 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 organization. So you can put these people into these areas and they will get 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 reinvent the wheel. You just go ahead and buy something off the shelf. Say for authorization use Okta.

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.

Henry Suryawirawan: So I think if we look back the whole episode, right, we cover a lot of things for all software engineers to actually upskill 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 mindmaps 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.

Srihari Sridharan: I want to touch on one more thing, which is 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.

[01:02:33] 3 Tech Lead Wisdom

Henry Suryawirawan: Right. Thanks for the plug as well. So Srihari, I think we have covered a lot of things. Unfortunately, due to the time, 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 have to ask for all my guests. I call this three 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 three technical leadership wisdom?

Srihari Sridharan: 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. And that will go a long way in building a working relationship. It is not about who is right or who is wrong. It’s about the working relationship. 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 are learning a programming language in a given paradigm, say object oriented. The next language, try to learn in a functional way. This gives you a different set of tools that you can apply for specific problems. Because it is not the programming language that determines a given project that you’re going to work on, but it is the problem domain that demands a given technology stack.

Let’s say you want to develop an enterprise app, you are better off doing it with Java or .NET or something. And if you want to do something in data engineering, you’re better off doing it with Python. Let us say you want to do something with statistical computing, you are better off doing it with R or Python. And if you go, probably if you go and use some other tech stack which is not appropriate, it 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.

Henry Suryawirawan: 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?

Srihari Sridharan: Yeah, they can find me on TopMate as well as LinkedIn. And I’m happy to collaborate with folks and try to provide any help that I can do.

Henry Suryawirawan: All right. Thank you so much again for your time. I hope everyone who listens to this episode can become a better software craftsman.

Srihari Sridharan: And thank you for your opportunity, Henry. And I’m also learning in the process. It was a great conversation and thank you for investing your time and having this conversation today.

– End –