Vox

Leitura de 81 min

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

Summary

Srihari Sridharan, author of ‘Craft Your Code’, shares insights on software craftsmanship and becoming better software engineers. He emphasizes that writing working code is the lowest bar—true craftsmanship involves writing clean, maintainable code that you can understand six months later. Despite technological advancements, project failure rates remain high because the fundamental issue lies with individuals needing to prioritize quality and continuously raise their own standards.

Srihari discusses practical strategies for improving code quality, including establishing and automating coding standards, focusing on code aesthetics for better readability, and performing effective code reviews. He explains the importance of consistency boundaries within files and projects, and how visual appeal through proper formatting, meaningful naming, and logical organization reduces cognitive load. The conversation covers managing technical debt by recognizing it early, creating backlog items, and balancing feature development with debt repayment.

Building high-performing teams requires creating psychological safety and transparency as foundational layers for trust. Srihari describes a model with four zones (detached, anxiety, comfort, and learning) and advises moving teams to the learning zone by first increasing psychological safety before raising performance expectations. He also highlights the importance of understanding various architectural styles and domain-driven design, noting that no single architecture is superior—the right tool must match the problem domain.

Throughout the episode, Srihari shares personal experiences and practical advice, including using mind maps for knowledge capture, visual note-taking for learning, and the value of sharing knowledge with others. He concludes with three leadership wisdoms: treat people with respect, learn something every day and share that learning, and bring variety to your learning to have the right tools for different problems.

Recommendations

Books

  • Craft Your Code — Srihari’s book sharing his experiences and practices for software craftsmanship, with polyglot examples.
  • Clean Code — Robert C. Martin’s book on writing clean, maintainable code, referenced for its newspaper analogy for code organization.
  • Code Complete — Steve McConnell’s book on software construction, mentioned as a foundational work in the field.
  • Code Craft — Pete Goodliffe’s book on the practice of writing excellent code, cited alongside other industry stalwarts.
  • Thinking and Learning Refactory or Wetware — A book about how the brain works, pattern matching, and its relevance to understanding code aesthetics.
  • Refactoring Design Smells — A book on identifying design smells, technical debt, and strategies for repaying it.
  • Domain-Driven Design — Eric Evans’ book on tackling complexity in software, highlighted as an ‘eternal concept’ with strategic and tactical patterns crucial for architects and leaders.

Concepts

  • Visual Note-Taking — A method of capturing information visually, which Srihari collects and uses to understand storytelling and complex concepts.
  • Mind Maps — A technique for organizing information around a central concept, used by Srihari to share knowledge, teach, and reconnect with ideas.

Tools

  • Miro — A visual collaboration tool recommended for brainstorming, strategic planning, and creating mind maps with team collaboration.
  • Prettier — A code formatter mentioned as an example of tools that can automate code formatting to maintain consistency.
  • Pre-commit hooks — Recommended for automatically formatting code before commits to ensure consistency across the team without manual debate.

Topic Timeline

  • 00:00:00 — Introduction to Software Craftsmanship — Henry introduces the episode and guest Srihari Sridharan, author of ‘Craft Your Code’. They set the stage for discussing software craftsmanship, code quality, and becoming better engineers. Srihari shares his career journey spanning two decades across product and consulting roles, plus his work reviewing books for Manning Publications and bridging the curriculum gap for university students.
  • 00:09:57 — Motivation for Writing ‘Craft Your Code’ — Srihari explains his motivation for writing the book: to share his unique experiences and lessons learned from mentors. He wanted to create a polyglot book with examples from multiple languages. He also mentions a potential follow-up book exploring Generative AI in software development. The core intent is knowledge sharing and legacy, not financial gain.
  • 00:12:37 — Importance of Software Craftsmanship and Quality — Srihari argues that writing working code is the lowest bar. True craftsmanship involves writing clean, maintainable code. Despite technological advances (cloud, powerful IDEs), project failure rates remain high because individuals must prioritize quality and raise their own standards. He uses Apple’s self-comparison as an analogy: engineers should compare their work to their own past work, not others.
  • 00:16:17 — Root Causes of Low-Quality Code — Low-quality code often stems from a lack of understanding of how one’s work fits into the bigger architectural picture. Srihari stresses investing more time in design than coding, as a robust design makes translation to code easier. He advocates for automated coding standards (using linters, formatters) to provide immediate feedback to developers, reducing cycle time compared to downstream CI/CD feedback.
  • 00:20:42 — Consistency and Coding Standards — Consistency in code is crucial for pattern matching and familiarity, which aids understanding. Srihari introduces the concept of ‘consistency boundaries’—starting at the file level, then expanding to project and codebase levels. Following industry standards helps new team members onboard quickly. He advises automating standards via pre-commit hooks to avoid debates (like tabs vs. spaces) and ensure uniform formatting.
  • 00:24:34 — Code Aesthetics and Readability — Code aesthetics tie into visual appeal and pattern matching, reducing cognitive load. Srihari recommends organizing code like a newspaper article: public methods/interface implementations at the top, with details below. Use vertical spacing (blank lines) to separate concepts (loops, conditionals) and horizontal spacing for operators. Meaningful variable names are essential, and names should evolve with better domain understanding.
  • 00:34:21 — Effective Code Review Strategies — Code review approaches depend on version control strategy. Pair programming allows real-time review but requires team maturity and fair time-sharing. Trunk-based development with short-lived branches suits pair programming; feature branch development requires formal reviews. Srihari advises decentralizing reviews—avoid single points of failure. Have multiple authorized reviewers (core team members) and groom newer members. Consider having developers present their changes to the team periodically to increase familiarity.
  • 00:39:53 — Managing Technical Debt — The first step is recognizing when you’re incurring technical debt (code, design, or architectural debt). Capture debt items in the backlog (e.g., Jira) and prioritize them alongside features. Srihari uses the woodcutter analogy: you must sharpen your axe (repay debt/learn) to cut wood efficiently. Leadership buy-in is crucial; present facts on benefits. He warns against full rewrites without original developers, as new teams may incur debt from day one while playing catch-up with the evolving old system.
  • 00:46:49 — Building High-Performing Teams — Creating psychologically safe environments where team members can be their true selves is foundational. Transparency builds trust. Srihari describes a model with four zones based on psychological safety and performance accountability: detached, anxiety, comfort, and learning. To transform a team into the learning zone, first increase psychological safety (moving to comfort zone), then raise performance/accountability bars. This approach avoids the anxiety zone and has worked in his experience.
  • 00:52:29 — The Power of Mind Maps and Note-Taking — Mind maps help capture and organize complex information in a way that mirrors how the brain works (neuronal connections). Srihari uses them to share knowledge concisely, teach, and reconnect with concepts faster. He also advocates for visual note-taking to capture learning and storytelling. Taking notes (in books or separately) is essential for retaining and sharing knowledge.
  • 00:54:17 — Architectural Styles and Domain Knowledge — No architectural style (layered, microservices, event-driven, etc.) is inherently superior or inferior; the right choice depends on the problem domain. Srihari respects legacy systems as pioneers of craftsmanship. Complex solutions often combine multiple architectural styles for different bounded contexts. This connects to Domain-Driven Design (DDD), which he calls an ‘eternal concept.’ Strategic DDD helps leaders decide where to place their best people (core domain) and what to outsource (generic domain).
  • 01:02:56 — Three Technical Leadership Wisdoms — Srihari shares three pieces of wisdom: 1) Treat people with immense respect—it’s about working relationships, not who’s right or wrong. 2) Learn something every day, capture that learning, and share it with others. 3) Bring variety to your learning (e.g., different programming paradigms) to have the right tools for different problems. Use the appropriate technology stack for the problem domain.

Episode Info

  • Podcast: Tech Lead Journal
  • Author: Henry Suryawirawan
  • Category: Technology
  • Published: 2023-10-16T12:00:00Z
  • Duration: 01:06:54

References

Podcast Info

Transcript

[00:00:00] As people, as individuals, we need to change our ways of working where we give importance

[00:00:05] to the work that we do in terms of the quality that we deliver and ensure that we keep raising

[00:00:11] our bar.

[00:00:11] So software craftsmanship is something that we need to work on as individuals and also

[00:00:17] pass it on to the next generation of developers who work with you in your respective organizations

[00:00:21] so that they get to learn from you.

[00:00:23] I mean, you lead by example.

[00:00:24] Hey everyone, my name is Henry Suryawirawan and you’re listening to the Tech Lead Journal

[00:00:36] podcast, the show where I’ll be bringing you the greatest technical leaders, practitioners

[00:00:41] and thought leaders in the industry to discuss about their journey, ideas and practices that

[00:00:48] we all can learn and apply to build a highly performing technical team and to make an impact

[00:00:53] in your personal life.

[00:00:54] So let’s dive into our journal.

[00:01:24] And if you have been enjoying this podcast and its contents, support my work by either

[00:01:30] buying me a coffee at techleadjournal.dev slash tip or becoming a patron at techleadjournal.dev

[00:01:36] slash patron.

[00:01:38] My guest for today’s episode is Srihari Sridharan.

[00:01:42] Srihari is a software architect and the author of Craft Your Code.

[00:01:46] In this episode, we discussed software craftsmanship and how to become better software engineers.

[00:01:52] Srihari first began by teaching me how to make software.

[00:01:54] He described some practices for improving code quality, such as establishing coding

[00:02:02] standards, improving code readability, doing effective code review and managing technical

[00:02:08] debt.

[00:02:09] He also explained the importance of software engineers understanding different architectural

[00:02:14] styles and domain knowledge.

[00:02:16] Srihari also shared strategies for creating high-performing teams by establishing psychological

[00:02:21] safety and trust.

[00:02:24] I hope you enjoy listening to this episode and learn some insights about software craftsmanship

[00:02:28] and becoming a better software engineer.

[00:02:31] If you enjoy listening to this episode, please share with your colleagues, your friends and

[00:02:35] communities and leave a 5-star rating and review on Apple Podcasts and Spotify.

