praneethr86.github.io/index.xml at gh-pages · praneethr86/praneethr86.github.io · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Praneeth Patakota</title>
    <link>https://praneethr86.github.io/</link>
    <description>Praneeth Patakota</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 21 Aug 2023 00:00:00 +0000</lastBuildDate>

    <atom:link href="https://praneethr86.github.io/index.xml" rel="self" type="application/rss+xml" />


    <item>
      <title>The Documentation Conundrum</title>
      <link>https://praneethr86.github.io/post/the-documentation-conundrum/</link>
      <pubDate>Mon, 21 Aug 2023 00:00:00 +0000</pubDate>

      <guid>https://praneethr86.github.io/post/the-documentation-conundrum/</guid>
      <description>&lt;h1 id=&#34;the-documentation-conundrum&#34; &gt;The Documentation Conundrum
&lt;span&gt;
    &lt;a href=&#34;#the-documentation-conundrum&#34;&gt;
        &lt;svg viewBox=&#34;0 0 28 23&#34; height=&#34;100%&#34; width=&#34;19&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34;&gt;&lt;path d=&#34;M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;path d=&#34;M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;/svg&gt;
    &lt;/a&gt;
&lt;/span&gt;
&lt;/h1&gt;&lt;p&gt;Any typical code base, given enough years, becomes large enough to find it difficult to maintain documentation for. Every new piece of code I saw in my career had one of the below 3 issues with regards to documentation :&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;No Documentation&lt;/li&gt;
&lt;li&gt;Incomplete Documentation or&lt;/li&gt;
&lt;li&gt;Outdated Documentation&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;So I started on a quest to find out what&amp;rsquo;s the best way to document your application and the internal implementation, and I shall try to summarise my findings to the best of my knowledge.&lt;/p&gt;
&lt;h2 id=&#34;tests-are-the-best-form-of-documentation&#34; &gt;Tests are the best form of Documentation
&lt;span&gt;
    &lt;a href=&#34;#tests-are-the-best-form-of-documentation&#34;&gt;
        &lt;svg viewBox=&#34;0 0 28 23&#34; height=&#34;100%&#34; width=&#34;19&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34;&gt;&lt;path d=&#34;M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;path d=&#34;M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;/svg&gt;
    &lt;/a&gt;
&lt;/span&gt;
&lt;/h2&gt;&lt;p&gt;One wise programmer once told that you won&amp;rsquo;t need any documentation if your tests are perfect. Well, he was right. But for that to happen you need to follow TDD (Test Driven Development) - where you first write a test, then fail it, then write code to pass that test - and iterate until your implementation is ready.&lt;/p&gt;
&lt;p&gt;Whoever does TDD well, has the perfect little suite of tests sitting right inside their code base, telling a clear story which no other document can explain.&lt;/p&gt;
&lt;h2 id=&#34;coding-conventions-make-life-easier-for-everyone&#34; &gt;Coding Conventions make life easier for everyone
&lt;span&gt;
    &lt;a href=&#34;#coding-conventions-make-life-easier-for-everyone&#34;&gt;
        &lt;svg viewBox=&#34;0 0 28 23&#34; height=&#34;100%&#34; width=&#34;19&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34;&gt;&lt;path d=&#34;M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;path d=&#34;M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;/svg&gt;
    &lt;/a&gt;
&lt;/span&gt;
&lt;/h2&gt;&lt;p&gt;I don&amp;rsquo;t need to stress much on this subject, as it&amp;rsquo;s a familiar topic to you all. Naming Conventions, Comments, Class/Method descriptions and many more rules that we set for ourselves, if followed, also ensure we can have great documentation.&lt;/p&gt;
&lt;p&gt;In fact you can use libraries/frameworks like java-docs, Sphinx etc to generate docs directly from code.&lt;/p&gt;
&lt;h2 id=&#34;wiki-pages-are-outdated-unless-you-enforce&#34; &gt;Wiki pages are outdated unless you enforce
&lt;span&gt;
    &lt;a href=&#34;#wiki-pages-are-outdated-unless-you-enforce&#34;&gt;
        &lt;svg viewBox=&#34;0 0 28 23&#34; height=&#34;100%&#34; width=&#34;19&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34;&gt;&lt;path d=&#34;M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;path d=&#34;M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;/svg&gt;
    &lt;/a&gt;
