atom.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

  <title><![CDATA[Avi Das]]></title>
  <link href="http://avidas.github.com/atom.xml" rel="self"/>
  <link href="http://avidas.github.com/"/>
  <updated>2022-08-28T18:22:59-04:00</updated>
  <id>http://avidas.github.com/</id>
  <author>
    <name><![CDATA[Avi (Ananya Das)]]></name>
    
  </author>
  <generator uri="http://octopress.org/">Octopress</generator>

  
  <entry>
    <title type="html"><![CDATA[Reflections on WeWork: Relentless Change and Unrealized Potential]]></title>
    <link href="http://avidas.github.com/blog/2022/08/14/reflections-on-wework-relentless-change-and-unrealized-potential/"/>
    <updated>2022-08-14T17:17:00-04:00</updated>
    <id>http://avidas.github.com/blog/2022/08/14/reflections-on-wework-relentless-change-and-unrealized-potential</id>
    <content type="html"><![CDATA[<p>I spent three years as a software engineer at WeWork. Three years is north of 6,000 working hours and this post is an account of my time there and key takeaways. If you are interested in what the experience of working in a hyper growth company feels like, this account may interest you.</p>

<p><strong>Getting There</strong></p>

<p>Working for WeWork is difficult to summarize in a single sentence, or even a paragraph. A fervent energy permeated the whole company, driven by the charismatic CEO Adam Neumann. There has been a lot that has already been written about WeWork, but every viewpoint provides something new. Mine is that of a software engineer in WeWork’s tech org, shipping software during the ups and downs as WeWork attempted to blitzscale the world&#8217;s fastest growing real estate business.</p>

<p>Having joined WeWork from Braintree, I had more experience with established companies with proven business models, operating at the scale of web commerce. The relative stability and nature of industry meant that an engineer&#8217;s contributions would be making small and incremental progress with few opportunities to build something from the ground up. I was recruited by a longtime friend who was a director of engineering at WeWork. It felt like a good opportunity to experience engineering in a hyper-growth company.</p>

<p>I remember my onboarding day, easily the most boisterous one of my career. The host had an insatiable level of energy and it was fascinating to see people working in a whole host of disciplines, legal, architecture, design, real estate, tax all brought together in one room. At the end of the day, Miguel, one of the co-founders, came and spoke about how WeWork started. Having seen tech culture in past companies, there was already the sense that this company would be different from anything I had seen before.</p>

<p><strong>Trial By Billing</strong></p>

<p>The first team I joined was building billing in house at Wework, and it was a challenging experience for my first six months of tenure. We were working in a monolith with poorly defined domain boundaries. During its growth phase, WeWork optimized for flexibility offered to members in terms of lease agreements, discounts, and payment methods. However, the infrastructure felt the weight of this product growth, making ongoing development a challenge. The team had doubled in size in a very short time, resulting in a high proportion of engineers new to the company.
Everyone I worked with was smart and genuine, and there was great camaraderie across the team. It felt far more familial than I&#8217;ve ever encountered before in my career.</p>

<p><em>Wework tech org managed to hire a group of genuinely good, talented people. This cannot be taken for granted at any company.</em></p>

<p>My job was to tug away the billing codebase from the rest of the monolith. This was an exercise that was doomed to failure, not least due to an arbitrary deadline that was laid down on us. We toiled hard, made a valiant attempt at taming the Spaghetti monster codebase responsible for processing hundreds of millions in recurring revenue.</p>

<p>By January, leadership saw things differently, and decided to take the work from our humble four person team to the Tel Aviv office and dedicate an entire new department towards solving WeWork&#8217;s billing conundrum. That department would eventually grow to over a hundred people, engaged in a multi year effort to architect billing at WeWork.</p>

<p><em>Your view of the work you and your team is doing may be wildly different from how the key stakeholders see the work.</em> Leadership changed their priority often during WeWork, making it a constant guessing game when the product direction would change or a re-org would happen. For a company of WeWork&#8217;s valuation, the rate of change was that of a small startup struggling for identity. This caused stress for those engineers who wanted to focus and specialize in a product area for a long period.</p>

<!-- more -->


<p><strong>WeLive</strong></p>

<p>As I sought out opportunities within the company, I learnt of a new effort at WeLive, the residential arm of WeWork. WeLive felt like an opportunity to build a product from the ground up, stay close to users, work with a nimble team and be a startup with large company resources. Sounds too good to be true?</p>

<p>It was. It was really great for a while to have zero red tape and build what users wanted. We worked on a product which had a real consumer need and potentially a massive market, but ultimately the environment was not a fit for what we were building. As WeLive failed to expand at the rate of WeWork, business drying up meant that it was no longer possible to budget a technology team and incur millions in operating expenses.</p>

<p>At the same time, top level leadership became completely invested in a new redesign of the WeWork app. This meant our team was rolled over into that org, into a team that would provide core services for the WeWork member app.</p>

<p>We would lose the autonomy and purpose which drove us during WeLive. However, we would now build infrastructure to support all teams building products for half a million WeWork members.</p>

<p><strong>Platform</strong></p>

<p>The core team, with primarily senior/staff engineers, was a very competent team. We lacked a clear mission or agenda though and became the fail safe of everything that would fall through the cracks of the product teams. Secondly, the team members began proving themselves to be too competent, so we started losing team members to higher priority product initiatives. There was a period of a couple weeks when we lost all three of our mobile engineers. In the midst of all this, we managed to launch a service to offer feature gating and experimentation in the WeWork app. We changed the way every single feature in the WeWork app got launched, and began accepting consumers beyond the app.</p>

<p>However, the steady loss of key members was a sign and by December 2018, it was clear that we were in the shadows where the product teams delivering the app redesign were in the limelight. A re-org would soon follow, and we would become another product team contributing to the WeWork member app.</p>

<p>The next step in my journey was being involved in the re-architecture of WeWork’s internal social experience used by its hundreds of thousands of members and community managers. The existing app was built in Angular 1.5, and was a maintenance headache. The groundwork would be laid for a modern app using React, while building up a component library which could be plugged in to create key experiences for members. After working primarily in backend development at WeWork, I was keen to do more frontend work, and took on the challenge to work amidst a group of capable frontend engineers.</p>

<p>The next few months were quite enjoyable. All of us believed in the work, and this resulted in a lot of momentum and collaboration in the team. There was a lot of emphasis on laying the right foundations, and the team was very engineering-driven. Perhaps too much so though, and design and product were not as invested in the project as engineering was. A lack of centralized focus towards delivery, coupled with changing designers meant a lot of work had to be redone. Changing priorities meant the project was resource constrained, and the full rollout of the app would get delayed by a year.</p>

<p><em>Rewrites are expensive. Weighing in failure scenarios can help derisk this.</em></p>

<p><strong>Intents</strong></p>

<p>Around this time, my manager has been discussing with me the possibility of promotion. Since I was in a new team, under a new management structure and using a new software stack, my relative contribution made the case harder to make. The advice was to seek out opportunities where I could have a higher relative impact and drive bigger results to make a stronger case.</p>

<p><em>Your relative impact in a team matters, as one becomes more senior, staying fullstack/generalist is challenging. Specialization can be a faster path to level up.</em></p>

<p>My opportunity came in the form of a curious word: Intents. The product leader for Member Apps had the vision of taking our member facing feed from plaintext to a variety of structured posts, evolving towards a marketplace. From one type of posts, we would go to a multitude of posts on the feed, and the grouping was called Intents. It made a lot of sense for WeWork to have, and needed experienced backend contributors to architect the level of flexibility and dynamism required.</p>

<p>What followed was a tragic case of misaligned expectations and poor timing. We were staffed generously, with solid talent and the rest of the org shielding the team from adjacent work streams.</p>

<p>Product wanted a flexible way to experiment with a large number of posts types without needing to ship a build to the app store. This key requirement meant that frontend, backend and design got involved in a month-long debate on how to execute this, since we lacked a design system and component library. We also lacked expertise in the company on how to build such a system. We eventually adapted the server driven ui paradigm. Lot of draining days fine tuning the architecture meant that we learnt a lot about division of responsibilities, managing state and the best UX for users.</p>

<p>However, the timeline engineering came up with was mysteriously cut short by exactly a month. So we hurried back to the drawing board, cut some key aspects to refit the project and came up with a compromise. Upon agreement, we were off to the races.</p>

<p>After a strenuous and heads down period, we delivered the project, two weeks over time, but something we were proud to ship and began to roll out the feature to users in September. Initial engagement of the new posts were 3-5x regular posts, which made our effort a success. However, it did not sufficiently impact the overall strategic move to increase engagement holistically in the WeWork app.</p>

<p><em>Near term momentum for a project or team does not necessarily ensure its success and sustainability.</em></p>

<p><strong>IPO &amp; Layoffs</strong></p>

<p>In September, everything changed as WeWork went to file for an IPO. Everything else became a side show as in a period of weeks we went from a unicorn to a laughing stock on the street. The change in mood in the company was palpable and dramatic, and within days the unthinkable happened with Adam Neumann leaving the company. New leadership from Softbank came in and layoffs were in the picture. All these meant that Intents would be on their way out as the WeWork app would pivot to a utility first app.</p>

<p>Layoffs happened late November, right before the holidays. Surprisingly, engineering was mostly unaffected. December and January were months of struggle, barely enjoying the holidays as I worked to sharpen up for interviews.</p>

<p>Multiple posts can be written about interviewing and negotiations. The biggest piece of advice is to test the market regularly, use inner channels and never immediately rage quit. Long story short, by March I had my job search wrapped up and could breathe again and contemplate when to leave.</p>

<p>However, there was one more story still left for my journey at WeWork. After a big reorg, I had shifted over to the messaging team. Despite our failure with Intents, our engineering effort was lauded and I got promoted.</p>

<p><strong>One Last Dance</strong></p>

<p>In March, two things happened. One, in an aggressive plan to cut costs, WeWork decided to migrate all applications from Heroku to an in-house Kubernetes based hosting solution. This meant a swat team would form, responsible for shifting over a dozen apps and databases. Not one to pass up a sharp learning curve, I joined the team. My last act at WeWork would be working on devOps after being a product engineer during the entirety. Two, the Covid19 pandemic would sweep across the globe and cause everyone to shelter in place in NYC.</p>

<p>The next few weeks were whirlwind, as we dug into a lot of legacy infrastructure, taking stock of compute and storage resources, dockerizing apps and getting them ready for migration, all the while familiarizing ourselves with a whole host of new Kubernetes tools. After putting in long hours for a few weeks, we pulled it off and migrated all the applications by April. Despite the intensity of the effort, I learnt a lot and enjoyed work after a while. Performance and reliability is more in the realms of science than engineering, and a stark contrast to product work. I would often go to sleep still thinking about performance tuning.</p>

<p>My time at WeWork was great at times but overall, it was the story of unrealized promise and potential. On one hand, the diversity of problems and the great coworkers made for a dynamic and rewarding journey. However, it was frustrating to feel that in aggregate, it could have been so much more. I hope this account will help someone looking to join a rocketship, driven by leaders with Messiah complexes.</p>

<p><strong>Postscript</strong></p>

<p><strong>Growth</strong>: The growth trajectory of the WeWork tech org was astronomical. During my time, it would grow 6x over two years and eventually shrink down to one third its size over the period of a few months.</p>

<p><em>Engineers would benefit by taking stock of how their organization is growing vs what is being delivered. A sustained mismatch means a correction is due.</em>
<em>There are many incentives that can drive growth in an organization, and it&#8217;s worth thinking about if you align with those incentives.</em></p>

<p><strong>Extracurriculars</strong>: This writeup has been primarily about work, but extracurriculars were a big part of the WeWork experience. Perhaps the most grandiose of those were two yearly events, Summer Camp and Summit. Both events had the entirety of WeWork employees experience product demos, mission pitches and celebrity appearances. Despite its reputation, I really enjoyed my two times at the UK version of summer camp. It felt mind boggling how a company could afford it, but it was a fun choose your own adventure weekend in the idyllic English countryside.
Startups are created in the image of the founders, or the founding team. Think whether you would align with the founding team, because that is the culture that will seep in across the company.</p>

<p><strong>#personal-finance</strong>: My second week at WeWork, I started a slack channel to discuss personal finance. Over three years, that channel grew to over three thousand people helping each other on their personal finance goals. It was also a great case study of watching a community grow, from early adopters, to hitting critical mass, and then gathering enough momentum where it would influence company wide initiatives, such as instituting a 401k and eventually 401k matching at WeWork. It was one the most gratifying things during my time there.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Finding the right team at a new company]]></title>
    <link href="http://avidas.github.com/blog/2020/06/22/finding-the-right-team-at-a-new-company/"/>
    <updated>2020-06-22T09:48:00-04:00</updated>
    <id>http://avidas.github.com/blog/2020/06/22/finding-the-right-team-at-a-new-company</id>
    <content type="html"><![CDATA[<p>The larger a company is, the more choices there can be for teams to join. In a small company, you could meet your teammates during the hiring process. However, in large companies hiring for generalist software engineers, you may not get the feel for the team before you join. The team matching process has a large variance across the industry, from companies interviewing for a specific role in a team to joining an org within a company to joining potentially any team with an open role across the whole company.</p>

<p>Being able to talk to manager and team members before joining the company is great. However, if that choice is not present, it is important to understand that internal transfers are commonplace in most companies. The inertia of staying in a team which is not the right fit is suboptimal when there are many opportunities internal and external.</p>

<!-- more -->


<p><strong>Play to your strength and excitement</strong></p>

<p>Specialization in particular technical stack or a preference for a specific problem space are both useful. Let&#8217;s just assume certain things. Let&#8217;s assume that in a job, when we are there working, we do want to give it 100%. We have a limited amount of time and want to feel a sense of autonomy, mastery and purpose. The biggest leaps of my career came when I was so engrossed in my work that it stopped feeling like work. Being interested in your end result are also very important. If you really want to be close to the end users, you may not do as well in a systems team far removed from users.</p>

<p><strong>Align with business needs</strong></p>

<p>Think a bit higher level, new projects can be exciting. But is this new project congruent with the company&#8217;s vision? What would take it to fund a project? Sustaining a team of engineers, PMs, support and others is a multi million dollars per year venture. Does the output that the team produce justify that venture? Challenge your EM and PM to understand this. Ideally, you want the value your team produce to far outweigh the costs. This makes it a sustainable beyond quarters, and halves and gives the opportunity to contribute at higher and higher levels. Finding the intersection between the company&#8217;s pressing needs and your skills and interests is key to finding the right fit.</p>

<p><strong>Team dynamics</strong></p>

<p>Joining a team can be like joining a new family. You have to see them almost everyday, work together, trust each other, help and push the common goal while everyone having individual career plans. The dynamics of the team will have a big impact your quality of life.</p>

<p>When do people begin work and what time do they leave work. Check if aligns with your view of life work balance. If you want the team to engage outside of work, you may be disappointed if everyone in the team takes it as a job and do not socialize outside.</p>

<p>How a team handles disagreements and conflict is key to how well a team works together. A subset of members of the team should be able to reach decisions without always relying on the EM, PM, or more senior.</p>

<p>The distribution of seniority across the team will have impact on your goals. If you are early in your career, you want some more senior members in the team for support. If you want to mentor engineers, you do not want a situation where everyone else is at least as senior as you.</p>

<p>Besides levelling, it&#8217;s useful to find out when there have been promotions in the team. This is an indicator of how the organization views the place of the team and that there is a track record of people growing in their roles.</p>

<h3>Team Responsibilities</h3>

<ul>
<li>What are quarterly vs yearly goals for the team? What are the challenges to achieving those goals?</li>
<li>What has the team working on for the last 6 to 12 months? Has the team been meeting it&#8217;s goals?</li>
<li>What are the key challenges the team faces?</li>
<li>Are there any low hanging fruit? Is there work that noone wants to touch?</li>
<li>What does on-call responsibiliteis look like for the time? Are their runbooks for common outages? Are there post mortems for most recent outages?</li>
<li>How does a feature go from idea to general availability? How does the team iterate on a shipped feature?</li>
<li>What percentage of the team&#8217;s work is new projects vs maintenance work vs paying back tech debt?</li>
<li>How much flexibility is there to get involved in different streams of work, in terms of technology and projects?</li>
</ul>


<h3>Team positioning in broader org</h3>

<ul>
<li>How long has the team been around, and what is the expected longevity of the team?</li>
<li>Explain the distribution of responsibilites between this team and the broder org, including but not limited to the upstream and downstream teams.</li>
<li>Does the work the team is doing align with the priorties that the company has? Otherwise, how does leadership perceive the work the team is engaged in?</li>
<li>Are their architecture diagrams that shows the systems the team owns and their dependencies?</li>
</ul>


<h3>Team Culture</h3>

<ul>
<li>Is the team adequately staffed to meet it&#8217;s goals? If not, what is the hiring strategy?</li>
<li>How is the team distribution by seniority and tenure at the company?</li>
<li>Does the team support remote work?</li>
<li>What hours and time zones does the team operate in?</li>
<li>Does the team have an onboarding process? What are aspects of onboarding to this team that new hires usually struggle with?</li>
<li>How does the team communicate? Is there an expectation to be always available for syncronous communication (e.g. meetings/chat)?</li>
<li>Does the team engage in social activites outside of work?</li>
<li>When was the last time someone left the team? Could more context be shared?</li>
</ul>


<h3>Career Goals</h3>

<ul>
<li>Ooh find examples for company cultures (tie in opinion with some research)  e.g. Basecamp primarily does all communication async</li>
<li>What’s your style of management

<ul>
<li>How long you have been a manager</li>
</ul>
</li>
<li>Can the manager articulate a vision for where the team&#8217;s product is going, and how that strategically fits into the company/org&#8217;s larger goals?</li>
</ul>


<p>team evolution (last 6 months 12 months, when people joined and left, how long team around, how has it changed over past and how might it change)</p>

<p>your own career goals
  - User impact of team, how to have high impact
  * Are their opportunities to get mentored and/or mentor others in the team? Are there other opportunities to grow in the people and communication axes?</p>

<pre><code>  - How explicitly does the manager think about career advancement for his or her reports?
</code></pre>

<ul>
<li>How do they foresee you fitting in? What kind of seniority? leadership opportunities? of course, managers can and do lie in these, but i&#8217;ve found that just sensing how prepared they are is a strong signal 1 a manager that doesn&#8217;t really think about their reports&#8217; career advancement won&#8217;t be prepared to answer the question mostly i&#8217;m sensing for whether managers are aware and into the &#8220;meta&#8221; aspects of management</li>
<li>A skill I would like to improve is to be a better mentor. What are my opportunities to get training?

<ul>
<li>Pair program with mentor</li>
<li>If I want to be promo in timeframe, what’s my path</li>
</ul>
</li>
<li>What are the ways in which a new person joining the team can have a high impact?</li>
</ul>


<p>Vs Expectations
  - Expectations 30-60-90 day</p>

<ul>
<li>Find the best intersection between my skills/interests and what is important for the company and get involved.</li>
<li>That they are strategically minded and looking out for their team and their reports
(Recognition is really important and it should not be only a subsection of the team giving demos. Maybe this is hard to pick when selecting a team)</li>
</ul>

]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Quotes I have loved]]></title>
    <link href="http://avidas.github.com/blog/2020/05/06/favorite-quotes/"/>
    <updated>2020-05-06T12:51:00-04:00</updated>
    <id>http://avidas.github.com/blog/2020/05/06/favorite-quotes</id>
    <content type="html"><![CDATA[<p>A brilliant and succint quote that says so much about our being.</p>

<blockquote><p>The negativity bias is a well intentioned learning disability.</p><footer><strong>Tara Brach</strong></footer></blockquote>


<p>Two quotes from the best book I have ever read.</p>

<blockquote><p>Everything can be taken from a man but one thing: the last of the human freedoms—to choose one’s attitude in any given set of circumstances, to choose one’s own way.</p><p>Between stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.</p><footer><strong>Viktor Frankl</strong> <cite>Man&#8217;s Search for Meaning</cite></footer></blockquote>


<p>I have been a long time admirer of the way Feynman lived his life.</p>

<blockquote><p>The first principle is that you must not fool yourself, and you are the easiest person to fool.</p><footer><strong>Richard Feynman</strong></footer></blockquote>


<p>Anais Nin should be more well known.</p>

<blockquote><p>Life shrinks or expands in proportion to one&#8217;s courage.</p><p>We write to taste life twice, in the moment and in retrospection. We write, like Proust, to render all of it eternal, and to persuade ourselves that it is eternal. We write to be able to transcend our life, to reach beyond it.</p><footer><strong>Anais Nin</strong></footer></blockquote>


<p><a href="https://nav.al/">Naval</a> may be the most quotable person around today.</p>

<!-- more -->




<blockquote><p>Desire is a contract that you make with yourself to be unhappy until you get what you want.</p><p>It is the mark of a charlatan to explain a simple concept in a complex way and it is the mark of a genius to explain a complex topic in a simple way.</p><p>A busy mind and a busy calendar will destroy your ability to create anything great.</p><footer><strong>Naval Ravikant</strong></footer></blockquote>


<p>Often quoted to JFK, this quote originated in the early 19th century.</p>

<blockquote><p>The rising tide lifts all boats.</p><footer><strong>The [New York] Christian Advocate</strong> <cite>Never Paralleled in New York</cite></footer></blockquote>




<blockquote><p>We don&#8217;t rise to the level of our expectations, we fall to the level of our training.</p><footer><strong>Archilochus</strong></footer></blockquote>


<p>Insight into how running can be a source of meaning.</p>

<blockquote><p>It&#8217;s not something most human beings would give a moment of consideration to, that it is actually possible to be living for years in a state of constant betterment.  To consider that you are better today than you were yesterday or a year ago, and that you will be better still tomorrow or next week or at tournament time your senior year.  That if you&#8217;re doing it right you are an organism constantly evolving toward some agreed-upon approximation of excellence.  Wouldn&#8217;t that be at least one definition of a spiritual state?</p><footer><strong>John L. Parker Jr</strong> <cite>Again to Carthage</cite></footer></blockquote>


<p><img class="center" src="http://avidas.github.com/images/just_breathe.jpg" width="500" height="500" title="Breathe" alt="Breathe"></p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Thriving Under Siege]]></title>
    <link href="http://avidas.github.com/blog/2020/04/12/thriving-under-siege/"/>
    <updated>2020-04-12T20:17:00-04:00</updated>
    <id>http://avidas.github.com/blog/2020/04/12/thriving-under-siege</id>
    <content type="html"><![CDATA[<p><em>Besieged</em></p>

<p>That one word captures the reality of living in NYC during the Covid-19 pandemic. It feels like being surrounded by an invisible, encroaching army, with no end to the siege in sight.</p>

<p>Everyday we are exposed to terrible news, how <a href="https://www.nytimes.com/2020/04/09/nyregion/coronavirus-queens-corona-jackson-heights-elmhurst.html">immigrants are hurting in my beloved Jackson Heights neighborhood</a>, mass burial grounds either locally or abroad in Italy and China. Bustling businesses in NYC have been reduced to laying off hard working employees.</p>

<p>There is no how-to manual for this current crisis, so devastating and foreign to all of us. Despite that, resilience is human nature. If there&#8217;s one place where our collective faiths have met, it is that better times are ahead. Is the thought of thriving during the age of Covid-19 heretical? It is perhaps more so to not attempt to.</p>

<p>Like many others, I have struggled with being quarantined in my apartment since March. I have immersed myself with the energy and drive that permeates NYC, and losing that has felt like being in withdrawal. At times, it has been a fearsome cocktail of loneliness, helplessness and concern.</p>

<p><img class="center" src="http://avidas.github.com/images/alone.jpg" width="500" height="500" title="Alone" alt="Alone"></p>

<p>I am a rational optimist. I like to think that better times can be ahead, but we have to strive towards it.  While my framework of life has been shaken by this crisis, it has yet to be broken, and it has definitely opened up more opportunities for self discovery.</p>

<p>Thanks to the internet, social media and on demand entertainment, simply passing time has stopped being a challenge. Rather, boredom has been a foreign concept to many of us surfing the world of dopamine rushes. Yet, deep inside, many of us feel that they fail to aid deep seated needs of purpose and self-actualization.</p>

<p>So how do we deal with our current consternation? Can we come out on the other side of this and be proud of what these last months meant for us? When we look back into this in five years, how will we think of this time?</p>

<p><strong>Invest in community</strong></p>

<p>It&#8217;s more important than ever to be there for your friends and family. Deepening relationships with our closest people have a way of giving back to our lives. That could just be video chats, and I have noticed myself talking to my folks a lot more since this began. There was also one night when, after some silly games on the House Party app, I realized I haven&#8217;t laughed this hard in a while and how necessary that was.</p>

<p><strong>Continue voting for your best self</strong></p>

<p>As the dust settled and I got more used to realizing that this is my life for the foreseeable future, I wanted to dig into things I could do but have been putting off due to the <strong>busy-ness</strong> of life. Not being as busy can be a positive thing, and opens up more time for things I have wanted to do more of.</p>

<!-- more -->


<p>Since Quarantine began, I have finished three books, and have enjoyed the process of being engrossed in a book more than usual, now that the usual societal stimulation has been removed. Using this time to read books I have been meaning to for a while has been enjoyable, accepting the mental escape that literature offers.</p>

<p>Cooking has added a lot of value to my life in the past, being able to create something nourishing that is beautiful and delicious is a very fulfilling act. I have been cooking more than I have been in a while and been really enjoying it. A good side effect of this is has been generally eating better since Quarantine.</p>

<p>Even before quarantine began, I have been coming off a challenging period in my life. Meditation has been the place I have been going to find center and grounding. It has also been fulfilling to keep a meditation streak of over 100 days and the reinforcement that just breathing can encapsulate all existence is powerful knowledge.</p>

<p>Life is not a scorecard, and the above activities are not things I do to achieve anything other than that I know my best self would enjoy. Even though they can be hard to start, they always make me feel better afterwards.</p>

<p><strong>Use this as an opportunity for greater self-discovery</strong></p>

<p>If you are on your own, you can truly choose how to spend a lot of your time. For myself, this has revealed for me that I thrive when there is human connection. Quarantine meant physical proximity has not been an option, but it has made me think about the key allies in my life, reaching out, resulting often in deeper conversations.</p>

<p>Creativity is important to my life, but it is stifled unless there is a stable base. An organized desk, a clean room and decorating my room so I can see artifacts that remind myself of my best times are actions I have doubled down on. Sleeping more is another such act, and I have given myself the license to sleep as much as I need.</p>

<p>I firmly believe that self-actualization is the modern day superpower. As someone who has a long way to go on that journey, this is our time for digging  deep. Whether it is seeking internally via meditation or solo walks, or externally by reading or deep conversations, may this time help us on that journey.</p>

<p><strong>Pursue acts of spirituality</strong></p>

<blockquote><p>It&#8217;s not something most human beings would give a moment of consideration to, that it is actually possible to be living for years in a state of constant betterment.  To consider that you are better today than you were yesterday or a year ago, and that you will be better still tomorrow or next week or at tournament time your senior year.  That if you&#8217;re doing it right you are an organism constantly evolving toward some agreed-upon approximation of excellence.  Wouldn&#8217;t that be at least one definition of a spiritual state?</p><p>  - Again to Carthage, John L. Parker, Jr</p></blockquote>


<p>The above is an excerpt from one of my favorite passages of writing. It has really touched the cord on why running has been a constant in my life over the last six years. Movement and running is essential for me at a subliminal level, and pursuing it is more of an act of spirituality than chasing personal records, experiencing the spectacle of a Marathon Major or accumulating mileage.</p>

<p>When I mention the word spirituality, I mean those acts that you follow with conviction whether or not an ulterior motive is involved. I have noticed that dancing plays that role for a lot of people as well. Whether it is running, dance or prayer, pursuing them can water a deeper part of us.</p>

<p><strong>Practice self forgiveness</strong></p>

<p>It&#8217;s important to not beat yourself over achieving goals, especially during this time. Comparing ourselves to a few selected people who achieved great acts of invention during times of trial is not a healthy activity.</p>

<p>In the same vein, there may be guilt which stems from the nagging feeling that you are not doing enough, that we could do more. It&#8217;s wonderful how some of us have risen to the needs and led efforts for mask production, test kit distribution etc, but those are not the only ways to add value to others.</p>

<p>Where we will end up is unknown, but isn&#8217;t that always the case? Existential threats and uncertainty can add a lot of suffering to our lives. Suffering is a side effect of being alive, but it is not where the goalpost is. Choosing to thrive in these times, taking actions that vote towards that direction and continue nurturing our deepest selves are some of the best things we can do in these times. I sincerely hope that manifests for you, dear reader.</p>

<p><img class="center" src="http://avidas.github.com/images/sunset_alone.jpg" width="550" height="550" title="Sunset Alone" alt="Sunset Alone"></p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Mindsets for Tech Behavioral Interviews]]></title>
    <link href="http://avidas.github.com/blog/2020/03/07/on-tech-behavioral-interviews/"/>
    <updated>2020-03-07T13:32:00-05:00</updated>
    <id>http://avidas.github.com/blog/2020/03/07/on-tech-behavioral-interviews</id>
    <content type="html"><![CDATA[<p><em>Axiom: Any software engineer writing a blog on tech will eventually write a post about interviews. - Yours Truly</em></p>

<p><strong>Interview Day</strong></p>

<p>You walk into a room with one or two people, who may be taking notes in a notepad or a laptop. The most common starter question is <em>tell me about yourself</em>.</p>

<p><img class="left" src="http://avidas.github.com/images/behavioral_interview.jpg" width="350" height="350" title="Interview Chair" alt="Interview Chair"></p>

<p>This used to be a question I didn&#8217;t know where to start or end. A possible interpretation of this question is to provide a succinct summary of your career.</p>

<p>The opportunity here is to prime the interviewer towards directions which would highlight your best career experiences. What part of your experience would be the most pertinent for this job? Doing this thinking beforehand would be helpful for the latter part of the interview.</p>

<p>As an interviewee, we are in a sales role and the product is our skills, experience and future potential. For engineers, this is not a natural part of our workflow. The best sales, however, is based on truth. Being honest and talking proudly about your best career achievements will aid you in this early phase.</p>

<p>A very common follow up is <em>what your ideal next role would look like</em>? You&#8217;ve just given them the path which got you to where you are. It is now time to lay out what you want for the future.</p>

<p>The opportunity in this question to highlight areas where you want to grow. Do you see yourself going into engineering management? Do you want to become really good at javascript and browsers? Or do you prefer to become an expert in server and cluster management? Again, it serves you to be honest here since this question helps you to evaluate if the growth opportunities you are looking for would be possible at this company.</p>

<p><em>Go in with a win-win mentality: It is a lot more about finding a mutual fit rather than getting through a cross examination.</em></p>

<p>After this point, the interview can go in a lot of different directions. Companies may dig deeper into your past experience or go through example scenarios to understand your  thinking process. Knowing your resume and being able to talk in depth about each part will be important.</p>

<p><strong>Before The Interview</strong></p>

<!-- more -->


<p>Practice and preparation will undeniably make you better. Even if it&#8217;s a friend who is asking you a series of questions, answering them again and again will solidify those responses and you don&#8217;t have to think every permutation of interview questions on your feet during the interview.</p>

<p>Despite that, it&#8217;s impossible to prepare for every possibility. In those cases, it&#8217;s useful to get better at on the spot thinking. I suggest the following three activities to improve on that front.</p>

<ol>
<li><p><strong>Meditation</strong>: Meditating on the morning of the interview can be great to calm down your nerves and help with fight or flight syndrome during an interview.</p></li>
<li><p><strong>Public Speaking</strong>: Whether it is in front of a group of friends, or coworkers or a wider audience, public speaking will sharpen your ability to be more poised when the spotlight is on you.</p></li>
<li><p><strong>Improv</strong>: Improv is a <a href="http://aviadas.com/blog/2019/03/16/life-lessons-from-doing-improv/">wonderful activity</a>, and it is all about being on the spot and working with stranger in a supportive environment building a scene and creating a story. I have found the spontaneity of Improv to be a great value add when facing an interview panel.</p></li>
</ol>


<p>Good luck with your interview process!</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Chicago Marathon 2019 Race Report]]></title>
    <link href="http://avidas.github.com/blog/2019/11/23/chicago-marathon-2019-race-report/"/>
    <updated>2019-11-23T17:12:00-05:00</updated>
    <id>http://avidas.github.com/blog/2019/11/23/chicago-marathon-2019-race-report</id>
    <content type="html"><![CDATA[<p><em>A big step forward and lessons learnt along the way.</em></p>

<p><strong>Race Day</strong></p>

<p>For goal races, I usually wake up before the alarm goes off. October 13th was no different. Despite the 3:30 am wakeup, I slept unusally well considering it was the night before the race. I KT taped my foot carefully, which I had to do throughout the training cycle to defend against feet issues. After the usual overpacking of gear check bag, I joined my Dashing Whippet housemates on the train ride to the starting line.</p>

<p><img class="left" src="http://avidas.github.com/images/marathon_photos/pre_race.jpg" width="350" height="350" title="Pre race" alt="Pre race"></p>

<p>In the race village, I watched the sea of green feet (nike Next %s), and waited till it was time to get to the start line. The race corral was already busy over half hour left before race start. I went through the motions of shedding extra clothing, doing warmups in the cramped environment and holding back the nerves. It was colder than I expected, which wasn’t a bad thing at all. It would stay cool during the whole race, which meant overheating never became an issue.</p>

<p>At the start line, I felt good. No major injuries have cropped up since March, and training went as well as it could. Despite that, I wanted to stay committed to running a smart race. Marathon is too long of a race distance to predict an outcome and I wanted to stay within myself as long as possible.</p>

<p>I saw the 3:15 pacemaker, and realized I was in two minds whether to go with him or not. I decided to trust my training and focus on running my own race.</p>

<p>The race began, and in the beginning mile I stayed attentive to what my body was telling me. The surge of adrenaline wanted me to speed up, but I held back and moved with caution. At mile 1, I heard my name from a friend cheering and immediately felt better. It is so valuable to see familiar faces during a race.</p>

<p>As early as mile 2, my GPS was completely haywire. I had to stop paying attention to the speed that the GPS was showing me and decided to count every 5k interval instead. I knew those times by heart from training.</p>

<p><em>23, 46, 1:09, 1:32, 1:55, 2:18, 2:41, 3:04…</em></p>

<p>I got to 5k within the limit without much issues. Chicago is one of the best marathons, and crowd support is a big part of that. The first half of Chicago is electric, with non stop crowd support, and they showed up strong on an overcast, windy day. It feels as if hundreds of thousands of people are on your side, and you want to run well for their sake.</p>

<p>Then next 5k also went fairly quickly. I have found the miles between 8-12 mentally tough during training and it was definitely no different during race day, injecting some doubt into my race strategy. Every person racing at their limit must battle negative thoughts, there is really no other way.</p>

<p><img class="left" src="http://avidas.github.com/images/marathon_photos/chicago_most_photogenic_mp_1.png" width="350" height="350" title="Chicago 20k" alt="Chicago 20k"></p>

<p>At 15k, I was able to keep a buffer of over a minute. It wasn’t clear to me whether the pace was sustainable the whole course. I wasn’t looking at the watch until a 5k interval, so there wasn’t much to rely on other than how I felt running. I kept repeating the words in my head.</p>

<p><em>Smooth. Calm. Relaxed. Metronomic.</em></p>

<p><em>Stay as calm as a Tibetan Monk.</em></p>

<p><em>Only a couple hours or so and I can go run trails.</em></p>

<p>Around mile 11 or 12 during the race, another runner cut sharply into my path, a near collision. As I looked at him, I went from bewilderment to anger to laughing out loud in the period of a second. “Wherever you are trying to go dude, I hope you get there&#8221;, I said silently as I shrugged and carried on.</p>

<!-- more -->


<p>I thought about getting to the start line and getting up to this point. I thought about the Tuesday night tempo workouts, Thursday night speed workouts in East River, Saturday morning long runs, all the work that went in. Even if the race fell apart at some point, there would solace in knowing that I came this far. Maybe I could go on for another 5k.</p>

<p>Once I passed 20k, I was getting more in the zone. There is a lot of beautiful Chicago neighborhoods the race takes you through. There are people carrying signs and blasting music and screaming words of affirmation from the sidelines. I don’t remember any of them specifically though. I remember staying close to the blue line as much as possible, which marked the point to point 26.2 miles on the course.</p>

<p>I crossed 13.1 miles at 1:36:21, well within goal time and feeling well. I was feeling well with the pacing, at the same time the relative effort was feeling harder with each 5k. I was feeling searing pain in my foot, but there wasn’t much I could do. The only possible option was to continue forward.</p>

<p>The plan was to stay ahead of hydration and nutrition, and it got me very well up to 25k and then onto 30k on pace. Around then my stomach started cramping up, meaning I was no longer able to take in more gels. This is the point of the race when the mental game really begins. I was still holding out hope for a late surge, but it would prove to be wishful thinking.</p>

<p><img class="left" src="http://avidas.github.com/images/marathon_photos/chicago_pain_face_mp_1.png" width="350" height="350" title="Chicago 40k" alt="Chicago 40k"></p>

<p>Past 35k, this is where the race got really difficult. Each mile felt like it spun forever and legs felt heavier. This is also the part of the race where the crowd thinned out, so support was few and far between. I felt as though I didn’t have space for either negative or positive thoughts. All of energy and attention was necessary to keep prodding ahead.</p>

<p>In my past four marathons, at the three hour mark of a marathon, I have quite a bit of running left to do. This was noticeably different. There was less than fifteen minutes of running left and it was time to empty the tanks.</p>

<p>As it turned out, the tanks were empty enough already, and maintaining pace was all my legs could manage. At this point, I was running back into the city, and the spectators were really turning up the cheering. I needed all the help here. The last couple miles bought blast of headwinds, the largest hill of the course and a sprint across the final stretch. I looked at the watch, it said 3:13, a PR of almost 26 minutes. Mission accomplished.</p>

<p><strong>Buildup to Chicago</strong></p>

<p>I got in to Chicago Marathon through the lottery early December 2018. Chicago was my second marathon back in 2016, and I had good memories from that year. Late 2018, I was on the road to recovery from lingering Plantar Fasciitis and feeling optimistic. I must have felt too optimistic though, as I hurried back into training only to get sidelined with a metatarsal stress fracture. To add to that, my shoulder  got injured from rock climbing, making it a tough winter to go through. In mid March I was finally able to run/walk again and had to be careful to build back with caution.</p>

<p>In March, Chicago felt very far away. Injuries have plagued me since August, and I haven’t had a personal best race since April 2018. I decided that doing the NYRR 9+1 would be a good way to get back into racing and have more near term races. The first one was early May, Fiesta 5k race in Jersey City. It went well, giving me a boost in confidence.</p>

<p>It won’t last long though as the next one was Brooklyn half, where I went in badly suffering from allergies and after exiting Prospect Park at mile 7, I found it impossible to breathe. Thankfully Lisa, a running friend from Austin, found me and we jogged the rest of the way. It was demoralizing to go through, but every day cannot be a win.</p>

<p>In the following weeks, I was steadily increasing mileage, able to gradually get back to doing workouts again and do more NYRR races: the Italy run, Pride run, sprinkle in some trail runs. The benefit of all these was that I was able to enjoy running again. I was learning how to pace myself in shorter distances. At the same time, I had to be patient. Those were not my goal races.</p>

<p>As temperatures rose during the summer, so did mileage. In July, I got back to doing a 15 mile long run, my longest run of the year. After team championships, it was time to fully dedicate to marathon training. July, August, September combined a total of over 630 miles. This was the first time that I followed a training plan to run a Marathon. It was far from smooth sailing, however.</p>

<p>There were many times I thought the foot injury was back and things were at the edge of falling apart. I would show up at a workout at Central Park and wonder if this would be the day my training cycle would be over. I realized that the only way to get through them was to remind myself that I enjoyed the process, and if this was my last workout, I should enjoy it as much as I can.</p>

<p>During the lead up to the Marathon, I did all I could to sustain the workload. I introduced yoga, daily foam rolling, and core strengthening as ways to support myself as the mileage and training got more demanding. I made sure to never skip warmups and cooldowns around workouts. I prioritized sleep, tried to eat healthy and cut out alcohol completely as the race got closer. I ran my easy days really easy to ensure they promote recovery, running them primarily thinking about form and not the watch.</p>

<p>Then came the 20 milers, which were a steep learning curve after a long break. These runs are key in a Marathon training plan to get ready for when things get really hard during the last 10k of the race. As a tune up race, I ran the 18 miler NYRR run in Central Park. I made some mistakes in that race: started too fast, forgot my gels. I had to check back my pace at mile 7 since the effort was too much but then was able to recover and steadily progress again. Despite feeling spent after that effort, it gave me a lot of confidence executing close to marathon effort for that long.</p>

<p>I had a meeting with coach Forti and discussed race day planning. He suggested running 23 minute 5ks since it mapped well to my time goal. I haven’t tried this before, but I liked the idea of looking at my watch less.</p>

<p>During the two week taper, I significantly reduced mileage to let the body heal. More than a time goal, showing up at starting line healthy would be a great win and I wanted that win.</p>

<p>I stayed with Dashing Whippets teammates in Chicago, which helped with pre race nerves, since the whole group was going through it. The day before the race, we did a shakeout run with the Heartbreak Hill Running Company in Chicago.</p>

<p><strong>Post Race</strong></p>

<p><img class="left" src="http://avidas.github.com/images/marathon_photos/chicago_end.jpg" width="350" height="350" title="Post Race" alt="Post Race"></p>

<p>It felt really good after the race. You can hypothesize about a Marathon goal, but it is just a theory until it happens in a race. It vindicated that a lot of things were done right during this training cycle, and revealed areas of improvement necessary to run a stronger Marathon. Marathon is a complex puzzle piece, and all individual components need attention and care to come together on race day.</p>

<p>Where does this leave me? I am deeply grateful for this race, having converted a lot of work that happened during the last two years and not pick up a new injury. It’s a good place to be, but I do feel that progress from here is going to be significantly harder. A potential BQ is still very, very far away. I have decided to not worry about that too much though, rather try to get better at short distance running and do some trail running.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[React Amsterdam 2019: Takeaway]]></title>
    <link href="http://avidas.github.com/blog/2019/04/14/react-amsterdam-2019-takeaways/"/>
    <updated>2019-04-14T11:16:00-04:00</updated>
    <id>http://avidas.github.com/blog/2019/04/14/react-amsterdam-2019-takeaways</id>
    <content type="html"><![CDATA[<ul>
<li>The case of GraphQL (Peggy Rayzis)

<ul>
<li>Productivity boost across teams</li>
<li>Smaller payloads</li>
<li>Fewer client/server round trips</li>
<li>Preventing over fetching</li>
</ul>
</li>
<li>Great Developer Experience (Peggy Rayzis)</li>
</ul>


<!-- more -->


<ul>
<li>Unobtrusive, out of the way e.g. Prettier</li>
<li>Predictable and intuitive, e.g. declarative React paradigm</li>
<li>Instant Feedback Loop e.g. VSCode/TS</li>
<li>Design Systems (Mark Dalgleish &amp; Andrey Okonetchnikov)

<ul>
<li>Universal Language > Technology</li>
<li>Set of design related rules as system of instructions that can be reused across products</li>
<li>Shared language between designers and developers enforced by tooling</li>
<li>Design powered development tools</li>
<li>Developer workflows as productive as designers</li>
<li>UI components and pattern libraries can provide this intermediate abstraction and be a common language for both designers and developers.</li>
</ul>
</li>
<li>Micro Frontends (Max Gallo)

<ul>
<li>Autonomy/Responsibility with Teams Innovation</li>
</ul>
</li>
<li>Better you understand the abstraction, better you are at using it (Kent C Dodds)</li>
<li>Write code that is resilient to future change (Max Stoiber)</li>
<li>Use existing solutions for tech problems if you don’t understand deeply (Bias towards conservative choices)</li>
<li>Be open about roadmap to learn about users priorities</li>
</ul>

]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Life lessons from Improv]]></title>
    <link href="http://avidas.github.com/blog/2019/03/16/life-lessons-from-doing-improv/"/>
    <updated>2019-03-16T15:07:00-04:00</updated>
    <id>http://avidas.github.com/blog/2019/03/16/life-lessons-from-doing-improv</id>
    <content type="html"><![CDATA[<p>I think life should be more like improv and improv should resemble life.</p>

<p>On a whim, I went to hideout theatre in Austin, TX for a improv beginner class back in 2016 but I have only been consistently doing improv for the past year. In the process, I have tried short and long form improv, and dabbled in musical/rap improv. Having zero theatre/stage background, it has been amazing to me how the lessons learnt from improv apply to life broadly.</p>

<p><img class="left" src="http://avidas.github.com/images/improv.jpg" width="350" height="350" title="Improv" alt="Improv"></p>

<ol>
<li><p><strong>Yes, and..</strong>: A 101 on improv would begin with the encouragement to accept whatever the other person is bringing to the scene. We may have a great idea in mind, but the scene is ruined if we do not accept the other person&#8217;s ideas and bind the scene in a cohesive way. Taking this attitude to life can frame anything in life as a gift. This in turns lends us to be less critical and cynical about our day to day interactions.</p></li>
<li><p><strong>Go with the first thing that comes to mind</strong>: Perfect is often the enemy of the good. Overthinking can stand in the way of action when spontaneity may have been the right choice. In improv, trying to think of a funny punchline can ruin an act, taking away from it the natural flow of the scene. On the other hand, going with the first thing that comes to mind often leads a scene to wonderful surprises. Real life decisions do involve more thought, but the training against overthinking still holds and can help us live a more spontaneous life and overcome the fear of taking action.</p></li>
<li><p><strong>Embracing failure</strong>: Making a fool of yourself is encouraged and celebrated in improv. The very act of complete unpreparedness on stage, taking the audience&#8217;s suggestion to theme a scene and strangers as partners means that you don&#8217;t have any semblance of control. There is no guarantee that an improv scene will be funny to the audience or reach a satisfying closure. But everyone in improv understands this, and supports your choices on stage regardless. This empowers improvisers to be authentic on stage. It also makes us realize that the consequences of failure may be less than we realize. This training is so important in life where fear of failure can hold us back.</p></li>
<li><p><strong>Make others look good</strong>: In improv, we succeed when we have made the others on stage successful. Supporting their ideas, pointing out the authenticity of their actions and emotions goes a long way into making a scene feel natural and relatable to the audience. When working with improvisers who are gifted in building out storylines, a great way to complement their work is to add other dimensions to the scene such as a location, timeline or other context to create a richer, vivid scene. This prioritizing of win-win mentality is a great habit for teams, since an effective team should be greater than the sum of its individuals.</p></li>
<li><p><strong>Make statements, don&#8217;t ask questions</strong>:
Making statements adds material to a scene, whereas a question puts the burden on the other to come up with the material. This is why it is encouraged in improv to limit questions and respond with statements. This is great for your communication skills, making conversations feel less like interrogations. People feel more at ease in a conversation when they feel they don&#8217;t have to do all the work. A related advice is to try and use every sentence in improv as if it would be a closing sentence, since a scene could end at any moment. <!-- more --></p></li>
<li><p><strong>Leading with emotions</strong>:
An audience is watching an improv scene has a fuller experience when they not only hear the words but see the emotions of the performers. Life is certainly more complicated. If you are investing in the stock market or playing poker, it is best to distrust or hide your emotions. On the other hand, lot of us lack the ability to emote even when situations demand it, because our upbringing has taught us to treat display of emotions as weakness. Improv can help unlearn and be more expressive in situations when we should lead with our emotions.</p></li>
<li><p><strong>Take the scene somewhere</strong>: In an improv scene, you and your partner create a character and a world which has the shelf life of the scene. The scene can be as short as a minute and half. It is great for the audience when the scene builds up to something, has a beginning, middle and end. In the movie of our lives, we are the protagonists living our story. The practice of improv helps us build a viewpoint of our lives from a third party perspective, and can make us wonder how we want the protagonist to act. To use a computing analogy, it would be similar to seeing life from a debug mode.</p></li>
<li><p><strong>Listen</strong>: There simply cannot be a good scene where you ignore the words, behavior and actions of your partner. Improv helps emphasize the importance of listening, the power of which is well understood.</p></li>
<li><p><strong>Have fun</strong>: The audience knows when the performers are enjoying themselves, and can feel they are part of it too.</p></li>
<li><p><strong>Commit to a scene</strong>: A more experienced improviser advised me to commit with your voice, face and your body. The practice of complete immersion in a scene can help us be more present when we show up in life.</p></li>
</ol>


<p>The beauty of improv is that you don&#8217;t have to become a great improviser to see the positive effects it can have on your life. Those of us who believe in constant improvement and are interested in living a more examined life and will find improv valuable.</p>

<p><img class="center" src="http://avidas.github.com/images/improv2.jpg" width="500" height="500" title="Improv Last" alt="Improv Last"></p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Frame code reviews as gift exchanges]]></title>
    <link href="http://avidas.github.com/blog/2019/03/16/pull-requests-as-gift-exchange/"/>
    <updated>2019-03-16T15:04:00-04:00</updated>
    <id>http://avidas.github.com/blog/2019/03/16/pull-requests-as-gift-exchange</id>
    <content type="html"><![CDATA[<p>The best metaphor I have found for thinking about code reviews is a gift exchange. The terms pull request and code reviews will be used interchangeably in this post.</p>

<p>The balance of writing code vs everything else that is necessary to be a successful member of a software team is one of the key challenges of our job.</p>

<p>Code reviews are an interesting mix. You have to understand someone else&#8217;s point of view, their journey through solving a problem in form of code. Or you have to face up to what everyone else thinks about code that you worked hard to write. Those reviews stand in your way of getting your code up to users and getting the emotional payoff from releasing something. The engagement or catharsis from building software is not an available reward when you are in code review mode.</p>

<p><img class="left" src="http://avidas.github.com/images/code_review1.jpg" width="350" height="350" title="Code Review" alt="Code Review"></p>

<p>Moreover, a code review must take into consideration not just the code, but the project, team and the company into consideration.</p>

<p>These qualities make code review a great opportunity to practice interpersonal skills alongside your programming skills. The best engineers I have worked with take code reviews and responding to feedback on their own pull requests very seriously. Specific strategies that engineers use are different. Some review pull requests first time in the day, others end of the day or anything in between.</p>

<p>Framing is a powerful technique we can use when summoning the energy to do code review everyday. It would be to see every request for a code review or feedback you receive on code review as a gift. Someone values your intelligence enough to ask for your review or taking their valuable time to give you feedback that can only improve you as an engineer. Everyday, you receive these gifts. But you can also offer them to others, which in itself is a meaningful and satisfying act.</p>

<p>Viewing pull requests this way makes them less of a transaction, and illustrates code reviews as a win-win game. So next time you are opening up a pull request, think how you can make it easier for someone else to review. Can you link to the ticket, provide a screenshot/gif, added sufficient comments and followed good coding practices? Have you considered breaking your change into smaller chunks? Can you sit down with a reviewer and go over the changes in code?</p>

<p>Let&#8217;s make it easier for someone else to offer us this gift.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Thoughts on button push driven development]]></title>
    <link href="http://avidas.github.com/blog/2019/02/24/on-button-push-driven-development/"/>
    <updated>2019-02-24T09:19:00-05:00</updated>
    <id>http://avidas.github.com/blog/2019/02/24/on-button-push-driven-development</id>
    <content type="html"><![CDATA[<p>I was in a conversation the other day when someone mentioned</p>

<p><em>&#8220;We may only be a couple Moore&#8217;s Law iterations away from all software built by pushing buttons and WYSIWYG editors.&#8221;</em></p>

<p>This made me think of the software that we write today and the direction software is going. It also made me think of why I got into software and am still in this profession.</p>

<p>Lately, I have been very curious about voice as a computing platform and what that will do for applications we use in future. Thankfully, as software engineers, we don&#8217;t have to hypothesize. We can build it.</p>

<p>Digging into Alexa skills development has been interesting. While the technical documentation and development for Alexa is quite good, I felt a fair amount of internal resistance during the project. The potential of this new computing platform and the possibilities it will bring kept me going.</p>

<p><img class="left" src="http://avidas.github.com/images/yes_code.jpg" width="350" height="350" title="Yes Code" alt="Yes Code"></p>

<p>The building blocks of working with Alexa are intents, utterances and lambda functions. After a series of thirty or so steps of wiring up buttons, copying and moving templates around, setting up attributes gives you a working voice enabled app, upload zip files, deploy it and submit for app review in the Alexa app store.</p>

<p>Why did I feel the resistance? Any new tool or language will bring an initial set of frustration before we achieve a minimal level of proficiency. But Alexa development felt like using a software program rather than programming. It felt challenging the way gruntwork feels challenging and as opposed to intellectually stimulating. It also felt opposite to when I have felt the most joy during programming. When I had a strong grasp of the vocabulary of the language and the meta-language (libraries, development environment,runtime, etc), leaving room for higher level product/architectural decisions where most things are a tradeoff. This meant I had to do <em>very minimal context switching</em>. When writing an app for Alexa, it feels driven by context switching.</p>

<!-- more -->


<p>Continuous context switching has real penalties. In <a href="https://www.amazon.com/Deep-Work-Focused-Success-Distracted/dp/1455586692">Deep Work</a>, Cal Newport points out that the more time we spend effortlessly focusing on a difficult task, the happier we are. The ability to do deep work is one of the greatest joys of programming. So while using WISYWIG or code as configuration can lower barrier to entry for software development, they do take away the mindful aspects of programming.</p>

<p>That left me with the following thoughts.</p>

<ol>
<li>Democratizing building of software applications is the direction in which software should go. <em>Just like literacy, tools of creativity should not be limited to those who have the time to learn or funding to hire people to do it.</em> If information hoarding is one&#8217;s only advantage, one is asking for disruption.</li>
<li><em>If solving problems is what gets you excited about programming, in the next decade you will want to think about focusing on areas more resistant to this change</em>. Infrastructure and tools development are more resistant to this change than application development, but there is less of it to be built compared to applications.</li>
<li><em>Programming is still a difficult thing to do. Building quality, lasting software is expensive for a business.</em> For a business, the ability to reduce this cost by using WISYWIG tools or code as configuration will always be appealing.</li>
<li>WISYWIGs encourages dependence on higher level tools which reduces the need to learn about the fundamentals and increases the risk when the tools themselves break.</li>
</ol>


<p>I hope this is a blogpost I get to laugh it in five years due to how much things have changed. But I do think this trend in software development has consequences as far as who will be interested in programming in the future and the intention people have when they get into programming.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Books I read in 2018]]></title>
    <link href="http://avidas.github.com/blog/2018/12/24/books-i-read-in-2018/"/>
    <updated>2018-12-24T14:07:00-05:00</updated>
    <id>http://avidas.github.com/blog/2018/12/24/books-i-read-in-2018</id>
    <content type="html"><![CDATA[<h3>General/Personal Development</h3>

<ol>
<li><strong>The art of living (Thich nhat hanh)</strong>: This is the best Thich nhat hanh I&#8217;ve read, composing his philosophy on living an examined life into day to day practices.</li>
<li><strong>Thinking in systems, a primer (Donella Meadows)</strong>: Really, really smart author, systems thinking should be a required course in college.</li>
<li><strong>Ain’t I a Woman: Black Women and Feminism (Bell Hooks)</strong>: Challenges a lot of assumptions, covering black woman&#8217;s involvement with race identity and feminism.</li>
<li><strong>When: The Scientific Secrets of Perfect Timing (Daniel Pink)</strong>: Dan Pink&#8217;s books are similar to Malcolm Gladwell&#8217;s, distilling behavioral psychology research into easy reads.</li>
<li><strong>The Essential Rumi (Jalal Al-Din Rumi)</strong>: Lately I have started admiring how much Poetry can accomplish with so few words. There is something very calming about reading Rumi.</li>
<li><strong>Sex at dawn (Christopher Ryan‎, Cacilda Jethá)</strong>: An incendiary/challenging investigation into human/primate sexuality, sweeping across history to construct the narrative, much like Sapiens by Yuval Noah Harari.</li>
<li><strong>Deep work (Cal Newport)</strong>: So good, anyone doing knowledge/creative work would be benefited by this classic.</li>
<li><strong>The life changing Manga of Tidying Up (Marie Kondo)</strong>: I have been leaning towards minimalism, and Marie Kondo offers very actionable steps to cleaning up, and why doing this is related to the life we want to have.</li>
<li><strong>Flow: The Psychology of Optimal Experience (Mihaly Csikszentmihalyi)</strong>: There is strong evidence at this point that time spent in flow state, (an state of effortless concentration on a single task), can be correlated to contentment/happiness. I really liked the first part of the book but thought it could be much shorter.</li>
<li><strong>Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead (Brene Brown)</strong></li>
<li><strong>So good they can’t ignore you (Cal Newport)</strong>: Much like deep work, essential reading for those looking to improve their craft.</li>
<li><strong>How to change your mind (Michael Pollan)</strong>: Eye-opening, challenging look at the resurgence of Psychedelics in mental health research.</li>
<li><strong>A life in parts (Bryan Cranston)</strong></li>
</ol>


<!-- more -->


<h3>Tech</h3>

<ol>
<li><strong>Radical Candor (Kim Scott)</strong></li>
<li><strong>The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win (Gene Kim)</strong> A curiously engaging fiction on DevOps and executive level politics in a large tech company.</li>
<li><strong>Designing data intensive applications (Martin Kleppmann)</strong>: One I will be re-reading many times.</li>
<li><strong>The master algorithm (Pedro Domingos)</strong>: An inspiring call to action and possibility of general artificial intelligence.</li>
<li><strong>The manager’s path (Camille Fournier)</strong></li>
<li><strong>The Passionate Programmer: Creating a Remarkable Career in Software Development (Chad Fowler)</strong></li>
</ol>


<h3>Running</h3>

<ol>
<li><strong>Running Rewired: Reinvent Your Run for Stability, Strength, and Speed (Jay Dicharry)</strong></li>
<li><strong>Endure: Mind, Body, and the Curiously Elastic Limits of Human Performance (Alex Hutchinson)</strong></li>
<li><strong>North (Scott Jurek)</strong>: Loved how personal this story was both for Jurek and his wife Jenny, alternating their narratives</li>
<li><strong>Again to Carthage (John L Parker)</strong>: Amazing in certain parts, especially near the end where Cassidy runs Olympic trials, but too long and dragging for most of it.</li>
<li><strong>Running with the mind of meditation (Sakyong Mipham)</strong>: What does a lifelong meditator who also ran the Boston marathon has to say about the sport?</li>
</ol>


<p><em>In no particular order, mostly read while being on the NYC subway!</em></p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Core tenants of highly effective software teams]]></title>
    <link href="http://avidas.github.com/blog/2018/11/03/core-tenants-of-effective-software-teams/"/>
    <updated>2018-11-03T11:47:00-04:00</updated>
    <id>http://avidas.github.com/blog/2018/11/03/core-tenants-of-effective-software-teams</id>
    <content type="html"><![CDATA[<p><em>This blogpost is my thoughts only and does not necessarily represent the positions of current or past employers.</em></p>

<p>We don&#8217;t build software in a vacuum. Software involves people. Beyond organizations of a handful of people, hierarchy is beneficial. We get teams, commonly with engineering manager/lead, product manager, designers and engineers. What becomes crucial for the software and the product delivered then is the effectiveness of the team. Throughout my career in the industry and being part of many teams in different circumstances, I have started noticing some key patterns that really drives standout results in teams.</p>

<ol>
<li><p><strong>Believing in a common cause</strong>: The single biggest observation is that when a team of people believe in a common mission, they produce outsized returns. The most effective teams I have worked in all had a strong belief that they was a reason for the work they were doing. This also aids inter team collaboration over inter team competition, with teams often investing in tooling that makes the whole team better.<br/><br/>Engineering leaders can play a key role here to frame a compelling mission for the team. Hiring for the right role also becomes super important as a highly motivated individual in a role can be 2-10x more effective than someone unmotivated with similar ability. Having a competitor or a common enemy is great since we are predisposed to bond over defending ourselves from common enemies.</p></li>
<li><p><strong>Psychological Safety</strong>: Google&#8217;s <a href="https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html?_r=0">Project Aristotle</a> studied 180 teams over two years and came to the conclusion that psycological safety was the best signal for how effective a team is. How comfortable do people in the team feel to share vulnerability without fear of retribution? How comfortable do people feel asking questions without fear of asking something silly or share ideas without fear of being shut down without listening? Team&#8217;s with high levels of psychological safety can have conflicts, but can deal with them in a mature way, being able to separate disagreement about ideas from disagreement with people.<br/><br/>For more senior engineers/technical leaders, this is crucially important since they are in a position to determine this culture for the team. Forming strong personal relationships with the team can be really valuable for fostering safety within the team. People like their leaders to be human, and admitting your own fallibility is a great way to form trust with team members.</p></li>
<li><p><strong>Diversity of Thought</strong>: Diversity is a word that is commonly heard in the tech industry, and for good reason. Having diversity of people is a proven way to achieving diversity of thought, which is just one of the reasons why we must invest in software communities of women and minorities. Inclusiveness is one of the key pillars of psychological safety in a team, building on from the last section. Moreover, when software is aimed at global audience, but the team is homogeneous, it is easy to be fooled that a wide audience will get their needs met.<br/><br/>Even teams of experienced contributors can fall prey to atrophy and decay, without fresh ideas so common in upstarts. A team of really excited newer developers may not realize that in balance lies the key to long term personal, team and product success. Diversity of experience in a team helps to avoid these common traps.<br/><br/>Finally, cross functional teams can be more effective than teams exclusively focusing on frontend/backend/mobile. Recognizing the individual contributor&#8217;s interest in user experience/security/governance etc and enabling space for that one of the most enabling things an engineer leader can do.</p></li>
<li><p><strong>Growth and Ownership</strong>: It is immensely gratifying for people to feel that they are growing, and knowing that they are playing a role in the growth of others. When team members feel confident about the path in front of them can still have challenges, they are far less likely to be unmotivated and plateau. This is big for retention, since job changes frequently are a result of people feeling stuck and needing to make a change. It is costly to replace engineers, especially ones already trained and performing well in their role.<br/><br/>A key intrinsic motivator for many is the feeling of ownership. Being able to really sink their teeth into a hard problem and come up with something they are proud of. Teams where people really believed that they have strong ownership of the product also care more about the end users experience, resulting in a better product.<br/><br/>As engineering leadership, one of the best signals of good management is to have clarity in career ladders and promote the right people. A bias for people who make others around them better can be healthy. It is my experience that promotions should rarely come as a surprise to the individual or the team. Demonstrated investment in people as future leaders is also a major indication of a company&#8217;s belief in their people, sending them to conferences, training and giving license for creativity.</p></li>
<li><p><strong>Work Environment</strong>: This is a controversial one, but I do believe that companies today have bought way too much into the open office movement. While a return to cubicles does not feel desirable, dedicated interruption free zones (both space and time) are essential for good software. A chaotic office environment can also mean chaos in your codebase.<br/><br/>Debates range whether standing desk or sitting is better, however many monitors are necessary. My belief here is that the team should be colocated but individuals should be empowered to find the best working situation for the track of work they are in. I have personally found that standing keeps me on my toes, making it great for lots of small tasks, whereas sitting is best for tasks that need deep thought.</p></li>
</ol>


<p><strong>When things fall apart</strong></p>

<p>We do not live in a perfect world. Recessions, unexpected downsizing, market competition and many other forces can impact access to resources which could result in ways in a group of people come in to work together and stop working together. Lot of us have all worked in a team where that magic of a great team existed, and the team achieved things together what could not be achieved by individuals. It is important for us to be thinking with intention and purpose and help each other build and find teams to discover that magic.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Jersey Half Marathon 2018: Race Report]]></title>
    <link href="http://avidas.github.com/blog/2018/05/09/jersey-half-marathon-2018-race-report/"/>
    <updated>2018-05-09T10:21:00-04:00</updated>
    <id>http://avidas.github.com/blog/2018/05/09/jersey-half-marathon-2018-race-report</id>
    <content type="html"><![CDATA[<p>&#8220;Gatoradeee!! Water!&#8221; The sudden enthusiastic cheer after a period of silence was hard to miss. Looking up, I saw the 10k marker. I looked at my watch and I was about to PR a 10k. Except that I was not running a 10k. I was running a half Marathon and with more than half of the race still ahead of me, this was bad news.</p>

<p>Post NYC marathon last November, I was happy to have run my goal race in a good time. I knew I was hitting my upper limits with the Marathon, and without focus on shorter distances, I would not get faster. I focused religiously on the Tuesday tempo and Thursday speed workouts with the Dashing Whippets central park group. It was inspiring to see the people training for Boston Marathon putting in incredible work during some difficult months.</p>

<p>This season’s training posed many challenges, primarily freezing temperature, snowstorms, breakups. Every time I stepped out the door and breathed in the icy air into my lunges, everything inside me wanted to get back inside and wrap myself in a blanket.  But the workouts had a way of enforcing discipline into my life. For Saturdays, I made the commitment to keep showing up and sometimes challenge myself by going with a slightly faster group.</p>

<p>The group kept me going. If everyone else have no problems showing up and putting in the work in dark and cold, I have no excuses not to. When I was in the pain cave during the Jersey Half, that was what going though my head. I am in the deep end, but I owed my 600 mile training cycle a good performance and take responsibility for strategic mistakes early in the race.</p>

<p>As I realized my mess up during the Jersey half, I realized I needed a baseline pace or I would fade. My inner voice said don’t fade, every second counts. So I found couple runners putting down 7:15 miles and making it look like cakewalk. Later I learnt that they were running the marathon. Talking to them helped me get some boost. After that, I found another pace group, and hung with them all the way to the end.</p>

<p>The value of this race as a developing runner is that it answers some lingering questions. How fast am I? Am I capable of taking my progress in training and convert it on race day? Am I training with the right group of people or just tagging along with faster runners for dear life. That’s what this half will mean for me, that I have improved this training cycle and while my strategy and mental game needs work, I can enjoy the following week knowing I made progress. Progress where I used to think there is no way I can hold a 7:09 pace for 13 miles but there is now data to prove otherwise.</p>

<p>So that was the Jersey Half. I am very happy with the result having converted a 10 minute PR. However, I would like to get there next time more gracefully and not feel totally wrecked at the end.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Lower Degrees of Separation with End Users]]></title>
    <link href="http://avidas.github.com/blog/2018/05/09/degrees-of-separation-with-end-users/"/>
    <updated>2018-05-09T10:21:00-04:00</updated>
    <id>http://avidas.github.com/blog/2018/05/09/degrees-of-separation-with-end-users</id>
    <content type="html"><![CDATA[<p>When working in software, one way to look at our profession is to say that we take architecture docs or designs and make code out of it. After years in the industry, we are trusted to come up with the architecture docs and work with a team to deliver the software. This absolves ourselves of responsibility in a way since even if the product fails, at least our code and systems were great. Companies today, however, are starting to see the limitations of software engineers being removed from the product decision making process.</p>

<p>I think we should reframe the problem: it is rather our responsibility as software engineers to ask, how many degrees of separation does it exist between us and the end user? Ideally, the end user would be the person paying for our service, although this gets more complicated certainly by ad funded or venture funded software. The exercise could involve us asking, what would it take to reach 10 users of our software? Would we have to go through our product manager, who then talks to the account manager or product support? These are likely the folks currently dealing with customer calls when our software bresks and waiting for the Zendesk tickets to be picked from the queue.</p>

<p>Who we are &#8220;engineering&#8221; for is a question we need to frequently ask ourselves. We should strive to be in environments where we are aware of our degree of separation and look for ways to cut down that separation. Without that frame, we can only have vague ideas of what the code we write is leading to, and end of the day limits the impact we can have.</p>

<p>It should also not always be the product manager&#8217;s job to always acting as the liason to translate user needs to us. When we are aware of user needs, it enables us to be proactive: to avoid that shortcut when building, or deal with that performance bottleneck early before it becomes a problem. We can also free the up the product manager to pursue broader goals such as product vision, market and competitive landscape analysis, etc.</p>

<p>Tomorrow, when you get to work, ask yourself that question. Do you know who your users are and how they use your product? How many degrees of separation would you have to navigate to find that answer? If you are not comfortable with the answer, maybe you can think of a way to change that.</p>

<p>Disclaimer: Thoughts expressed in the article are mine only, and does not represent the positions of current or past employers.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[NYC Marathon 2017: Training and Race Report]]></title>
    <link href="http://avidas.github.com/blog/2017/11/07/nyc-marathon-2017-race-report/"/>
    <updated>2017-11-07T09:06:00-05:00</updated>
    <id>http://avidas.github.com/blog/2017/11/07/nyc-marathon-2017-race-report</id>
    <content type="html"><![CDATA[<p>I ran the NYC marathon this Sunday. On my fourth marathon, I was going for 3:45, came off with a 3:38, personal best by 4 minutes. More than the time, a vanity metric, I was happier about the race execution, doing negative splits, avoiding cramps and bonks/hitting the wall. NYC marathon is a technical and challenging course, but I found it could reward patience and training. It was also an emotional roller coaster for me, NYC being a focal point during majority of my time in the US.</p>

<p><strong>Training</strong></p>

<p>Big part of my marathon was made during the months prior. I have ran marathons before, most recently in Feburary in Austin, so I know my body is capable of handling trials of the 26.2. But I was carrying over my adductor injury from March, and since moving to NYC, its been a slow ramp back up on the miles. Joining the Dashing Whippets in NYC was a great decision, as all my running progress can be attributed to training with groups in Austin, Austin Runner&#8217;s Club and Austin Runner&#8217;s Meetup. Post June, I had to patiently wait for my speed/endurance to catch up as I stopped running since March. Whippets are a great group, as they are both very competitive and large enough where runners of different paces can have others to run with.</p>

<p>Once summer turned into fall, I was beginning to get the mileage adaptation back up. Besides the Saturday long runs, I worked on Harlem hill repeats on Sundays and speed work with the Whippets on Thursdays. Putting those fast and hilly miles were instrumental to getting myself back into marathon shape. Alongside with Tuesday workout with the whippets, I was able to get my weekly mileage up to 55 early October, more than I&#8217;d ever done. However, at this point I had to cut back since the workload was triggering overuse injuries in calves and ankles.</p>

<p>This is what my peak weak mileage looked like</p>

<p>Saturday: 20m long run (Whippets)<br>
Sunday: 8-9m Harlem Hill repeats<br>
Monday: Rest<br>
Tuesday: 12m (Central park Whippets)<br>
Wednesday: 5m easy<br>
Thursday: 10-12m (Speed work on East Side with Whippets)<br>
Friday: Rest<br></p>

<!-- more -->


<p><strong>Nutrition</strong></p>

<p>NYC marathon has been my goal race, and I took nutrition and hydration leading to the race very seriously. Prior to race day, this involved hydrating well, drinking about 1.5 gallon of water a day. It also involved giving up alcohol for a month before the race. I remembered cramps from salt depletion in the Austin marathon, and I added salt to my food leading to race and carried salted water with me on race day. I carb loaded leading to days prior to the race except before race day when I stuck to really simple food heavier in carbs, potatoes, sweat potatoes, eggs. On race morning, I got coffee and simple carbs such as oats, apple and a bagel/banana on the route. During the race, I used 4 Cliff Gels, one every 5 miles, an approach which worked well for me in the Austin Marathon. On the race course, I alternated between water and gatorade every other mile. This helped me avoid cramps and hitting the wall during the race.</p>

<p><strong>Getting to start line</strong></p>

<p>NYC marathon is tough logistics wise, so I wanted to reduce chance of things going wrong as much as possible.  Race day is stressful, and I wanted to limit variability. Spending the night on Wall Street gave me an extra hour of sleep and less subway stress en route to the ferry. Meeting up with friends I have been training with was also good to calm down race day nerves. The ferry ride set a tone as I was feeling excited and giddy with Statue of Liberty looming large in the mist. Waiting for the buses post ferry was more of a slog, with standing long being the last thing I wanted before the marathon. Off the bus, and post Porter Potty visits, I heard the announcement of my Corral being closed in 5 minutes. 5 minutes! I ran frantically to look and find my corral. Eventually I managed to get in just in time for my wave. That left half an hour of waiting for the race.</p>

<p>I dressed warm heading to Staten Island, and this was the time to get rid of the baggage and get some warmup in my system. I love talking to runners before races. In a race like the NYC Marathon, everyone I talked to had a super interesting story.</p>

<p><strong>The race</strong></p>

<p><strong>Staten Island</strong></p>

<p>For the first time, I decided to run a marathon without a pacer, phone or watch. I put trust in that my experience of running 3 marathons and training would be enough to run by what Marathon effort should feel like. My goal was to be conservative as long as possible as a course like NYC deserves respect and a cautious approach.</p>

<p>After the short opening ceremony, we finally took off. It immediately started drizzling rain, not ideal but far from worst conditions. My spirits were pretty high, despite everything, I was running the NYC Marathon! As we ran up the Verrazano Bridge, I wished for a clearer day as the iconic view of Manhattan on top of the Verrazano was blurry in the fog. I brought my focus back to the road and the blue line markers on the road, which mark the point to point 26.2 mile during the race.</p>

<p><strong>Brooklyn</strong></p>

<p>Downhill from the Verrazano, it was steep decline but not the time to speed. I checked my pace, letting most runners pass me by. We were gradually moving down the bridge towards Brooklyn, which could only mean one thing. Crowd support!</p>

<p>And what a crowd it was! Brooklyn was my favorite part of the race. They brought music, diversity, energy and smiles. Bay ridge leading to Park Slope, Flatbush and then running through Williamsburg was an absolute riot in the best way possible. There were times when if I spread out my hands I could reach spectators on both sides. Not a problem with such a well behaved and well wishing crowd. There were bands and choirs and some great signs: &#8220;You can overcome the path once you become the path itself&#8221;.</p>

<p>NYC Marthon is a race of two halves. Most of the first half is in Brooklyn and is also some of the easier parts of the course. My goal here was to run slightly under Marathon effort, and making sure to fuel/get water along the way.</p>

<p><strong>Queens</strong></p>

<p>Finally we were at the halfway point in the race, up top the Pulaski bridge. We heard the announcement that Shalane Flannagan just won the women&#8217;s race and groups of people erupted into cheers. This set a great tone leading into Queens.</p>

<p>Queens does not get a lot of mileage but it is the lead up the most talked about part of the course, the infamous climb up the Queensboro bridge at mile 15.</p>

<p>This was a key part of the race for me. For the second half of the course, I wanted to start pushing, starting with uphills. Hence Queensboro was the acid test for how my marathon would shape up. While the ride up Queensboro was hard, I was passing people all the way which gave me a lot of confidence.</p>

<p><strong>Manhattan to Bronx</strong></p>

<p>As we ran down Queensboro, a low hum grew louder and finally erupted into cheers as we descended down Queensboro to reach Manhattan. The crowd here is boisterous and makes for a landmark moment of running this race.</p>

<p>In Manhattan, going up 1st avenue, my priority was to still run at a fairly conservative pace as there was still 10+ miles left. Getting rid of my waistbelt at mile 16 was helpful as I got rid of some weight. The latter part of 1st avenue is surprisingly hard psycologically, as crowd support fell further into the course. This was also the part of the race where goals and training for the race starts to become important.</p>

<p>Crossing the Willis bridge, we got to Bronx. I have ran this part of the course, and I was looking forward to the Whippets cheering section, which comes right at the edge of Bronx, at mile 21 as I moved my way back into Manhattan. It was at this point too that I was starting to realize not only I could break 3:45 but a PR (personal record) was possible, which brought a fresh wave of motivation.</p>

<p><strong>Back to Manhattan towards central park</strong></p>

<p>Back into Manhattan, going across fifth avenue, this is where I started to increase to full effort, knowing that with each step, the course was getting more and more into familiar terratory. Despite that, mile 23 was likely the most challenging of the whole race, a steady incline up 5th avenue on tired legs. But this also where the training mattered the most.</p>

<p>Once we entered Central park on 91st street, this was the home stretch. This is where I was really going for it, fixing my attention on one runner, catching up to them and repeating. I have ran central park enough to know the inclines and declines and with every step, it was getting closer to finish line. We were on mile 26 and at this point we left the park, run adjacent to it and finally come back. The last 400 yards were memorable, running through a painful haze but moving closer to that immaculate finish line and eventually reaching it. I knew I had PRed, I did not know by how much yet.</p>

<p><strong>Post Race thoughts</strong></p>

<p>Broadcasting to everyone how to track me on race day was motivating for me as I knew friends and family in NYC, Austin and Bangladesh would be watching. Ultimately, NYC being my goal race, I wanted to give everything I was capable of. 2017 NYC marathon was a race in which I was able to apply some of the race advice and strategies and this was the first time I&#8217;d ever hit negative splits in a race. It was really an unforgettable race, running with 50,000+ people and going through all the iconic NYC sights.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Web Payments by First Principles: Data Architecture]]></title>
    <link href="http://avidas.github.com/blog/2017/10/25/web-payments-by-first-principles-data-architecture/"/>
    <updated>2017-10-25T20:22:00-04:00</updated>
    <id>http://avidas.github.com/blog/2017/10/25/web-payments-by-first-principles-data-architecture</id>
    <content type="html"><![CDATA[<p>Once you start receiving payments on your site, congratulations! You are likely building something people want. But now you are at the point of having to manage payments data. Developers are generally aware that handling payments data should be done with care, but it is not immediately obvious what the different considerations are. In this blog post, we will go over strategies that you can follow to future proof your payments stack from the point of a fledgeling startup to a mature, stable business.</p>

<p>With storing payments data, there are quite a few considerations. What you should store and shouldn’t. In the event of a security breach on your site, you want your users financial information to be protected. Moreover, you want to architect your data storage for any current and future stakeholder requests. When it comes to payments, there are generally many stakeholders, let’s talk about a handful of them.</p>

<p>You are going to have technical stakeholders: your managers and other product teams who have questions about payments. Business entities that have to report their earnings for filing taxes and reporting earnings to shareholders who will need their data from you. As someone buying/selling online, your data needs to be stored in a way to make sure you don’t break compliance (PCI/SOX etc). Support/operations will be your stakeholders when customers have problems paying and come to you for help. Let’s get into how we can address these asks.</p>

<ol>
<li><p><strong>Avoid storing sensitive personal information</strong>: Any application sending payments information such as credit card numbers, cvv to their server will have to become PCI compliant. This a financial and logistics burden which you can avoid for the most part by using a gateway provider such as Braintree/Stripe/Adyen. Usually your browser/mobile app will authenticate with the gateway and get back a token, which you can relay back to your server. This removes the danger of accidentally logging payments data, since the only data your server will see is a payments token. Even if you do get data breached, these tokens would not be useful to the attacker. This also removes the need for you to be PCI compliant which is tens of thousands of dollars in yearly expenses.  More data you should avoid storing include any plaintext passwords and secret keys, common web best practices.</p></li>
<li><p><strong>Freeze request/response from external providers</strong>: You need to store every single request/response that you are making to your external providers, ideally in an append-only data storage. One of the common requests that we get in payments is to recreate the transaction as it happened. This is hard to do without storing the data at point in time of the transaction. Moreover, the business logic related to transaction such as taxes, fees calculations also need to be versioned and stored so that you can recreate the transaction at a certain point in time.</p></li>
<li><p><strong>Encourage immutability and lower side effects</strong>: Similar to the point above, you should never destroy payments or charging data. There are easy ways to archive and hide the data from users. This is very useful for historical financial reporting, triaging potential inefficiencies in your charging/billing process, and dealing with any disputes with your payments provider.</p></li>
<li><p><strong>Denormalize and index for searchability</strong>: Payments data is generally more write heavy but needs to be stored in a way for ease of triaging. Most payments providers provide unique request ids with their calls, and you should supply your own if that is possible. That way, you can set up bidirectional tracking, so that each individual call to payments is trackable from both sides. Setting indices on those unique ids is helpful for search. If the table is growing too large, it is useful to only keep upto a certain limit in your app and store the rest in a data warehouse such as AWS Redshift or Google Bigquery. The data warehouse strategy also enables you to normalize the data if you want easier access to data in one place and avoid expensive joins.</p></li>
<li><p><strong>Prefer cents as units instead of dollars</strong>: You can avoid a whole class of floating point bugs by storing in cents and using integers as opposed to float for all your arithmetic. Since floats in computing are really a representation of an infinite number, the can only be approximation and lead to hideous rounding errors. This is a good read on that topic https://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency. Using established tools such as the money gem for currency in ruby is also very useful.</p></li>
</ol>


<p>The above strategies will be useful for both internal and external users of your payments stack and help to protect your money and time when it comes to payments data. Please reach out via comments or <a href="mailto:avi@aviadas.com">email with feedback!</a>.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Web Payments by First Principles: Testing]]></title>
    <link href="http://avidas.github.com/blog/2017/05/19/web-payments-by-first-principles-testing/"/>
    <updated>2017-05-19T16:21:00-04:00</updated>
    <id>http://avidas.github.com/blog/2017/05/19/web-payments-by-first-principles-testing</id>
    <content type="html"><![CDATA[<p>In recent years, payment API providers have made integrating payments much easier than it used to be. Instead of dealing with banks and exchanges, ecommerce apps can integrate with payment gateways that will allow accepting any form of credit cards, and most payment methods such as Apple Pay and PayPal. Large pdfs with instructions manuals are replaced by intelligent documentation sites with walkthroughs and tutorials. Despite that, it is not uncommon to hear developers referring payments as their least favorite part of the development process. Payments integrations are often seen as a necessary evil, to be done once, and hopefully be forgotten thereafter. Often the reasoning is that investing in better payments integration is often not a profit center for companies.</p>

<p>I have worked the last few years in the online payments industry, building APIS, sdks and reliability tools. While payments integration has gotten easier, developers still do make mistakes which are easily avoidable. Here are some of the best practices I would recommend for testing payments in your applications.</p>

<ol>
<li><p><strong>Isolate interation between application code and payment gateway in a package</strong>: Once an app grows to a certain size, it may have different ways of interacting with payments gateways. You may be accepting recurring payments and accepting webhooks from the payments provider, just in time checkout or interact with point of sales systems. Having your own package that abstracts out interaction with the payments APIs can help centralize all outgoing requests back and forth with the payments API. You can add your own logging and monitoring, stub out the interaction with payments API to have faster unit tests and centralize knowledge about how you serialize and deserialize messages from and to your payments provider.</p></li>
<li><p><strong>Sandbox Testing</strong>: Most payment API/gateways expose a sandbox environments where you can test out a real integration with the API without moving any money. Ideally your integration tests running continously in Jenkins/Travis/Circle CI should be hitting those endpoints.</p></li>
<li><p><strong>Monitoring</strong>: You should monitor your sandbox integration as well as your live system. What does the graph of 200s vs 400s HTTP response codes from the payments API look like? Are you getting unexpected 400s? How about 500s? What does the response times look like?</p></li>
<li><p><strong>Automated QA</strong>: To avoid putting undue stress on your computation and database resources, background tasks are common strategies to do break down calculations for common payments needs such as reporting and analytics. When calculations are done in partial chunks, automated jobs that test whether those calculations have been done properly can reduce a lot of load for your support and developers when something goes wrong midway between a job, or failure.</p></li>
<li><p><strong>Negative/Failure Testing</strong>: Special card numbers provided by payments providers can help you recreate payment declines due to potential denial from processors for reasons such as not enough funds in account. You may also be able to test for rejections due to fraud and compliance. This helps lower the range of potential unknown errors your site may run into, especially when expanding to new markets or accepting more payment methods.</p></li>
<li><p><strong>Live testing</strong>: Live testing against payment providers is often tricky, and can led to accounts getting shut down if there is undue load on the API. Despite that, some testing in live is absolutely necessary before you can be confident that on release day, your integration is working as expected.</p></li>
<li><p><strong>Test for absence of sentive information</strong>: Storing user information such as credit card number or passwords is a very common way of violation of PCI compliance. Regex patterns can be used to make sure that neither your logs nor your database is storing sensitive information.</p></li>
</ol>


<p>I intend to write more posts in this series, covering topics such as considerations before and after going live with payments, when scaling up and so on. If you liked this post, please share or comment.</p>

<p>If you have feedback on this blog post or integrating payments, please <a href="mailto:avi@aviadas.com">feel free to reach out!</a>.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Takeaways from MicroConf Starter 2017]]></title>
    <link href="http://avidas.github.com/blog/2017/04/21/takeaways-from-microconf-starter-2017/"/>
    <updated>2017-04-21T17:55:00-04:00</updated>
    <id>http://avidas.github.com/blog/2017/04/21/takeaways-from-microconf-starter-2017</id>
    <content type="html"><![CDATA[<p>With the rise in VC funded startups, there was not a big community for individuals and small teams launching and supporting digital product businesses with their own profits. Rob Walling and Mike Taber noticed that need and created MicroConf, a conference for self-funded software startups.</p>

<p>I was at MicroConf Starter last week. In its 12th year, MicroConf split into Starter and Growth Tiers, the starter edition for people who do not make a full time income from digital products. If you are the kind of person who enjoys taking an idea to a functional product that solves real world problems, MicroConf is a conference where everyone has that shared goal.</p>

<p>Some at MicroConf have launched products and were doing quite well from a digital product business, let it be online courses, software plugins, SAAS etc. There were also number of people who wanted to learn more about find the right idea, product-market fit, sales and marketing.</p>

<p>I really enjoyed the pragmatic voice of the conference, keeping focus on balance. The conference does not shy away from the fact that it is not a easy task to bootstrap software products.</p>

<p><a href="https://shai.io/MicroConf/">MicroConf has great notes</a> for the whole conference. Instead of trying to go through the whole conference, here are some of my takeaways from MicroConf Starter 2017.</p>

<ol>
<li><p><strong>Consistency</strong>: Rob Walling emphasized start of the conference that the success of MicroConf will be what these two days can do for the remaining 363 days of the year. Often consistency made the difference in the eventual endurance and success of the product. Josh Doddy&#8217;s blog was fairly dormant for the first 12-14 months but peaking exponentially near its current runtime of 18 months. Mastermind groups were mentioned as a great way for a group of people who help each other stay on track.</p></li>
<li><p><strong>Finding an idea worth building</strong>: Multiple speakers mentioned the need to take a hard look at your stocks and assets. What questions do people keep asking you? What are you passionate about that other people find boring? What would you from 6 months ago find valuable? All these were from Ben Orenstein&#8217;s talk, one of my favorite at the conference. Patrick Mckenzie also touched on the same topic, to double down on what you do very well already and what the market already buys from you. Justin Jackson mentioned the need to find the groups you are best equipped to serve, and to research the audience and find ideas rather than thinking in your own head what the problem could be. Mike Taber also emphasized focusing if you are in fact the right person to be building that product.</p></li>
<li><p><strong>When to launch</strong>: An MVP should solve a well defined problem, not solve a portion of it or solve every possible iteration of the problem. However, the lack of polish is intentional to see how much inconvenience the customers would endure to solve their problem. Justin Jackson had a great point that an MVP should be the smallest product you could build to disprove a hypothesis. It was interesting to see multiple speakers mentioning the importance of putting your face right by your product, to encourage trust and take responsibility of what you are delivering.</p></li>
<li><p><strong>On user acquisition</strong>: Probably the biggest concern of fledgling products, user acquisition/outreach had dedicated talks. Some of the key points where to focus on conversations with users and doubling down on a few approaches e.g. SEO, Content, Ads rather than throwing in the kitchen sink. Looking for integrations with other products by forming partnerships was a common theme. Key questions to ask users were to ask how they were solving the problem today, what they have tried or ask for introductions to someone with that problem. In the beginning, unscalable strategies such as concierge onboarding are useful, specially for SAAS products.</p></li>
<li><p><strong>Getting results</strong>: Users are the best signals here, and if you have to chase people down to use your products, it may not be solving a real problem. Google analytics charts showing growth and conversion rates were part of almost every presentation. At the same time, reading those charts can be a hard story, often showing charts recovering from a flatline or decline to eventual success because the founders believed enough to carry on. Its hard to think convictions to be infallible in the face of data however, and sometimes it is time to give up.</p></li>
</ol>


<!-- more -->


<ol>
<li><p><strong>Pricing and revenue</strong>: Patrick Mckenzie mentioned that the objective to be a predictable sales process to make profit every month. The question of how much to charge for the product is tricky for founders. Both him, Ben and Jordan Gal emphasized the need for running experiments on your pricing page. Surprisingly enough, an increase in prices may often result in better customers in the long run even though in the short term your trials may fall.</p></li>
<li><p><strong>Motivation</strong>: People are motivated differently, but momentum is a key driver. Ben mentioned the need to reverse the relationship, not to wait for inspiration but to get started, feel the success and then get inspired. Sherry Walling mentioned using positive stress to fuel motivation. Lot of the folks in the conference started when they already had a lot of responsibilities, but often it is not time that is lacking, but the prioritization. Making more time is a function of reorganizing your priorities. Delegation is another important tool to master, especially for adjacent responsibilities to the key goals.</p></li>
<li><p><strong>Success and Failure</strong>: Jordan Gal had a great point that success is the ability to go from one failure to another without loss of enthusiasm. But success is quite subjective, and often reinforced by societies expectations. Perhaps it is worth asking if you are helping people solve problems. Failure is often more interesting part of the conference, to see what these speakers have tried but stopped when they did not deliver the results.</p></li>
<li><p><strong>Maintaining balance</strong>: Almost every speaker mentioned the need to for maintaining the balance in your life, relationships and family. Sherry Walling&#8217;s talk was dedicated to this, pointing out the need for self reflection and care. Taking retreats to step away from the grind is valuable, giving time to ask the important questions. Questions such as what pieces of day to day life is infusing you with energy? How can I readjust priorities so that I can live in those sweet spots more and do less of what is causing stress? The other really important point was about feedback loops, getting advice, forming mastermind groups and making sure that there are others weighing on important decisions</p></li>
</ol>


<p>Overall, I loved the theme and people at Micronconf. It was a blend of driven, helpful people interested in solving problems and owning software products. I would highly recommend the conference for anyone looking to launch products and interested in bootstrapping.</p>

<p>If you have feedback on this blog post or MicroConf, please <a href="mailto:avi@aviadas.com">feel free to reach out!</a>.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[What makes a great programming tutorial?]]></title>
    <link href="http://avidas.github.com/blog/2016/04/18/what-makes-a-great-online-tutorial/"/>
    <updated>2016-04-18T05:36:00-04:00</updated>
    <id>http://avidas.github.com/blog/2016/04/18/what-makes-a-great-online-tutorial</id>
    <content type="html"><![CDATA[<p>The Internet started as a publishing medium. It excels at enabling people to share their unique gifts. An amazing amount of content gets put out on the web everyday, far beyond someone can read in a lifetime. Massive amount of information also means information overload.</p>

<p>In software, it is common to use web tutorials to supplement one&#8217;s learning of a particular material. Following guidelines of someone who has already done it can really fast track development. Tutorials appear in various forms in the web. Some of the common formats are long form blogposts, videos and series of email newsletters. Some enjoy the personal touch that videos can offer; others enjoy being able to quickly skim a blogpost.</p>

<p>When you want to put your hard earned knowledge and valuable time into writing a tutorial, there are questions worth thinking about. Does the tutorial cater to its intended audience? Will it reach them? Can someone quickly skim the content and still get value? Is there a way to measure the effectiveness of online tutorials?</p>

<p><img class="left" src="https://files.slack.com/files-pri/T025F19MZ-F1ASWBLV8/pasted_image_at_2016_05_22_04_58_pm.png" width="800" height="800" title="Survey Questions" alt="Survey Questions"></p>

<p>To look for answers, I asked a carefully selected group of 150 people about their preference of tutorials. The focus was on software engineers/designers/entrepreneurs due to my familiarity and experience with the field. What emerged from their responses gives a blueprint for creating great online resources.</p>

<ol>
<li><p><strong>Real time feedback</strong>: If exercises or examples accompany a tutorial, multiple survey responders emphasized the need to check the user&#8217;s responses and provide interactive feedback to the user to guide them to the solution. Good examples are checkpoint multiple choice questions during Coursera/Udacity courses that you must complete to move forward with the course.</p></li>
<li><p><strong>Follow up</strong>: Several responders emphasized the need to provide contact information or other means to reach out to the author once they went through a tutorial. Providing a comments section or your email/twitter handle are great mediums for a reader to follow up.</p></li>
<li><p><strong>Address a concrete problem</strong>: Staying focused of a specific problem gives a tutorial depth. A differentiator can be to classify for the user whether the focus is academic and structured vs. a blogpost focused on solving a particular problem right now.</p></li>
<li><p><strong>Working examples</strong>: Interactive, working examples close to the content that builds on top of each other makes following along simpler. <a href="https://www.railstutorial.org/">Michael Hartl&#8217;s Ruby on Rails tutorials</a> came up as an example of detailed, comprehensive tutorials.</p></li>
<li><p><strong>Advanced user tutorials</strong>: Several user&#8217;s pointed out the need for tutorials that addresses advanced content. Making expectations clear about experience levels of intended audiences can be a huge positive for tutorials. <a href="https://www.raywenderlich.com/video-tutorials">Ray Wenderlich&#8217;s iOS tutorials</a> are good examples of the detail and level of research and understanding that can happen before putting out content on the web.</p></li>
</ol>


<!-- more -->


<ol>
<li><p><strong>Copyright</strong>: Sometimes an afterthought, it may be worth pointing out what license the content is released under. This can give the reader’s clarity on how to attribute the source when they use that content in production. Github makes this really easy with license options provided  during repository creation.</p></li>
<li><p><strong>Offer tangible short-term benefits</strong>: While this certainly applies more to blogposts rather than courses, focusing on offering user&#8217;s value short, medium and long term can improve the message of a tutorial. Moreover, an user may be more inclined to follow through the entire content of a tutorial if they are get that value at different stages of the tutorial.</p></li>
<li><p><strong>Timeliness</strong>: This could be hard to measure, but popularity of tutorials can be attributed to how current and relevant they are. As of the time of writing this blogpost, April 2016, there are lot of people looking to get into VR/AR, chatbots, AI and so on. Accounting for recency can certainly increase the reader counts of your posts.</p></li>
<li><p><strong>Continuity</strong>: It became clear through the responses that while people looked for tutorials to solve a particular problem, they return because they are looking for a subject matter expert. Producing a series of tutorials taking on different aspects of a topic can help with retention.</p></li>
<li><p><strong>Discoverability</strong>: This can go in the realms of SEO, but lot of responders responded to their favorite source of online tutorials with well-known sources. Coursera/Udemy/Khan Academy/YouTube and Google were all common ways people went around in finding online tutorials. If you do not want to solve distribution for the content you create, writing for more known blogs/sites can be a way to reach larger audiences.</p></li>
<li><p><strong>Formatting</strong>: A big part of the user experience, proofreading cannot be left for the last. In the tech space, prominent writers such as Paul Graham always attribute at the end of the blogpost all those who have helped proofread the content. Just passing it around to a few people before publication and basic spell checking/grammar checking can improve the user experience for tutorials.</p></li>
</ol>


<p>There are definitely caveats to this survey. As the person compiling this survey, it is at least slightly influenced by my biases. My target group is highly technically literate, so there is a bias towards modern tools. Perhaps it is worth taking into account the intent of writing tutorials, be it teaching, lead generation or growing a business.</p>

<p>Like most studies, this too should be taken with a grain of salt and in no way is sure way to produce great tutorials. Someone&#8217;s genuine passion, interest and the willingness to learn and teach find their ways to shine through content. However, just as the <a href="http://www.joelonsoftware.com/articles/fog0000000043.html">Joel Test for Software Development</a> companies is often a good checklist for expected standards of software companies, being aware of the reader’s needs and voice can lead to sharper, more helpful tutorials.</p>

<p>Research for this post was done by using Dripper, a twitter direct message automation tool that I helped build. Feel free to <a href="mailto:avi@aviadas.com">reach out</a> if you want to know more about the software!</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[10 things I learnt going from 10k to a Marathon in 2015]]></title>
    <link href="http://avidas.github.com/blog/2016/02/09/10-things-i-learnt-going-from-10k-to-a-marathon-in-2015/"/>
    <updated>2016-02-09T23:28:00-05:00</updated>
    <id>http://avidas.github.com/blog/2016/02/09/10-things-i-learnt-going-from-10k-to-a-marathon-in-2015</id>
    <content type="html"><![CDATA[<p>If I were to think about running a 26.2 mile race at the start of 2015, the overwhelming feeling would be one of fear. I have only ever ran a 10k before and just signed up for the Austin 2015 half Marathon, my first ever half. The prospect of running twice the distance still seemed far away though. Flash forward to October 18th 2015, I finished my first Marathon with a 3:49:00 time. As I look back on this year, I wanted to put together some of my realizations during the whole process. </p>

<ol>
<li><p><strong>Running is a privilege</strong>:
Living somewhere where I can run safely, have trails to run on, be in good health to run are all privileges to be thankful for. Growing up in the developing world meant that it was hard pressed to find opportunities to be involved in outdoor activites. Having the time and space to exercise is a luxury that needed to be earned. I never ran in high school, and by the time I graduated college I could not run longer than 5k. Having the time to run, being in US where running is very much part of the culture has been a huge contributor to my running progress.</p></li>
<li><p><strong>Joining a running group is one of the best decisions you can make as a beginning runner</strong>:
Training with people better than you to improve is not unique to running. Start of 2015, I had no plans of running a marathon. In April, I joined the Austin Runners Meetup (ARM). In training long runs with ARM, I was able to build up the endurance for longer runs which made the progression to a Marathon much easier mentally. Training with other runners can definitely help you maintain the habit of running as well as improve your form and performance. Moreover, I found a new community of great people which has been very rewarding.</p></li>
<li><p><strong>Tying running with other activities you enjoy can make running much more consistent</strong>:
In Charles Duhigg&#8217;s <a href="http://www.amazon.com/The-Power-Habit-What-Business/dp/081298160X">Power of Habit</a>, he talks about the cue-action-reward pattern that most habits follow. Being aware of that pattern can help in building running as a habit. When run&#8217;s are followed by a delicious breakfast, you have something to look forward to. Trance music and podcasts help me maintain the flow during running. Travel is one of my favorite things and going to a new city for a race is something I eagerly look forward to.</p></li>
<li><p><strong>Running is a blissful release from life&#8217;s distractions</strong>:</p>

<blockquote><p>“All I do is keep on running in my own cozy, homemade void, my own nostalgic silence. And this is a pretty wonderful thing.” 
― Haruki Murakami, What I Talk About When I Talk About Running&#8220;`</p></blockquote>

<p> Distractions are part and parcel of our lives as more form factors emerge competing for our limited attention span. Often, this results in us not being aware of the passage of time. Running has been a great antidote to that problem for me. When running is effortful, you have to concentrate on the activity at hand and your entire focus is on the present moment. Long runs offer the prospect of seeing places and neighborhoods that you would not frequent otherwise. A slight breeze on a scorching summer&#8217;s day has never been more enjoyable.</p></li>
<li><p><strong>Once running is a habit, a chore becomes a craving</strong>:
When you start out running, it can be something you dread on your calendar. There is really no way to get past this without sustained practice, lowering the cognitive load with group associations and reward mechanisms. If you continue though, you realize at one point that you start craving the runs. Don&#8217;t get me wrong, it still requires a lot of mental effort to get up at 5:30am for that 20 mile run you need to do for Marathon training. But something about the combination of endorphins, habits built during running and seeing your friends out there on the trail can change running into something that you look forward to.</p></li>
</ol>


<!-- more -->


<ol>
<li><p><strong>You only compete against your past self</strong>:
This can vary a lot based on personality, but being slower than a lot of other runners has never really bothered me that much. As long as I beat my previous PR by two seconds, I would be happy. Running as an activity has been such a positive change for my life that the gratification from being faster than others has not been necessary at all. Lot of people starting out running also worry about their pace. However, beginner runners should actually run slower than the pace they think they can run at to avoid injury and build up distance and time.</p></li>
<li><p><strong>Respect your body&#8217;s adjustment mechanisms</strong>:
One of my foremost running philosophies is to avoid injury. Running is a full body exercise. Your heart, muscles, ligaments and joints all need adjust to the increased level of physical activity. In the beginning, you run out of breath since your heart is simply not used to pumping out the necessary amount of oxygen to the muscles. However, it can adjust remarkably fast, and you may be tempted to run faster than you should. Getting past muscle cramps is often the next step. Your joints likely will be the last to adjust though, and care should be taken to not run too fast too soon to avoid injury.</p></li>
<li><p><strong>Hard things are often the most rewarding</strong>:
If a Marathon was easy, the feeling of achievement would be less profound. You will be in pain after finishing a Marathon. However, if there is any time when pain feels besides the point, this is it. Finishing a Marathon feels good in a way that is hard to find a parallel in our day to day life. Rather you feel as accomplished as a battle commander from the middle ages after winning a long and arduous war.</p></li>
<li><p><strong>It will affect you positively in ways you may not expect</strong>:
When I talk to people about running, I consistently discover new and positive impacts running has had on their lives. For some people if is therapeutic and a great way to cope against troubles in life. It stands out as one of the activities that can have an <a href="https://en.wikipedia.org/wiki/Pareto_principle">80/20 impact</a> on your life, since the improvement in concentration and physical ability that you gain from running regularly can help in most other areas of life.</p></li>
<li><p><strong>It gives you the satisfaction of reaching your goals and finishing</strong>:
There are lot of things in life that can drag on, get pushed on and not have a clear resolution. Life is rarely black or white. Running is often a refreshing break from all that. Once you finish a race, it is done and over with, offering the joy of finishing something. Moreover, looking forward and planning for the race can become an exciting activity, as you look to vindicate your hard hours of training.</p></li>
</ol>


<p>Running is ultimately a very solitary activity. It does not matter if you train with a group, you are going to be on your own for long periods of time. This makes everyone&#8217;s running journey very personaI. If you are starting out running in 2016 or have certain training goals, I wish you all the best. If you have already been running races, I hope there was still something useful in this post for you. Either way, feel free to reach out or leave a note. I would love to hear from you.</p>
]]></content>
  </entry>
  
</feed>