[00:02:40] Your small help will help me a lot in getting more people to discover and listen to this

[00:02:45] podcast and I really appreciate it.

[00:02:48] So let’s now go to my conversation with Srihari.

[00:02:53] Welcome to my podcast.

[00:02:54] Welcome to Tech Lead Journal podcast show.

[00:02:55] Today, we have Srihari here.

[00:02:57] Really looking forward to discuss things about software craftsmanship, how to make your software

[00:03:01] quality higher and things like that.

[00:03:04] So welcome to the show, Srihari.

[00:03:06] Hi, Henry.

[00:03:07] Thanks for the opportunity.

[00:03:08] So Srihari, in the beginning, I would like to ask you first to share your career journey.

[00:03:12] Maybe if you can give us some highlights or turning points that you think we all can learn

[00:03:16] from you.

[00:03:17] Sure, Henry.

[00:03:18] So I have close to two decades of industry experience working across different products and

[00:03:23] services organizations.

[00:03:25] I’ve been in both in product development as well as in the services side of things.

[00:03:30] We’re doing consulting with the clients on different domains and trying to solve complex

[00:03:34] problems.

[00:03:35] So that is my journey across this two decades across seven different organizations.

[00:03:40] And apart from my day job, I do reviews and proofreading for Manning Publications, which I

[00:03:45] started back in 2017.

[00:03:47] So I get to review the titles of interest and try to proofread them and provide feedback to the

[00:03:53] authors and closely interact with them.

[00:03:55] And that is why I think we also got connected through LinkedIn, discussing about books and

[00:03:59] stuff.

[00:04:00] And apart from that, as a pro bono activity, I do connect with a university here in Chennai,

[00:04:06] where I get to decide the curriculum for the students who are doing engineering as part of

[00:04:11] their studies.

[00:04:12] So this is to bridge the gap between the academic curriculum that is there today and what the

[00:04:17] industry actually wants.

[00:04:18] I mean, the curriculum should actually help them in two ways.

[00:04:20] Either it should help them find a job or help them for their higher studies.

[00:04:23] So I’m just trying to bridge the gap because the industry is very fast moving and there are a lot

[00:04:28] of changes that are coming our way.

[00:04:29] So that’s the idea, Henry.

[00:04:31] I mean, that’s a short summary of what I’m doing.

[00:04:34] This episode is brought to you by Miro.

[00:04:36] As you will hear in this episode later about the power of mind maps and note taking, finding a

[00:04:43] tool that can support creating comprehensive mind maps while also supporting collaboration can be

[00:04:48] quite a challenge.

[00:04:49] One tool I find that allows us to do so effectively.

[00:04:53] And in a fun way is Miro, M-I-R-O.

[00:04:58] At a first glance, it might seem just like a simple digital whiteboard, but Miro’s capabilities run far

[00:05:04] beyond that.

[00:05:05] It’s a visual collaboration tool where the whole team can build on each other’s ideas and create

[00:05:11] something innovative together from anywhere.

[00:05:14] Brainstorming and strategic planning become easier when it’s visual and accessible, and it can all

[00:05:20] happen across teams in Miro.

[00:05:22] You can quickly start.

[00:05:23] You can start collaborating within 90 seconds without having everyone registered as a Miro user before.

[00:05:29] There are also more than 300 predefined templates you can use to kickstart your collaboration within seconds.

[00:05:36] So the next time you’re looking for a digital tool to support your brainstorming, designing, planning, and

[00:05:42] online collaboration, do give Miro a try.

[00:05:45] You can sign up today at Miro.com slash podcast, M-I-R-O.com slash podcast, and your first three Miro

[00:05:53] boards are free forever when you sign up now.

[00:05:56] And now let’s get back to our episode.

[00:05:58] Thank you so much.

[00:05:59] Very interesting.

[00:06:00] You have a day job in a consulting company.

[00:06:02] You also review books, right?

[00:06:04] I think you are part of the reviewers of many great titles from Manning.

[00:06:08] And the last one you do pro bono for university.

[00:06:11] So maybe a little bit, if I can ask about your pro bono part, right?

[00:06:14] So you have been helping the university to bridge the gap, and you are also now the author of The Craft Your Code.

[00:06:20] Where do you see the biggest gap between universities?

[00:06:23] Students, and also from the practical side of you, when they go into the job as a software developer?

[00:06:29] Yeah, definitely.

[00:06:30] I mean, things have improved a lot in the current situation.

[00:06:34] I mean, a lot of students get to study about programming languages and stuff early in their school days.

[00:06:40] When back then, when we used to study, probably we were not so lucky to read programming languages early.

[00:06:47] But again, today I see students are reading much earlier.

[00:06:50] So what happens when they come to the university?

[00:06:52] The subjects?

[00:06:53] So you need a revision.

[00:06:54] I mean, revision in the sense, what is going to make you do things practically?

[00:06:59] Like how will you be able to work, apply your skills that you learn in the industry?

[00:07:04] How you get industry ready?

[00:07:05] Because the industry is moving at a very fast pace, given that you have generative AI and other stuff today.

[00:07:10] How do we equip students to adjust to the new curriculum?

[00:07:13] Forget students, even professionals as we need to adjust ourselves to the new modern world in terms of the current demands, right?

[00:07:21] So that is where I try to look at it.

[00:07:23] I 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 you 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.

[00:07:43] So, for example, when I studied, we never had papers on data science, data science did not exist back then, but data warehousing and other stuff was there.

[00:07:52] I’m talking about two decades ago.

[00:07:53] So data warehousing was there, databases were there.

[00:07:56] I think we were lucky enough to grow along with the languages and frameworks.

[00:07:59] 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 matured.

[00:08:07] Every framework has matured.

[00:08:10] A lot of features have come into the frameworks and languages, and there are a lot of streams as well.

[00:08:15] I mean, we are looking more at specialization, right?

[00:08:17] I mean, the subjects in the streams are getting very specialized from a educational standpoint.

[00:08:22] So that is when we did.

[00:08:23] So when you 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?

[00:08:33] Right.

[00:08:34] Maybe towards then when we discuss about architecture, we’ll discuss about the importance of having the bigger picture.

[00:08:38] Right.

[00:08:39] 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.

[00:08:47] And there are things that you know, but you don’t know.

[00:08:49] Basically, you don’t know that such a thing exists.

[00:08:51] But you know, something exists, but you don’t know about it.

[00:08:53] And the third thing is you don’t know and you don’t know.

[00:08:55] You don’t know what exists and you don’t know such a thing exists.

[00:08:58] Right.

[00:08:58] 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.

[00:09:07] So that’s the idea of bridging this gap, Henry.

[00:09:10] Yeah.

[00:09:10] A little bit empathy as well for those students or the new people who just graduated.

[00:09:14] Right.

[00:09:14] So there are so many things in technology these days.

[00:09:17] Right.

[00:09:17] You just mentioned generative AI.

[00:09:18] Maybe that’s the buzzwords this day.

[00:09:20] Previously, data science.

[00:09:21] Right.

[00:09:22] Previously, blockchain.

[00:09:22] And so many other things that keep coming along.

[00:09:25] Right.

[00:09:25] I think it’s really, really a big challenge for all those people, including me, myself.

[00:09:30] I can’t keep up with all these changes as well.

[00:09:32] So I think your work is really, really tremendous in terms of helping them bridging the gap.

[00:09:36] So moving on to maybe that’s why you write this book, right?

[00:09:40] Craft Your Code.

[00:09:41] Because I had a look and read off your book in a glance.

[00:09:44] Right.

[00:09:44] So you cover the breadth of the technology from software engineering point of view.

[00:09:48] Right.

[00:09:49] So maybe if you can share a little bit, what was your motivation behind?

[00:09:52] Writing this book, right?

[00:09:54] So maybe we can learn from that story itself.

[00:09:57] Definitely.

[00:09:57] So one cool thing that happened is it was back in 2018 when I was actually having this idea of writing this book.

[00:10:04] And just to explain that journey, right?

[00:10:06] I had the idea, had the proposal to write the book, but again, maybe I wasn’t so popular, I would say.

[00:10:13] 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 Craft Your Code.

[00:10:21] Because you have.

[00:10:22] Industry stalwarts like Robert C.

[00:10:24] Martin, who wrote Clean Code, you have Steve McConnell who wrote Code Complete, you have Pete Goodlife who wrote Code Craft and a lot of things, right?

[00:10:32] And when you as an engineer, as a person want to write something about it, I mean, all of this is about your experience.

[00:10:38] Again, knowledge is borrowed, but the experiences are unique.

[00:10:41] 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.

[00:10:50] I just want to share that knowledge.

[00:10:52] With others and make it available.

[00:10:54] So that is the whole motivation of actually coming up with this idea of writing a book.

[00:10:59] And I wanted to make it a polyglot in the sense, give examples from multiple languages, right?

[00:11:05] 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 Gen-AI for software development and Craft Your Code.

[00:11:18] So that’s the idea again, it’s in its early stages.

[00:11:21] So.

[00:11:22] I cannot comment more on it, but the idea is about sharing that knowledge, which is the core.

[00:11:27] And as you know, authors don’t write books to become rich.

[00:11:30] The intent is not to make money, but the intent is to share the knowledge.

[00:11:33] So that is the background of this book, Henry.

[00:11:37] Henry Suryawirawanan Yeah.

[00:11:37] Thanks for sharing the background.

[00:11:38] Right.

[00:11:38] So, yeah, I mean, for people who don’t know yet, authors write book not to get rich, right?

[00:11:44] Maybe some authors do because of the royalties and all the other things outside of the book.

[00:11:48] Right.

[00:11:49] But I think the first thing is about instilling their knowledge and share it with others.

[00:11:52] And it’s also about the legacy.

[00:11:55] Yeah.

[00:11:55] Sorry to cut you.

[00:11:56] I mean, it’s also about the legacy, Henry.

[00:11:58] I mean, leaving behind something for others to consume, right?

[00:12:02] Henry Suryawirawan That’s correct.