&lt;/span&gt;
&lt;/h2&gt;&lt;p&gt;Domain documentation is a tough problem to solve, and there is a good chance that whatever path we take, it eventually grows outdated as it can&amp;rsquo;t keep up with the changes being pushed in by the team. Wiki pages make sense at a HLD/LLD level, and to keep them updated as design gets updated during development, but beyond that, using it as a repository of all documentation possible - is not a smart solution in my opinion.&lt;/p&gt;
&lt;h2 id=&#34;please-use-readme-md-and-api-docs-well&#34; &gt;Please use README .md and API Docs well
&lt;span&gt;
    &lt;a href=&#34;#please-use-readme-md-and-api-docs-well&#34;&gt;
        &lt;svg viewBox=&#34;0 0 28 23&#34; height=&#34;100%&#34; width=&#34;19&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34;&gt;&lt;path d=&#34;M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;path d=&#34;M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;/svg&gt;
    &lt;/a&gt;
&lt;/span&gt;
&lt;/h2&gt;&lt;p&gt;The best documentation is not something that sits outside your repo (like a wiki/confluence) but something that can be found right when the developers open up the repository or clone it.&lt;/p&gt;
&lt;p&gt;What better place than to use the markdown documentation to ensure at least application level docs are updated there on a regular basis.&lt;/p&gt;
&lt;h2 id=&#34;versioning-change-log-matters&#34; &gt;Versioning (Change Log) matters
&lt;span&gt;
    &lt;a href=&#34;#versioning-change-log-matters&#34;&gt;
        &lt;svg viewBox=&#34;0 0 28 23&#34; height=&#34;100%&#34; width=&#34;19&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34;&gt;&lt;path d=&#34;M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;path d=&#34;M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;/svg&gt;
    &lt;/a&gt;
&lt;/span&gt;
&lt;/h2&gt;&lt;p&gt;This is something I saw being followed very well in open-source repositories and it&amp;rsquo;s clearly a useful history of the changes that went in. It wouldn&amp;rsquo;t classify as official docs any day, but it&amp;rsquo;s a really useful addendum to the documentation if you ever want to figure out recent changes that went into application code.&lt;/p&gt;
&lt;h2 id=&#34;docs-as-websites&#34; &gt;Docs as websites
&lt;span&gt;
    &lt;a href=&#34;#docs-as-websites&#34;&gt;
        &lt;svg viewBox=&#34;0 0 28 23&#34; height=&#34;100%&#34; width=&#34;19&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34;&gt;&lt;path d=&#34;M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;path d=&#34;M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;/svg&gt;
    &lt;/a&gt;
&lt;/span&gt;
&lt;/h2&gt;&lt;p&gt;Docusaurus, Gatsby and other static side generators work really well. I am still experimenting with them, but my take is that they are good for external facing documentation, Public APIs etc. but for internal documentation, it might get really tough to ask the team to keep the docs updated along with the rapid pace of changes flowing in every day.&lt;/p&gt;
&lt;p&gt;There is clearly no silver bullet to fix the documentation conundrum, but a situational approach to decide where to host the documentation for an application, tech stack, domain, or a simple change - can make life much easier for future generations of developers who will probably applaud you for doing a good job at maintaining docs.
If you have any better suggestions, please leave a comment or respond to me via email.&lt;/p&gt;
</description>
    </item>

    <item>
      <title>The Art of Holding Back</title>
      <link>https://praneethr86.github.io/post/the-art-of-holding-back/</link>
      <pubDate>Mon, 14 Aug 2023 00:00:00 +0000</pubDate>

      <guid>https://praneethr86.github.io/post/the-art-of-holding-back/</guid>
      <description>&lt;p&gt;This is the first in a series of mini thought-bytes from my experiences.&lt;/p&gt;