[00:12:03] And also, yeah, like you mentioned, I find something interesting about your book, right?

[00:12:06] You actually use polyglot languages, right?

[00:12:08] So this is, I think, quite rare as well.

[00:12:10] I don’t see much technical books also using multiple languages.

[00:12:13] There’s pros and cons to that, but I think, yeah, this is quite unique in a sense.

[00:12:18] So if I read your book, I think if I can pick a theme, one is about software, craft,

[00:12:22] craftsmanship, and the other one is about high-quality code.

[00:12:25] So maybe if you can touch on a little bit from your industry experience, two decades, right?

[00:12:29] Well, what do you see why it is important for engineers to look into the aspects of software

[00:12:34] craftsmanship and also high-quality code?

[00:12:37] Henry Suryawirawan Definitely.

[00:12:38] So the first thing, right?

[00:12:39] I mean, writing code that works, I mean, that’s the very lowest bar.

[00:12:42] I mean, anybody can cross that bar of writing code.

[00:12:45] Again, writing code that you yourself understand after six months of being in a project or

[00:12:50] somewhere is vital.

[00:12:51] I mean, you’re not going to do good to others, but do good to yourselves by writing some

[00:12:56] clean code, which you can understand in six months’ time, right?

[00:12:58] I mean, as prominent authors like Robert used to say.

[00:13:01] So the essence of software craftsmanship as such, if you just rewind the whole two decades

[00:13:07] of the industry or three decades of it, right?

[00:13:10] Back then, we did not have cloud.

[00:13:12] We did not have sophisticated systems.

[00:13:15] We did not have a lot of RAM and a lot of processing power.

[00:13:19] We did not have SSDs, right?

[00:13:20] Right.

[00:13:21] Right.

[00:13:21] Right.

[00:13:21] Right.

[00:13:21] Right.

[00:13:21] Right.

[00:13:21] We did not have anything.

[00:13:22] We did not have powerful IDEs.

[00:13:24] But today, we have all of them.

[00:13:26] But still, projects fail.

[00:13:28] Still, the cost of software development is pretty high.

[00:13:31] And still, getting it right is very rare, right?

[00:13:34] The success rate is like hardly 15%, 16%, or less than 20% maximum.

[00:13:38] Either it shoots by budget or by time or by any resource, right?

[00:13:42] So why does that happen?

[00:13:43] So the problem lies with us as individuals.

[00:13:46] As people, as individuals, we need to change our ways of working where we give important

[00:13:51] importance to the work that we do in terms of the quality that we deliver and ensure

[00:13:56] that we keep raising our bar.

[00:13:57] Again, here, probably, I’d like to quote an example of Apple, right?

[00:14:01] Apple never compares themselves to other products.

[00:14:03] They compare themselves to their own products.

[00:14:05] So if you see iPhone 15, it’s better than iPhone 14 by so-and-so terms, right?

[00:14:09] I mean, same way, the code that you write, the software that you write, the development,

[00:14:13] don’t compare with others.

[00:14:14] Just compare yourself with your own work, right?

[00:14:16] Try delivering better quality in terms of the code that you write, the documentation

[00:14:20] that you generate.

[00:14:20] The attention to detail that you provide, the care that you take, that shows how much

[00:14:25] you love your profession or how much you give importance to the quality, right?

[00:14:30] I mean, it is all about, again, passion meeting profession.

[00:14:33] It happens for a few people.

[00:14:34] At the same time, you can also use your profession to fuel your passion, right?

[00:14:38] Either ways.

[00:14:39] So software craftsmanship is something that we need to work on as individuals and also

[00:14:44] pass it on to the next generation of developers who work with you in your respective organizations

[00:14:48] so that they get to learn from you.

[00:14:50] Yeah.

[00:14:50] Yeah.

[00:14:50] Yeah.

[00:14:50] You lead by example.

[00:14:51] I mean, all of these principles you would have seen in management books.

[00:14:54] I’m just trying to connect the dots.

[00:14:55] How from a software development angle and a craftsmanship angle, you can lead by example

[00:14:59] and also learn from them.

[00:15:01] So learning is always a two-way street.

[00:15:03] The fresh minds who come into the industry, they have a fresh perspective looking at the

[00:15:06] code and the system and they can do their feedback.

[00:15:08] So be open to feedback.

[00:15:10] So learn from people who are younger than you.

[00:15:12] They are much faster in learning something than you possibly.

[00:15:15] You might have the experience, but they have the speed.

[00:15:17] So instead of competing, it’s like complementing each other.

[00:15:19] Together, you solve a problem.

[00:15:20] So that is my view about software craftsmanship and writing clean code.

[00:15:26] Right.

[00:15:26] So I think when you explain that, it intrigued me, right?

[00:15:29] The fact that the technologies have moved so advanced so rapidly.

[00:15:33] We have so many choices, programming languages, cloud, you know, infrastructure.

[00:15:38] I don’t know.

[00:15:38] So many exotic things happening, right?

[00:15:40] But still, we have the fact that projects fail.

[00:15:43] The cost of the project is really, really high.

[00:15:46] And yeah, sometimes it also doesn’t meet the user requirements, right?

[00:15:48] So I think it’s a true fact.

[00:15:50] Plus one thing that I just want to add.

[00:15:52] We have these kind of resources, the books that are available since long time as well.

[00:15:56] You know, like those clean code refactoring, TDD, XP, all exist, like, I don’t know how many decades ago, right?

[00:16:02] But still, we have this problem that software engineering is sometimes tricky to deliver, right?

[00:16:06] So maybe in your view, right, maybe also touch on from your books, what are some of the root causes of low quality code?

[00:16:13] Maybe if you can highlight some of the categories for us here to remind ourselves.

[00:16:17] So low quality code in the sense, I mean.

[00:16:20] Again, first things, the code should align with the architecture, the overall architecture, the bigger picture, right?

[00:16:27] So that is where, I mean, we’ll again touch upon visualizing architecture for the developers towards the end.

[00:16:32] 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.

[00:16:45] So you have a feature, a set of modules work together to provide you the feature.

[00:16:49] So within the module.

[00:16:50] You will have class and components that interact with each other, and then you get it working, right?

[00:16:54] 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 the acceptance criteria, whatever you call it, right?

[00:17:07] So that it meets the requirements of the user.

[00:17:10] So in essence, the overall quality depends upon the understanding that people have, right?

[00:17:18] The moment you understand the problem.

[00:17:19] You can.

[00:17:20] Easy.

[00:17:20] Design it.

[00:17:21] 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?

[00:17:30] Again, with gen AI and other, other tools that you get the path programming assistance, it is going to help you code faster is what we observe.

[00:17:38] At least that’s the claim today.

[00:17:39] 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.

[00:17:48] We cannot ignore and move on, right?

[00:17:50] People who embrace these assistants, they’ll get to code faster.

[00:17:54] So maintaining that code quality is important.

[00:17:57] Having coding standards within the team and the project is important.

[00:18:01] And most importantly, trying to automate this coding standards.

[00:18:04] I mean, having coding standards, not every human being can or developer can remember all of these standards day in, day out, right?

[00:18:11] We need to see how we can provide faster feedback by automating this coding standards.

[00:18:15] So let’s say you get a coding standard, you have some PMD textile kind of stuff, or you have the.

[00:18:20] Okay.

[00:18:20] X corp and style corp on the dot, or some linters in terms of JavaScript and drive slip, which provides developers with immediate feedback on code quality.

[00:18:28] 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.

[00:18:39] Instead, if you try to get that feedback ahead of time, that is going to be much more useful to developers.

[00:18:46] So that’s the whole idea.

[00:18:48] Arif Karim- Thank you for sharing that, right?

[00:18:49] I think it’s a,

[00:18:50] It’s very interesting when you said that, you know, understanding is the first thing, right?

[00:18:54] Sometimes all engineers just want, you know, to straight away write the code.

[00:18:58] You give me what you want and I’ll just write the code.

[00:19:01] But I think in so many good practices that is advocated by the thought leaders out there,

[00:19:06] understanding the problem, understanding the requirements, coming up with the right design.

[00:19:10] Of course, it doesn’t have to be very heavy weight and, you know, take a long time to come up with, right?

[00:19:15] But actually, you do need to take time to actually understand what kind of software that you want to build.

[00:19:19] And I think from my experience as well, right, building a good, robust system, you know, you need to plan it, right?

[00:19:25] You cannot just come up with the perfect software design by just writing the code all the way from the low level, right?

[00:19:31] So I think that’s a very good thing.

[00:19:33] One thought I would like to add to that, Henry.

[00:19:35] I mean, design one-pagers are definitely helpful.

[00:19:38] I mean, you need to write the design one-pager, write a wiki page or a confluence page,

[00:19:43] which actually helps you share your thought process with the team.

[00:19:46] Let’s say you’re doing path programming as a part.

[00:19:48] And you want to communicate your design and get it sorted out with your technical lead.

[00:19:52] Write a one-pager which contains or outlines the overall design that you’re thinking for solving the problem.

[00:19:58] And also document how it is staying in line with the existing architecture that is there, right?

[00:20:03] And present it to the audience, get to the feedback, and then probably get into coding it.

[00:20:09] Then it’s going to decrease your back and forth loops that you’ll have in rework and all this stuff.

[00:20:15] Right.

[00:20:15] And you mentioned just now about coding standards, right, and that we have to automate it.

[00:20:20] I think that’s the first thing.

[00:20:21] In the past, I used to do it manually.

[00:20:23] So I think it really, really relies heavily on your brainpower, right, to actually align with the coding standards.

[00:20:29] Don’t do that, right?

[00:20:30] Use automation as much as possible.

[00:20:32] And I also find something related to standards that I just want to highlight from your book, right?

[00:20:37] You mentioned that high-quality code, if you follow the coding standards, right, it is as if written by a single developer.

[00:20:42] Even on one file that is, you know, modified by the developer.

[00:20:45] It’s not modified by multiple people.

[00:20:47] So why I said that, yeah, I can explain to you.

[00:20:50] So one of the important things is consistency.

[00:20:54] When it comes to looking at code, when it comes to aesthetics of your code, our brain usually forms patterns.

[00:21:00] Take this example, right?

[00:21:01] You see somebody, say your childhood friend, after 10 years, you are able to recognize this person, right?

[00:21:07] Hey, how are you?

[00:21:08] So how the brain works, it works based on pattern matching.

[00:21:10] So it matches the pattern of the person and it kind of calculates, okay, this is how this person looks now.

[00:21:15] I can see the resemblance.

[00:21:17] That resemblance is the important factor with respect to code in terms of familiarity.

[00:21:21] And that familiarity is nothing but standards, right?

[00:21:24] You see a piece of code that adheres to a standard, you know what it does, how it does, easy to read.

[00:21:29] Let’s say you have certain ways of structuring your conditionals and loops and all this stuff, the fundamental elements.

[00:21:35] Even the, let’s say, for example, you write streams or link code in streams in Java and link in C sharp.

[00:21:40] The way you formulate your query and the way you write your query, right?

[00:21:43] Imagine you write a SQL query.

[00:21:45] If you put your columns in a single line, it’s going to be very difficult to read everything.

[00:21:49] 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.

[00:21:57] It helps you to easily grasp and understand that concept of what you’re trying to do.

[00:22:01] Because code is written once, a study that claims that code is written once but read 10 times.

[00:22:06] So this kind of a pattern matching is crucial for understanding your code.

[00:22:11] And now when it comes to the standard, at times you get to modify legacy code.

[00:22:15] Legacy code, in the sense of code that is old or Brownfield applications for that matter, right?

[00:22:20] I have huge respect for legacy systems.

[00:22:22] I’ll get to that shortly.

[00:22:23] But when you see the Brownfield coder 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.

[00:22:30] Minimum the file level because that is the consistency boundary.

[00:22:33] I look at the code one file at a time.

[00:22:36] So you can at least ensure that the minimum amount of consistency is maintained at the file level.

[00:22:42] So that the key is to be consistent.

[00:22:44] That’s the first step.

[00:22:45] Next question.

[00:22:45] Okay.

[00:22:45] Well, that’s my final thought.

[00:22:45] The reason is, let’s say you want to fix something, you can go and fix it in all the places in

[00:22:50] one go because you know the consistent pattern where it is written in a consistent manner

[00:22:54] and let us say that needs to be addressed, you can go and address it.

[00:22:57] When there is lack of consistency, it’s going to make things difficult.

[00:23:01] There is another angle to consistency, which is following industry standards.

[00:23:04] Why should teams follow industry standards?

[00:23:06] Because let us say you have a new person joining your team.

[00:23:09] Now, this new person joining the team is going to be the lowest common denominator.

[00:23:13] So when you communicate something, when you share knowledge, when you discuss about your

[00:23:17] problem domain or discuss about a solution, you need to ensure that this person understands.

[00:23:22] That is how you build an inclusive environment where the person understands this whole thing.

[00:23:26] So doing something that is consistent with the industry standards and maintaining that

[00:23:30] consistency at the file level to start with and then at the project level and then at

[00:23:33] the code base level will help you ensure that people can quickly come in from outside and

[00:23:39] grasp and start being productive.

[00:23:41] So that’s the reason I wrote about.

[00:23:43] That consistency boundary within the file, and then you slowly expand it to the project

[00:23:47] and then to the entire code base, right?

[00:23:49] So that’s the idea, Henry.

[00:23:51] Yeah, it’s very interesting when you mentioned about consistency boundaries, right?

[00:23:54] We’re talking about how to write code consistently, well, you know, within your code base.

[00:23:59] So I think that’s really, really powerful, right?

[00:24:01] If you get it right within a team and it will be even more powerful within a company, right?

[00:24:05] I know that in Google, right, they all have these coding standards.

[00:24:08] They can automate it and it’s as if, right, the whole company is written by the same kind

[00:24:12] of standards.

[00:24:13] And same kind of people, right?

[00:24:15] So I think that’s really, really powerful.

[00:24:17] And you touch on a little bit about aesthetics part of the code base when you say about, you

[00:24:20] know, formatting your stream or maybe the way you write queries.

[00:24:24] So maybe not all software engineers are taught about this aesthetics part, right?

[00:24:29] Maybe a little bit touch on, elaborate more.

[00:24:31] Why aesthetics so, so much important?

[00:24:34] How can they start doing it right?

[00:24:36] Sure.

[00:24:36] I mean, aesthetics again ties down to your visual appeal of the code base.

[00:24:40] So as I mentioned earlier, I spoke about pattern matching.

[00:24:43] So there is a very good book that I would suggest folks to take a look at, which is

[00:24:47] thinking and learning refactory or wetware, which is about how the brain works and the

[00:24:52] pattern matching and all this stuff.

[00:24:53] So the moment you have that consistency and the way you lay out your code, say, for example,

[00:24:59] all the variables that are used in a class, say an object oriented programming paradigm

[00:25:04] should be organized properly at the top.

[00:25:07] So as Robert C. Martin calls it, he also gives that newspaper analogy, right?

[00:25:11] When you read a newspaper article,

[00:25:13] he speaks about having the very gist of the news and then going into the details of the

[00:25:18] then summarizing.

[00:25:19] So people who have a lack of time, who are not so interested in your news, they’re just

[00:25:24] going to read the first paragraph or the headline and probably move on.

[00:25:27] Those who are interested will dive deep into it.

[00:25:29] The same is applicable to the code.

[00:25:31] When you put your public methods that are implemented by an interface or this particular

[00:25:35] class that implements the interface, you’re going to have this at the top of the file.

[00:25:39] So you clearly demark it and communicate like this is what this.

[00:25:43] Lance is doing.

[00:25:43] These are the responsibility cells class.

[00:25:45] And if somebody is more interested, they’ll probably drive into the stuff that is below,

[00:25:49] which is the private methods and other stuff, right?

[00:25:52] So aesthetically, you need to organize your code such that the concepts are well encapsulated,

[00:25:56] well split within the file.

[00:25:58] So let’s say you have a class in a file and then you have the members properties, methods, the

[00:26:03] constructors, the methods, and then the private methods.

[00:26:05] That is a neat way to organize it aesthetically.

[00:26:08] And the aesthetics also boils down to putting things together in terms of stuff that is a

[00:26:12] little.

[00:26:13] And putting things that are not related separately in the sense, let us say you’re trying to do

[00:26:18] something within the loop or a for loop or a while loop or whatever, right?

[00:26:22] What are we doing within that loop is a very kind of a closed construct, right?

[00:26:26] What are you trying to do within the iteration?

[00:26:28] What is outside of it?

[00:26:29] If you leave a blank line next to this loop, the line where it ends and then leave a blank

[00:26:34] line and then start the next possible line clearly gives you a separation between this

[00:26:39] and the next concept that is coming up, right?

[00:26:43] So the same is applicable to if blocks, else blocks, switch cases, and all this stuff, all

[00:26:47] this constructs.

[00:26:48] So anytime there is an indentation, the indentation that takes your code towards the right, if

[00:26:53] you take Python, there are no brackets, it’s all indentation, right?

[00:26:57] So the way you write your code, it should be, there should be a clear demarcation between

[00:27:01] these concepts.

[00:27:02] So that is your vertical way of organizing your code aesthetically.

[00:27:07] When it comes to horizontally organizing, as you might know, leaving spaces between

[00:27:11] operators and variables.

[00:27:12] And then.

[00:27:12] Assignment and variable living spaces, wherever required, writing the comments in a very clean

[00:27:18] manner, in a very concise and understanding, and all of this boils down to aesthetics.

[00:27:22] So visually, when you see the code, when it is aesthetically pleasing, it is easier to

[00:27:26] work with it.

[00:27:27] It’s welcoming for the developers who are new to the system rather than that.

[00:27:31] If your code is not visually consistent or aesthetically pleasant, then probably you

[00:27:35] take a step back and say, okay, it takes me some time to understand this.

[00:27:38] So make your life easier, right?

[00:27:40] I mean, make everyone’s life easier.

[00:27:42] So after all, software development should be fun, in my opinion.

[00:27:45] So giving importance to aesthetics is really crucial when reading code is done more

[00:27:51] frequently than writing it.

[00:27:53] Henry Suryawirawan Right.

[00:27:53] You mentioned about visually appealing.

[00:27:55] I think it also helps a lot for your cognitive load for your brain, right?

[00:27:58] To actually read the code because you mentioned that the code is written once, read 10 times

[00:28:03] or even more, right?

[00:28:04] So you need to help yourself, right?

[00:28:06] In order to actually understand what you read.

[00:28:09] I mean, another thing, right?

[00:28:10] It’s about writing code.

[00:28:11] That is.

[00:28:12] Understandable by everybody.

[00:28:14] Meaning, say for example, why are we using English in programming more?

[00:28:18] The reason is English kind of is a widespread language that many of us understand, right?

[00:28:24] At least the majority understands English and using variable names that can be spelled

[00:28:29] properly is very important.

[00:28:31] I mean, back then we had challenges with memory and other things where we used to shorten

[00:28:35] the variable names and a lot of the things in the past.

[00:28:38] But given that those things are no more a problem, even you have typing assistants,

[00:28:42] from your IDEs, even if you give a meaningful name, it is not very hard to type.

[00:28:46] You just put a control space and a command space and move on, right?

[00:28:50] So giving meaningful variable names that are readable is crucial for understanding your

[00:28:55] code.

[00:28:55] I mean, naming, as you know, naming and caching, the two important problems or difficult problems

[00:28:59] to solve is to went to invalidate the cache and naming things, right?

[00:29:03] So naming definitely invest time in giving proper names and never worry about revisiting

[00:29:09] your names.

[00:29:10] Meaning once you name something.

[00:29:12] Yeah.

[00:29:12] The way you get a better domain understanding down the line, you will need to revise your