&lt;p&gt;There will be a lot of times when your actions will be misinterpreted or your words will be misconstrued in unimaginable ways. It&amp;rsquo;s bound to happen more than once in your career, so what can you do about it ?&lt;/p&gt;
&lt;p&gt;The first step is to have an open conversation with whoever raised the concern, and listen, not talk. That itself will make it clear that you have taken the right approach. If you don&amp;rsquo;t listen and react emotionally, it just puts you in the vulnerable position of having to apologize for reacting.&lt;/p&gt;
&lt;p&gt;It&amp;rsquo;s always wiser, and there are no exceptions, to be the silent person in the conversation. No matter what the situation, it can be diffused only when one side is silent and listens. The others have no option but to step back and have a thought as well.&lt;/p&gt;
&lt;p&gt;The courage to hold back &amp;amp; listen, when all your senses are saying you should react, is a skill to be developed. Most take a life time and never get there. Some try and try and eventually do get there. Which one do you want to be ?&lt;/p&gt;
</description>
    </item>

    <item>
      <title>Tech Leadership</title>
      <link>https://praneethr86.github.io/post/tech-leadership/</link>
      <pubDate>Tue, 08 Aug 2023 00:32:27 +0530</pubDate>

      <guid>https://praneethr86.github.io/post/tech-leadership/</guid>
      <description>&lt;h1 id=&#34;notes-on-technical-leadership-and-problem-solving&#34; &gt;Notes on Technical Leadership and Problem Solving
&lt;span&gt;
    &lt;a href=&#34;#notes-on-technical-leadership-and-problem-solving&#34;&gt;
        &lt;svg viewBox=&#34;0 0 28 23&#34; height=&#34;100%&#34; width=&#34;19&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34;&gt;&lt;path d=&#34;M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;path d=&#34;M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;/svg&gt;
    &lt;/a&gt;
&lt;/span&gt;
&lt;/h1&gt;&lt;p&gt;Recently I had a deep dive conversation into what the role of a technical leader should be and wanted to share a few points here.&lt;/p&gt;
&lt;p&gt;There are lot of aspects to consider here&lt;/p&gt;
&lt;h2 id=&#34;setting-platform-roadmap-and-vision&#34; &gt;Setting Platform roadmap and vision
&lt;span&gt;
    &lt;a href=&#34;#setting-platform-roadmap-and-vision&#34;&gt;
        &lt;svg viewBox=&#34;0 0 28 23&#34; height=&#34;100%&#34; width=&#34;19&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34;&gt;&lt;path d=&#34;M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;path d=&#34;M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;/svg&gt;
    &lt;/a&gt;
&lt;/span&gt;
&lt;/h2&gt;&lt;p&gt;Before we can set a roadmap and a vision for where the platform should be heading, it&amp;rsquo;s important to first understand it in-depth. Once you have that level of detailed knowledge about the current system, changes and roadmap can be proposed with a level of certainty in mind.&lt;/p&gt;
&lt;p&gt;A technology leader&amp;rsquo;s main goal is to have a constant radar scanning for opportunities and gaps in the system, and propose better alternatives, refactoring, rewrites or even rebuilding the architecture.&lt;/p&gt;
&lt;p&gt;Vision is about how all this is going to pan out in the next 5-10 years. If you can get that right, you are the best leader your team can hope for.&lt;/p&gt;
&lt;h2 id=&#34;encouraging-enforcing-best-practices&#34; &gt;Encouraging (enforcing) best practices
&lt;span&gt;
    &lt;a href=&#34;#encouraging-enforcing-best-practices&#34;&gt;
        &lt;svg viewBox=&#34;0 0 28 23&#34; height=&#34;100%&#34; width=&#34;19&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34;&gt;&lt;path d=&#34;M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;path d=&#34;M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;/svg&gt;
    &lt;/a&gt;