[00:29:17] ubiquitous language from a domain driven design standpoint to see if a better word or a better

[00:29:22] term conveys that meaning in a better way.

[00:29:26] So that is another piece of input.

[00:29:28] I just want to add on maybe as part of the aesthetics, right?

[00:29:31] So the few things that I feel that some engineers do not actually realize yet are actually powerful.

[00:29:36] So things like vertical new line, like you mentioned, vertical space, sometimes just

[00:29:40] adding new lines.

[00:29:41] It’s in between some sections of your code.

[00:29:44] Actually, that’s really powerful.

[00:29:45] And the second thing is about maximum width that you can expand to the right, right?

[00:29:49] So I think some teams actually enforce the maximum width so that you don’t scroll to the

[00:29:55] right.

[00:29:55] I have some interesting stories there.

[00:29:58] So once upon a time, there was one of the developers who I was working with.

[00:30:02] Two stories.

[00:30:02] One is one of the developers who I was working with, he used to write very long methods.

[00:30:08] I mean, this was back when I was in the US, like I used to asking, why is it your methods

[00:30:11] are long?

[00:30:12] Then he told me like, okay, my methods are long because whenever it crosses my screen

[00:30:16] limit, I tend to break it to a new method.

[00:30:19] Okay.

[00:30:19] That seems to be a very interesting yardstick to break into a new method.

[00:30:23] Then I thought, even then you should be breaking it both half the size of it or even three by

[00:30:28] fourth of it.

[00:30:28] Why are you taking so long?

[00:30:29] Then I went and visited his desk.

[00:30:31] So he had the monitor in portrait mode where the monitor was actually in a portrait mode

[00:30:37] and he was trying to break a line when it enters the next screen.

[00:30:39] So I mean, it might sound.

[00:30:41] Funny, right?

[00:30:42] I mean, the most important thing is to adhere to single responsibility principle, right?

[00:30:46] Single responsibility is not that it crosses your screen limit, but instead to try to see

[00:30:50] how to have a well-defined responsibility for a given method that you’re writing.

[00:30:54] I mean, don’t do more than one thing as Robert says.

[00:30:56] Another instance was, I was again working with a set of folks who actually write long

[00:31:01] lines, which make you scroll to the right and then read the code and then come back.

[00:31:05] So it feels like you are doing typewriting work where the head goes to the right and

[00:31:09] then comes back to the reset.

[00:31:10] I mean, those who have seen typewriting.

[00:31:12] So the comment that came was like, I was asking, like, why do you do that?

[00:31:15] They have very wide monitors.

[00:31:17] We don’t find any challenges in working with such a code.

[00:31:19] It was like, okay, you might have white monitors, but doesn’t mean you should make others suffer.

[00:31:23] I mean, some people might have smaller screens, right?

[00:31:26] Not only that, I mean, research has shown that beyond the point, the cognitive load

[00:31:30] increases when you keep scrolling and going back and forth.

[00:31:32] And then all of this stuff, right?

[00:31:34] When you write long methods or when you write horizontally long lines, the cognitive load

[00:31:38] on readability is going to be more on the reader.

[00:31:41] It’s very difficult.

[00:31:41] It’s very difficult to understand the whole stuff.

[00:31:44] I mean, even I would say for methods, if the number of arguments is more than three, in

[00:31:50] my view, I think the method is doing more than what it is supposed to do.

[00:31:54] But you are not probably folding things into a data structure and then sending it to the

[00:31:57] method.

[00:31:58] Instead, you are sending in arguments that are separated.

[00:32:01] So try to see how you can make it coercive in terms of method arguments that go into

[00:32:04] a method.

[00:32:05] At the same time, try to see if you can stick to that 60 to 80 character limit.

[00:32:08] Again, this is all proven by research.

[00:32:10] I think that I researched.

[00:32:11] But again, people before me, they have done the research and given the results.

[00:32:14] Thank you for such a fun story, right?

[00:32:16] I think that’s completely right.

[00:32:17] So the reason why you don’t want to have like a too long to the right is because, yeah,

[00:32:22] you have to be inclusive, right?

[00:32:23] Not everyone has the same set of monitors and resolutions as you.

[00:32:26] Sometimes we work on laptops, right?

[00:32:28] Because we travel.

[00:32:29] So yeah, please do set MaxMid.

[00:32:31] The other thing I just want to add, right?

[00:32:32] Not to start a debate or something, right?

[00:32:35] Tab versus space for indentation, right?

[00:32:37] So I think need to be consistently set, even though ID now helps you.

[00:32:41] No matter whether you set tabs or, you know, space, but sometimes you

[00:32:44] have to go to terminal, sometimes you go VI, right?

[00:32:48] Another fun story, I guess.

[00:32:50] I have a solution.

[00:32:52] Not a fun story.

[00:32:53] I have a solution.

[00:32:54] So the solution is, see, don’t debate, first of all.

[00:32:59] Because you’re in your productive time debating on real things, right?

[00:33:02] Especially tabs and spaces.

[00:33:03] So the essence is, try to use formaters that are built for specific languages, right?

[00:33:09] Say for example, Visual Studio Extensions, like Prettier.

[00:33:11] Do you know what I’m talking about?

[00:33:11] They do a great job in formatting your code.

[00:33:13] My solution is to use a pre-commit hook, right?

[00:33:16] A pre-commit hook, which formats the code in a uniform manner for every developer.

[00:33:21] So before they commit, this hook runs, format it in a very consistent way,

[00:33:25] because I don’t want to see diff in the code, which was actually not modified.

[00:33:29] Just because of formatting, you will see a lot of diff here and there, but

[00:33:32] actually it would have been a couple of lines that got modified end of the day.

[00:33:35] So what really happens is the consistency is maintained when you use this kind of

[00:33:39] formatting tool and a pre-commit hook.

[00:33:41] Which helps you achieve that consistency across the board.

[00:33:44] I mean, everybody in the team, they can have their own settings and their own IDEs, which is fine.

[00:33:49] You put tabs, spaces, whatever you want to do it.

[00:33:51] There’s no point to debate.

[00:33:52] I’ll just, as a tech lead, I’ll just go out and set a pre-commit hook, which does the job.

[00:33:56] Yeah, that’s a very powerful advice, right?

[00:33:59] So automate as much as possible and do set convention within your team, right?

[00:34:03] And no debates, right?

[00:34:04] Like you shouldn’t debate so much about it.

[00:34:06] I mean, like, it’s not to say that.

[00:34:07] No, debate.

[00:34:08] I mean, debate is healthy.

[00:34:10] Debates are healthy.

[00:34:10] Definitely debate.

[00:34:11] But on worthy things.

[00:34:12] That’s correct.

[00:34:13] Okay.

[00:34:13] So let’s move on to maybe other aspects of software engineering, where it also

[00:34:17] determines the code quality, right?

[00:34:19] So I’m talking about code reviews.

[00:34:21] Now that you maybe follow convention, follow standards, you write the code, right?

[00:34:25] The other aspects is actually someone reviewing it.

[00:34:27] Is there anything that you want to elaborate here on how we can

[00:34:31] become a better software craftsman?

[00:34:33] Yeah, definitely.

[00:34:34] So for code reviews, before touching upon code reviews, I’ll probably touch upon

[00:34:37] the version control strategies or the approaches that you take, because version

[00:34:41] control studies and your programming approach actually has an impact on code reviews.

[00:34:46] So first things first, path programming is an excellent concept, which actually you

[00:34:50] have a programmer, you have a driver and you have a person who is pairing along

[00:34:54] with you, who’s a navigator, who keeps looking at your code in real time.

[00:34:58] Again, for team startup path programming, you need certain amount of maturity because

[00:35:02] there are some path programming IT patterns.

[00:35:04] So you should have a fair timeshare between both the developers who are writing code.

[00:35:09] So it’s not like one person will always be writing code.

[00:35:10] The other person is always a navigator.

[00:35:13] Those kinds of things cannot happen.

[00:35:14] You should not be having pair affinity where the same developer gets to pair with the other person, right?

[00:35:18] Those kinds of things cannot happen.

[00:35:20] When you do this path programming, the other person gets to review the code on the fly, gives you the feedback.

[00:35:25] So it actually essentially cuts down on your cycle time.

[00:35:28] What is a pro and a con?

[00:35:29] The pro is that you get to ask that feedback and you can easily incorporate the feedback in terms of the review

[00:35:34] comments that might potentially come.

[00:35:36] Three requisite is the expertise.

[00:35:38] Developers who are pairing.

[00:35:41] At least should have a fair amount of understanding of the coding standards followed in the project.

[00:35:45] They need to understand things.

[00:35:47] 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.

[00:35:53] There is a new developer coming in as a pair.

[00:35:55] You can probably pair them with an existing developer who knows the standards very well.

[00:35:59] 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.

[00:36:05] So this goes well with trunk based development where you commit to the main line instead of having features.

[00:36:10] The branches are also leading to have short load branches, as you might know.

[00:36:14] But again, this might not be possible in certain scenarios like regulatory environments or public sector work that you’re getting to do.

[00:36:23] And these kinds of things don’t let you work with people.

[00:36:26] Drunk based development is not possible to be used in those cases.

[00:36:30] 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 police branch or a development branch or a master, whatever, right?

[00:36:39] Typically, we catch them.

[00:36:40] We have a development branch.

[00:36:42] And from the development, you have a release branch.

[00:36:44] You keep committing to release and development.

[00:36:45] And then once that release goes out, then the main hot fixes and bug fixes happen in the master.

[00:36:51] And then they are merged back into this.

[00:36:53] So all of these steps require you to have proper code reviews being done.

[00:36:58] And the most important thing is to decentralize this whole process.

[00:37:02] In my view, I mean, one person should not be responsible for code reviews, which actually increases the cycle time and more developers.

[00:37:10] So you have to have the challenges of going back and forth in a sense, like, let’s say there is a dev, a dev pair who is working on waiting for a review, and then by the time you have a lead, let us say you’re reviewing it, you are the single point of failure then, right?

[00:37:20] So you go on off, then the reviews get piled up and you cannot review and respond to it in a timely manner.

[00:37:26] And what happens, these devs keep waiting for you.

[00:37:28] And then once you get to review it, it’s your other responsibilities because code reviewing is not the sole responsibility.

[00:37:34] So once you get to review it, you approve it, and then you let these developers or the dev pair merge.

[00:37:39] 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.

[00:37:53] By then, you will be elsewhere.

[00:37:55] So the cycle continues.

[00:37:56] So the developers have that back and forth in terms of reviewing, waiting for a review, merging conflicts, again waiting for a review.

[00:38:03] So that keeps on going, right?

[00:38:05] So we need to see how to decentralize it.

[00:38:07] I’m not saying feature brands-based development is bad.

[00:38:09] Or trunk-based is good.

[00:38:10] It’s all trade-offs, right?

[00:38:11] It depends upon the specific project.

[00:38:13] It depends upon the scenario.

[00:38:15] But the essence is, try to see how you can decentralize it.

[00:38:18] Have more people who have the authority to review and approve.

[00:38:22] 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.

[00:38:28] So they are the long-term members.

[00:38:29] And in the process of time, also groom the newer members to become those reviewers or champions, right?

[00:38:36] And don’t just have one person review it and approve it.

[00:38:39] And it can.

[00:38:39] Go ahead.

[00:38:40] No.

[00:38:40] You should at least have two people or another pair of eyes looking at the code before it gets reviewed and approved.

[00:38:46] Another thing that at least we have followed in my teams is to see if we can do it once in an iteration.

[00:38:51] Let us say we have the developers present their code and change it to the team.

[00:38:55] I mean, what they have done in the given iteration.

[00:38:57] Go through the features with everyone.

[00:38:59] What are the changes that were made in a given component or the code base of the specific project?

[00:39:04] That way, the familiarity about the changes increases within the team.

[00:39:07] And everybody has a fair understanding of what.

[00:39:10] Based on the time and interest, they can go ahead and read further and make themselves today.

[00:39:15] So these are my ideas.

[00:39:16] And yeah, I mean, these are my views on code reviews, Henry.

[00:39:20] Henry Suryawirawan Thanks for sharing all these different variations, permutations, right?

[00:39:23] And you are right when you touch on different, first of all, it’s about different version control strategy, right?

[00:39:28] Sometimes you use strong base development.

[00:39:30] The way you review is slightly different than if you do, you know, branching strategies.

[00:39:34] So thank you for sharing all that.

[00:39:36] So other aspects of craftsmanship that I think is really, really important.

[00:39:39] Is that how do you control technical debt?

[00:39:42] So sometimes, you know, when you write software after a few weeks, a few months, right, you accumulate some debt.

[00:39:49] Is there anything from your side to actually advise us how we can manage technical debt?

[00:39:53] The first and foremost thing is to know that you are absorbing technical debt.

[00:39:58] If you don’t know that you are absorbing technical debt, then it’s hard to save, right?

[00:40:03] So technical debt can be classified into code debt, design debt and architectural debt, right?

[00:40:08] Let’s say on the code.

[00:40:09] 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, you write some code, you deliver it, you get it working.

[00:40:24] 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, you can very well try to do that.

[00:40:34] I can, instead of doing it and crafting it, I can very well go out and use that framework feature and get it done.

[00:40:39] So once that is the thing, capturing it is crucial.

[00:40:43] Meaning once you identify that immediately you need to create a backlog item or 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.

[00:40:56] Because again, capturing alone doesn’t take you anywhere as a team, right?

[00:40:59] 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.

[00:41:08] Handling technical debt is important.

[00:41:09] 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.

[00:41:18] So one more example, or probably an analogy that I would like to quote is a woodcutter example, right?

[00:41:25] As a woodcutter, you go and cut your wood, sometimes you have to sharpen your ax.

[00:41:29] You cannot use the same ax to keep on cutting at the same pace, right?

[00:41:32] You need to slow down, sharpen your ax.

[00:41:33] And then that’s part of your profession.

[00:41:35] This is applicable to both technical debt and engineers in terms of learning.

[00:41:39] Whatever.

[00:41:39] On software craftsmanship, whatever on learning, you need to learn.

[00:41:42] This learning is nothing but sharpening your ax and same is applicable to technical debt.

[00:41:46] So you need to repay the technical debt in a timely manner, which lets you and faster.

[00:41:51] Again, there is an excellent book I came across as far as technical debt is concerned.

[00:41:56] I don’t remember the title on top of my head.

[00:41:58] I think it’s refactoring design smells.

[00:42:01] It’s a wonderful book, which actually talks about these aspects of design smells and technical debt and how to repay them.

[00:42:07] And one more thing is from a people standpoint.

[00:42:10] People standpoint, you need to ensure that you convince the folks, the organizational buy-in should be there.

[00:42:14] The leadership should understand the importance of technical debt and repaying it in a timely manner.

[00:42:18] I mean, this includes architectural debt and redesigning stuff as well.

[00:42:21] Let’s say with the particular understanding of a given domain or a sub domain, you designed it in a certain way.

[00:42:26] You architected that in a certain way, but let us say down the lane, you discover that, okay, this is a better way to actually communicate between these two bounded contexts.

[00:42:34] I can probably refactor this design and redesign this and it’s better to get it done.

[00:42:38] 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 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.

[00:42:53] And ultimately, right, people don’t see technical debt.

[00:42:56] I mean, users might not see.

[00:42:58] End user might not worry.

[00:43:00] They might not see, but where they will feel is all about the quality.

[00:43:03] You have a car.

[00:43:04] The car keeps running every day.

[00:43:06] You are not appreciating your car that wow.

[00:43:09] I started you.

[00:43:10] You got started the moment I started.

[00:43:12] Excellent.

[00:43:13] But the lack of that, where it doesn’t start, you feel the pain.

[00:43:17] Same goes with technical debt under the hood.

[00:43:19] Technical debt keeps on building.

[00:43:22] You won’t realize it.

[00:43:23] One fine day, it is like changing the oil for your car engine, right?

[00:43:27] It just ceases to run.

[00:43:29] And then you realize, oh no, I should not have delayed it this much.

[00:43:33] Probably that is the time where it is too late to handle it.

[00:43:36] Right.

[00:43:37] And again, it goes into a cycle.

[00:43:38] The problem.

[00:43:39] There are systems that have so much technical debt.

[00:43:42] You decide to rewrite the system.

[00:43:43] I’ve been through this.

[00:43:45] You decide to rewrite the system.

[00:43:46] When you rewrite the system, possibly you don’t have the original developers

[00:43:50] who wrote the system, no more with you.

[00:43:53] So there is a lack of domain understanding or a lack of knowledge.

[00:43:55] You have a newer team, newer set of folks trying to reverse engineer the old system

[00:43:59] by understanding the behavior and then trying to break it apart and implement it.

[00:44:03] Now, without that understanding, without that level of background, they will start

[00:44:08] designing a system with technical debt from day one or a design that from day one.

[00:44:12] Okay.

[00:44:13] And it never meets because you need to keep repaying the technical debt that is there

[00:44:18] in the existing system because you have users who are using it and you make changes to it.

[00:44:22] And this new system is going to play a catch up game with the old one, which is

[00:44:25] already getting changes.

[00:44:27] It’s very difficult.

[00:44:28] I mean, the essence is pay technical debt as soon as possible, and then

[00:44:32] maintain a backlog, revise the backlog, revisit the backlog and keep reducing the backlog.

[00:44:38] Right.

[00:44:38] It is never going to be zero.

[00:44:40] Let me tell you that you cannot do away with technical debt entirely because people keep

[00:44:44] moving across projects.

[00:44:45] People keep moving across organizations.

[00:44:47] People come and go.

[00:44:48] So when new people come in, there might be an increased technical debt because they are

[00:44:53] understanding of the system.

[00:44:54] They need time to accustom themselves to the system.

[00:44:56] Right.

[00:44:57] But as they learn, they will understand the nuances.

[00:44:59] They will learn the system and they’ll start working.

[00:45:02] So this technical debt that you incur, I’m not saying every new person will bring in a technical debt,

[00:45:06] but there is a possibility, right?

[00:45:08] Okay.

[00:45:08] So once that happens, you try to repay that and ensure that as a team, you support this

[00:45:13] new person so that there is no technical debt.

[00:45:14] That’s a better way to put it.

[00:45:16] Try to see how you can repay the technical debt and stay on top of it.

[00:45:19] Meaning, know that you are absorbing technical debt first of all.

[00:45:23] That is where trade-off analysis and understanding trade-offs is vital.

[00:45:26] That is where understanding design, understanding the architectural styles, awareness of these

[00:45:32] possibilities that you have is important.

[00:45:34] The lower most level you have, probably you have the design patterns.

[00:45:38] You need to have a fair understanding of design patterns, like which one to apply when.

[00:45:41] It is not about knowing the pattern, it’s about applying the pattern, right?

[00:45:44] It’s about knowing what to apply when in a given context.

[00:45:48] So these are some thoughts on technical debt, Henry.

[00:45:51] Henry Suryawirawan Right.

[00:45:52] Thank you for sharing your thoughts about technical debt.

[00:45:54] I think all what you said is really insightful, right?

[00:45:56] So when you mentioned also about rewrites, right?

[00:45:58] Sometimes software engineers, especially the new software engineers, when they deal with legacy code, oh, we need to rewrite this.

[00:46:04] You know, like I think you mentioned that the first day that they do that, right?

[00:46:08] They probably have lost much of the knowledge behind why the code was written that way.

[00:46:12] And they will incur debt in the first place itself, right?

[00:46:15] Unless you can maybe restructure what kind of domain knowledge that was maybe behind all those code, right?

[00:46:20] So I think that’s a very, very key lesson as well.

[00:46:23] So now let’s say, assume, you know, individuals, teams and all that have this kind of high-quality code.