&lt;/span&gt;
&lt;/h2&gt;&lt;p&gt;Over time, these three things grow beyond a certain level of control - workforce, codebase and business expansion.
All these pose unique challenges, but a common one they all throw at leaders, is the problem if best practices and how to ensure they aren&amp;rsquo;t left out on a daily basis.&lt;/p&gt;
&lt;p&gt;If quality, integrity and cost of ownership is taken into consideration, making sure best practices are followed/introduced/revisited etc, is of paramount importance to ensure the health of both your tech stack and your organization. The benefits of this are incomparable if you start listing them down in detail.&lt;/p&gt;
&lt;h2 id=&#34;technical-debt&#34; &gt;Technical Debt
&lt;span&gt;
    &lt;a href=&#34;#technical-debt&#34;&gt;
        &lt;svg viewBox=&#34;0 0 28 23&#34; height=&#34;100%&#34; width=&#34;19&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34;&gt;&lt;path d=&#34;M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;path d=&#34;M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;/svg&gt;
    &lt;/a&gt;
&lt;/span&gt;
&lt;/h2&gt;&lt;p&gt;As your code base grows, debt always inevitably piles up, as we make compromises due to urgency of business, lack of stringent reviews for changes and the speed at which we want to deliver in the market today.&lt;/p&gt;
&lt;p&gt;The leaders&amp;rsquo; role here is to ensure that debt is not forgotten and take ownership of ensuring it is cleared on a regular basis as part of upcoming changes. There are multiple approaches to this, but I prefer doing it incrementally along with upcoming changes, rather than a big bang hackathon to clear technical debt - that wont bring about any systemic changes for long term.&lt;/p&gt;
&lt;h2 id=&#34;innovation&#34; &gt;Innovation
&lt;span&gt;
    &lt;a href=&#34;#innovation&#34;&gt;
        &lt;svg viewBox=&#34;0 0 28 23&#34; height=&#34;100%&#34; width=&#34;19&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34;&gt;&lt;path d=&#34;M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;path d=&#34;M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;/svg&gt;
    &lt;/a&gt;
&lt;/span&gt;
&lt;/h2&gt;&lt;p&gt;Pushing team and oneself towards technical excellence involves keeping an eye out for all opportunities for innovation. Using all avenues possible to push for minor to major innovations helps the leader and their team build their own career paths while also helping their company on their innovation path. It&amp;rsquo;s a true win-win.&lt;/p&gt;
&lt;h2 id=&#34;being-visible-and-hands-on&#34; &gt;Being visible and hands-on
&lt;span&gt;
    &lt;a href=&#34;#being-visible-and-hands-on&#34;&gt;
        &lt;svg viewBox=&#34;0 0 28 23&#34; height=&#34;100%&#34; width=&#34;19&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34;&gt;&lt;path d=&#34;M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;path d=&#34;M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;/svg&gt;
    &lt;/a&gt;
&lt;/span&gt;
&lt;/h2&gt;&lt;p&gt;The last but probably the most important item in my opinion, is to be a visible and hands-on leader. A leader has to spend long hours to truly understand about their people, their product, and always be connected to the ground level operations. Losing touch with what your team works on on a daily basis, is like shutting off the gates to learning and development for themselves and the team.&lt;/p&gt;
&lt;p&gt;Failing to be hands-on and being available and visible to team and stakeholders, opens up a huge can of worms - lack of trust and respect, lack of knowledge, unable to review team performance and unable to establish an overall growth trajectory for the team. The list goes on.&lt;/p&gt;
&lt;h2 id=&#34;conclusion&#34; &gt;Conclusion
&lt;span&gt;
    &lt;a href=&#34;#conclusion&#34;&gt;
        &lt;svg viewBox=&#34;0 0 28 23&#34; height=&#34;100%&#34; width=&#34;19&#34; xmlns=&#34;http://www.w3.org/2000/svg&#34;&gt;&lt;path d=&#34;M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;path d=&#34;M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71&#34; fill=&#34;none&#34; stroke-linecap=&#34;round&#34; stroke-miterlimit=&#34;10&#34; stroke-width=&#34;2&#34;/&gt;&lt;/svg&gt;
    &lt;/a&gt;
&lt;/span&gt;
&lt;/h2&gt;&lt;p&gt;This is not a complete list, but these are thoughts which got triggered due to a conversation I had and helped me atleast organize these most important categories and start working on them for myself and also for leaders inside my team.&lt;/p&gt;
</description>
    </item>

  </channel>
</rss>