[00:46:28] They are a software craftsman.

[00:46:30] I think the next is about how we can transform the team into a highly performing engineering teams, right?

[00:46:35] I think here you also have some stories.

[00:46:37] Stories that you want to share, right?

[00:46:39] About how you actually transform the team to become a highly performing or software craftsman all around, right?

[00:46:45] So maybe if you can touch on a little bit on this, that will be great.

[00:46:49] Definitely.

[00:46:50] I mean, there’s an existing model you might find online as well, like which actually shows psychological safety and performance and accountability, a graph, right?

[00:46:58] So I’ll probably before jumping into that, I’d like to touch upon psychological safety.

[00:47:03] So one of the key aspects today, at least, is to give equal importance to mental health.

[00:47:07] Compared to, I mean, as important as physical health, because this is going to also impact your physical health in a way.

[00:47:13] 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.

[00:47:25] They can speak without inhibition.

[00:47:26] They can be open about their issues that they are facing on a daily basis because psychological safety forms the foundation of any team, right?

[00:47:33] On top of it, I would recommend transparency, which is.

[00:47:36] Just be transparent.

[00:47:38] One, one 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.

[00:47:47] Be true to yourself and be true to others.

[00:47:49] I mean, tell the truth and the truth comes only with transparency.

[00:47:52] You try to be transparent.

[00:47:53] Let us say you have a personal appointment that is actually coming on your way.

[00:47:58] Be transparent about it.

[00:47:59] Let others understand everybody has a life, right?

[00:48:01] You might be undergoing a tough time.

[00:48:03] You don’t need to take a loudspeaker and tell it to everybody.

[00:48:06] But.

[00:48:06] 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.

[00:48:18] Don’t say that work is a family or something, right?

[00:48:20] I don’t want to use such fancy words.

[00:48:21] Family is family.

[00:48:22] Work is work.

[00:48:23] It’s a professional environment, right?

[00:48:24] Say professional.

[00:48:26] At the same time, people definitely are social beings who need that emotional support to try to see how we can provide the psychologically safe environment with transparency.

[00:48:35] And.

[00:48:35] These are the two foundational layers for you to build trust.

[00:48:39] As you know, trust is going to take time to build within the team.

[00:48:43] 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 time frame.

[00:48:55] So it happened that the team was actually very good.

[00:48:57] I mean, in terms of psychological safety and performance accountability, there were some challenges.

[00:49:01] We tried to fix it as a team.

[00:49:03] So what happens is not specific to that team, right?

[00:49:05] In general, it is split into four zones.

[00:49:07] When there is no psychological safety and low performance and accountability, you are there in the detached zone.

[00:49:12] So the detached 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.

[00:49:20] They don’t understand the dynamics and the politics and the, all the organizational fancy stuff that’s going on, right?

[00:49:25] The next one is actually a anxiety zone.

[00:49:27] Let us say there is no psychological safety, but there is more performance and accountability.

[00:49:31] You have a lot of performance and accountability expectations on the individuals.

[00:49:35] They become anxious.

[00:49:36] How am I going to deliver?

[00:49:38] How am I going to achieve this?

[00:49:39] There is a huge deadline that is moving over on me or the team, right?

[00:49:43] How am I going to solve this as a team?

[00:49:44] That makes them anxious.

[00:49:46] The third zone on the top left is about low performance, accountability, but high psychological safety.

[00:49:51] This is kind of a very comfort safe zone.

[00:49:54] People are laid back.

[00:49:55] Okay.

[00:49:56] Nobody questions.

[00:49:57] There is some legacy system, which is paying our bills.

[00:50:00] It is generating the revenue.

[00:50:01] I have a lot of time for develop software, deliver.

[00:50:04] Same kind of.

[00:50:05] I’m just giving a cooking up an example, right?

[00:50:07] Some kind of a situation like that, that people are very laid back.

[00:50:10] They know they won’t get fired.

[00:50:12] There is no hard motivation or something to actually run and keep yourself up to date with stuff.

[00:50:17] And you just keep doing in a very slow manner, right?

[00:50:21] So that is a comfort zone.

[00:50:22] And finally the learning zone where there’s high performance, high accountability, and also high psychological safety.

[00:50:28] So we want our teams to actually go from these three zones mentioned earlier, which is the detached comfort zone.

[00:50:34] And the anxiety zone into the learning zone.

[00:50:37] So how to take these teams?

[00:50:40] So there are two parts you can see either you take them through the comfort zone or through the anxiety zone.

[00:50:48] So the first one is don’t take the anxiety zone.

[00:50:50] That is don’t increase the performance and accountability without increasing the psychological safety and trust.

[00:50:58] Work on psychological safety, work on trust, try to increase it.

[00:51:01] So when you keep your performance and accountability expectations constant for a moment.

[00:51:04] 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, right?

[00:51:15] Instead of going through the anxious zone, you take them to the comfort zone.

[00:51:18] And once you know, they are there, they have the psychological safety, they have the transparency and trust.

[00:51:23] Then you start increasing your performance and accountability bars.

[00:51:26] When you raise that bar, the team naturally transforms.

[00:51:29] Again, this was done with a set of individuals by working with them.

[00:51:34] And, uh, it’s the.

[00:51:34] Right.

[00:51:35] So we worked as a team to apply these concepts.

[00:51:39] Concepts are new.

[00:51:40] I mean, as I told earlier, knowledge is everywhere.

[00:51:42] Knowledge is borrowed, but the experiences are unique, right?

[00:51:46] So this is one such experience where we got an opportunity to transform a team and it has worked in more than one century in my opinion.

[00:51:53] So connecting with the individuals and improving the psychological safety is the fundamental to building a stronger team.

[00:51:59] Right.

[00:52:00] So I think it’s really insightful for people who are interested to see these quadrants.

[00:52:03] As Rihari just now mentioned.

[00:52:04] right some of you may not be able to follow but i’ll put it in the show notes if you can find a

[00:52:08] link and also i i saw Srihari come up with a mind maps for these kind of things including this how

[00:52:14] to actually go into learning zone how to transform teams right and also in the software architecture

[00:52:19] or software crossmanship you also have another mind maps right maybe tell us a little bit more

[00:52:23] why do you love creating mind maps how does your brain actually work with mind maps maybe a little

[00:52:29] bit intrigue here mind maps as an idea is always about how your brain organizes information so you

[00:52:36] have neurons which are actually three-dimensional in connection and which you retain and remember a

[00:52:42] lot of things so mind maps as a concept or as an approach capturing knowledge just to give you an

[00:52:47] example boeing captured their entire 747 details in a mind map that was 25 feet long so a 25 feet

[00:52:54] long mind map was used by boeing to capture the entire knowledge about 747 so

[00:52:59] the essence of mind map is to capture a lot of information and try to present in a way it can be

[00:53:04] recollected easily that is you have a central concept and then you have other concepts that

[00:53:08] are linked to it and then there is a linking between these sub concepts as well at times so

[00:53:13] it’s like a three-dimensional graph where concepts and things are linked together right so that is

[00:53:18] how i found interest in creating mind maps and i try to create mind maps whenever i have a complex

[00:53:23] concept that i want to share with my team and then present it to them and share it with them and

[00:53:28] it helps

[00:53:29] in multiple ways one is to share knowledge in a very concise manner second it also helps me in

[00:53:34] teaching and learning and third it also helps you reconnect faster i mean if you want to reconnect

[00:53:40] the concept the mind map is something that will help you recollect faster so that is about mind

[00:53:45] maps in short sometimes you also see it in the movie right when you have a detective investigation

[00:53:50] you have all these you know lines uh on the wall right it’s kind of kind of like that as well to

[00:53:55] recollect all the threads threads connecting the photographs and

[00:53:59] that’s correct yeah so about software craftsmanship right i think we have covered about code base a

[00:54:04] little bit of practices right we also touch on about teams right going to learning zone

[00:54:08] the other aspect of good high quality software or product is actually about architecture

[00:54:13] and the domain knowledge that you mentioned right so maybe we can touch on a little bit as well to

[00:54:17] become a good software craftsman or what aspects of architecture and domain knowledge that we have

[00:54:22] to actually adhere to as far as architecture is concerned as you know there are a lot of

[00:54:28] different architectural styles and there are a lot of different architectural styles and there are a

[00:54:29] lot of different architectural styles and there are a lot of different architectural styles and there are

[00:54:29] various different architectural styles that you can utilize from layered to monolith to microservices

[00:54:33] to space-based event-based event-driven and all of this architecture service oriented kind of

[00:54:38] architectural sites out there as such we have as industry we have undergone transformation in terms

[00:54:44] of these architecture in my view if you see this back then we used to have layered architecture as

[00:54:48] conway’s law says the creature will be very team structure and inverse convey managers if this

[00:54:53] is your architecture that you want to achieve then probably you try to structure your teams this way

[00:54:57] right so

[00:54:59] back then we used to have layered architecture we used to have a client server right we take

[00:55:04] web pages we had server-side rendering as such we had server-side rendering which servers used to

[00:55:09] render but in my view right if you take the advent of smartphones again the iphone and ipad in 2010

[00:55:15] 2011 time frame actually changed things from uh even the impact of the development ecosystem in

[00:55:22] my view because back then when server-side rendering was so prominent number and device

[00:55:27] hitting these servers was actually a finite set but with the proliferation of mobile devices the

[00:55:32] number of devices hitting these servers became exorbitant but in this service could not keep up

[00:55:36] with that load and they eventually had to scale right scale horizontally as well as try to offload

[00:55:43] the responsibility of rendering into the client use the client-side power to render right which

[00:55:48] gave a way to the kind of simple page applications and frameworks and all this javascript frameworks

[00:55:54] and stuff right then you also have the mobile apps

[00:55:57] and other things that are communicating with the server so there is more computing power that got

[00:56:00] distributed from a computational perspective so all of these are different events that shaped up

[00:56:08] newer architectural styles so from layered we got into service oriented which resulted in some

[00:56:14] distribution and then from there it became micro service on the server side and then micro front

[00:56:20] ends on the client side now i mean not that every architecture is suitable for every problem right i

[00:56:25] mean first of all you need to have a server-side rendering and then you need to have a server-side

[00:56:26] rendering to understand one thing very clearly no architectural style is superior or inferior

[00:56:31] i i see a lot of debates online where i’ve probably i’ve stepped in and given my suggestions that i

[00:56:38] learned from different authors and different people in the industry by reviewing these books

[00:56:42] and expanding my knowledge not that it’s my personal view i’ve also learned from others

[00:56:46] and also seen an experience both put together architectural style is superior or inferior

[00:56:51] you’d be wondering i mean working in a fancy micro service based project but it might be

[00:56:56] a humble legacy system which will be sitting in the background and funding your project

[00:57:00] but that will be the cash cow from a management perspective which gives you the cash and the

[00:57:04] funding right for their r&d division to invest in micro services and develop a new version of

[00:57:09] your product right so we need to see i mean i have huge respect for this legacy system because

[00:57:14] the developers who wrote it they didn’t have all these fancy things back then not have faster

[00:57:20] machines they did not have a lot of ram they did not have cloud they did not have fancy ids and

[00:57:25] all this stuff but even then they produce something that is not as good as it used to be and they did not have

[00:57:26] anything that’s of great quality right they are are pioneers in terms of software craftsmanship

[00:57:32] those who wrote such systems they need to get their fair share of respect and every time i see

[00:57:40] people complaining about legacy systems but also try to look at the positives of legacy system it

[00:57:44] is giving you the funding that you need today in essence understand the different architectural

[00:57:49] styles try to see how it is going to fit together and no single architectural style might be

[00:57:56] helping you solve a very complex problem let’s say you take a example like amazon part of it might

[00:58:03] be micro services a part of it might be a mobile app a part of it might be a layered stuff it

[00:58:08] depends upon the problem domain and the subdomains that are interacting and working together so these

[00:58:12] architectural sites some part might be event driven right these architectural styles should

[00:58:16] actually work together in tandem to solve the business problem wherein you can even go ahead

[00:58:20] and apply a given architectural shell for a given problem or a boundary context and then solve it

[00:58:26] in the way it interacts with another bounded context so again it boils it’s as a close link

[00:58:31] to domain driven design assets because in my view domain driven design is kind of an eternal concept

[00:58:36] in software time frame because it was written in 2003-2004 by eric evans but i feel there is more

[00:58:44] traction in the last few years or last decade or so where people have started looking back into the

[00:58:51] literature of domain driven design and they are trying to take these concepts like stuff that is

[00:58:56] like accelerates stuff that is there in books like team topologies some there is in every

[00:59:00] micro service book stuff that is there in all the architectural books everything boils down to domain

[00:59:05] driven design the strategic patterns of domain driven design and the tactical patterns of domain

[00:59:08] driven design so an organization for leaders i feel it is important for leaders to read about

[00:59:15] domain driven design especially the strategic part of it because that is going to give you a

[00:59:19] lot of insights on what work remains within the organization where do you put the best people

[00:59:26] in your organization and how do you put the best people in your organization and how do you put

[00:59:26] the best people in your organization or the best minds right i mean we need to have an inclusive

[00:59:29] environment as i mentioned earlier people differ by their own knowledge levels and abilities but

[00:59:37] it is not a matter of learning everybody can learn and work it is just a matter of experience not a

[00:59:41] question about ability it is just a matter of learning and time right so given that people

[00:59:46] will learn and they will definitely get up to speed so if you take an organization where you

[00:59:52] have the best minds or the most experienced folk they should be trying to solve the core problem

[00:59:56] organization the core domain and this knowledge should not be going out of the organization to

[01:00:02] other folks who are like say you have a conducting firm or a subcontracting or an outsourcing firm

[01:00:08] sometimes the problem is complex enough where you need specialized consent from an outsourcing firm

[01:00:12] i’m not saying don’t outsource your core domain but also have some people in your organization

[01:00:17] who pair with these people to solve the complex problem together stuff that is a supporting domain

[01:00:23] which is not a off-the-shelf solution but i need to be able to solve the complex problem together

[01:00:26] that is where you can actually probably give an opportunity to your younger developers or the

[01:00:32] junior developers or people who are new to the organizations you can put these people into these

[01:00:36] areas and they will have to know the application how to develop it and how to move forward with

[01:00:39] the supporting domain and of course for the things that are not going to give you a competitive

[01:00:44] advantage like the generic domain something like authentication authorization don’t reinvent the

[01:00:51] wheel just go ahead and buy something off the shelf say for authorization use octa so

[01:00:56] it depends so all of all of this stuff try to get that perspective so when leaders

[01:01:01] they read about domain driven design and these kind of concepts that we discussed about

[01:01:06] architecture the styles and stuff you need to connect the dots so i’m probably trying to cover

[01:01:11] these as well in my next book so i’ll be writing about these and much more in the coming days

[01:01:18] so i think if we look back the whole episode right we cover a lot of things for all software

[01:01:22] engineers to actually upscale and become a better crossword right we start from the code

[01:01:26] start then for some practices and also transforming the teams into learning zones and things like

[01:01:31] that we also touch on about mind maps a little bit of how you can recollect knowledge and then

[01:01:36] lastly we talk about architectural styles and also understanding domain driven design so all

[01:01:41] these i feel i agree with you that these are all very very important aspects for us to become a

[01:01:46] much better software engineer i want to touch on one more thing which is to take notes i mean

[01:01:52] have a notebook and a pen next to you whenever you read a book

[01:01:56] either you write it in the book itself in the sidebar or underline or mark it or write notes

[01:02:02] definitely i request folks who are learning to take notes visual note taking is a concept that

[01:02:08] you can explore which i am also collecting a lot of visual note taking samples nowadays

[01:02:12] so whenever i find something interesting i just take a quick screenshot or i just save the image

[01:02:16] and i have a library of visual notes now which i can refer back to different styles of visual

[01:02:21] note taking it also like mind maps helps you capture complex concepts and it helps you to

[01:02:26] understand the story telling so my two cents always learn take notes of what you learn

[01:02:32] right thanks for the plug as well so sri hari i think we have covered a lot of things unfortunately

[01:02:38] due to the time we we have to you know leave soon but i have one last question that i would like to

[01:02:43] ask you which is a custom question that i i have to to ask for all my guests i call this three

[01:02:49] technical leadership wisdom so you can think of it just like advice that you want to give to us

[01:02:53] to learn from you so what will be your three technical leadership wisdom

[01:02:56] not every problem is technical in nature many of the time it’s people right so give respect to

[01:03:04] people and treat them with immense respect and everybody should get their share of respect

[01:03:09] irrespective of their background irrespective of anything right so respect your folks who are

[01:03:14] working with you and your team that will go a long way in building a working relationship

[01:03:18] it is not about who is right or who is wrong it’s about the working relationship so

[01:03:21] gracious behavior is one of the key aspects that i would recommend to folks

[01:03:26] i’m also in the process of learning not that i’m perfect so always try to be gracious let the other

[01:03:33] person say a phrase and keep moving that is one thing a second advice that i would uh not an advice

[01:03:39] an input or a wisdom i would like to share is to learn something every day i mean you cannot

[01:03:45] conquer without practice right it might not be a new piece of wisdom but as technical folks or

[01:03:53] technical leads or architects we need to keep

[01:03:56] learning and capture your learning so that you can share and recollect and teach others

[01:04:03] always share what you learn as yoda said so that is one thing and third piece of input would be

[01:04:11] try to bring in variety in your learning i mean don’t learn the same kind of stuff

[01:04:16] let us say you’re learning a programming language in a given paradigm

[01:04:19] say object oriented the next language try to learn in a functional way this gives you

[01:04:26] different set of tools that you can apply for specific problems because it is not the programming

[01:04:32] language that determines a given project that they’re going to work on but it is the problem

[01:04:38] domain that demands a given technology stack right let’s say you want to develop an enterprise app

[01:04:44] you are better off doing it with java or dotnet or something and if you want to do something in

[01:04:48] data engineering you are better off doing it with python let us say you want to do something

[01:04:52] with statistical computing you are better off doing it with r or python and if you go to a

[01:04:56] you probably if you go and use some other tech stack which is not appropriate you’ll burn your

[01:05:00] fingers right so use the right tool for the right problem and the right domain which actually

[01:05:06] helps you become a better person so have that variety in terms of learning and try to apply

[01:05:13] your learning and share your learning i like the last part right so you also need to know the

[01:05:18] variety and the options that you do have right so that you can tackle the problem with the right

[01:05:23] tool so thank you so much for this conversation

[01:05:26] would like to connect and find you online or ask you about questions is there a place where they

[01:05:31] can find you yeah they can find me on top mate as well as linkedin and i’m happy to collaborate with

[01:05:38] folks and try to provide any help that i can all right thank you so much again for your time i hope

[01:05:44] everyone who listens to this episode can become a better software craftsman and thank you for

[01:05:48] your opportunity henry and i’m also learning in the process it was a great conversation and

[01:05:53] thank you for investing your time and having this conversation

[01:05:56] thank you for listening to this episode and for staying right until the end if you highly enjoyed

[01:06:04] it i would appreciate if you share it with your friends and colleagues who you think would also

[01:06:08] benefit from listening to this episode and if you’re new to the podcast make sure to subscribe

[01:06:13] and leave me your valuable review and feedback it helps me a lot in order to grow this podcast

[01:06:19] better you can also find the full show notes of this conversation on the episode page at

[01:06:24] techleadjournal.dev website including the full show notes of this conversation on the episode page at

[01:06:26] techleadjournal.dev full transcript interesting quotes and links to the resources mentioned from

[01:06:31] the conversation and lastly make sure to subscribe to the show’s mailing list on techleadjournal.dev

[01:06:37] to get notified for any future episodes stay tuned for the next techleadjournal episode

[01:06:42] and until then goodbye

Visão de gráfico