Avi Das

Home for my code, thoughts and else.

Life Lessons From Improv

I think life should be more like improv and improv should resemble life.

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.

  1. Yes, and..: 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’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.

  2. Go with the first thing that comes to mind: 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.

  3. Embracing failure: Making a fool of yourself is encouraged and celebrated in improv. The very act of complete unpreparedness on stage, taking the audience’s suggestion to theme a scene and strangers as partners means that you don’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.

  4. Make others look good: 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.

  5. Make statements, don’t ask questions: 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’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.

Thoughts on Button Push Driven Development

I was in a conversation the other day when someone mentioned

“We may only be a couple Moore’s Law iterations away from all software built by pushing buttons and WYSIWYG editors.”

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.

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’t have to hypothesize. We can build it.

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.

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.

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 very minimal context switching. When writing an app for Alexa, it feels driven by context switching.

Books I Read in 2018

General/Personal Development

  1. The art of living (Thich nhat hanh): This is the best Thich nhat hanh I’ve read, composing his philosophy on living an examined life into day to day practices.
  2. Thinking in systems, a primer (Donella Meadows): Really, really smart author, systems thinking should be a required course in college.
  3. Ain’t I a Woman: Black Women and Feminism (Bell Hooks): Challenges a lot of assumptions, covering black woman’s involvement with race identity and feminism.
  4. When: The Scientific Secrets of Perfect Timing (Daniel Pink): Dan Pink’s books are similar to Malcolm Gladwell’s, distilling behavioral psychology research into easy reads.
  5. The Essential Rumi (Jalal Al-Din Rumi): Lately I have started admiring how much Poetry can accomplish with so few words. There is something very calming about reading Rumi.
  6. Sex at dawn (Christopher Ryan‎, Cacilda Jethá): An incendiary/challenging investigation into human/primate sexuality, sweeping across history to construct the narrative, much like Sapiens by Yuval Noah Harari.
  7. Deep work (Cal Newport): So good, anyone doing knowledge/creative work would be benefited by this classic.
  8. The life changing Manga of Tidying Up (Marie Kondo): 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.
  9. Flow: The Psychology of Optimal Experience (Mihaly Csikszentmihalyi): 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.
  10. Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead (Brene Brown)
  11. So good they can’t ignore you (Cal Newport): Much like deep work, essential reading for those looking to improve their craft.
  12. How to change your mind (Michael Pollan): Eye-opening, challenging look at the resurgence of Psychedelics in mental health research.
  13. A life in parts (Bryan Cranston)

Core Tenants of Highly Effective Software Teams

This blogpost is my thoughts only and does not necessarily represent the positions of current or past employers.

We don’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.

  1. Believing in a common cause: 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.

    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.

  2. Psychological Safety: Google’s Project Aristotle 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’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.

    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.

  3. Diversity of Thought: 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.

    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.

    Finally, cross functional teams can be more effective than teams exclusively focusing on frontend/backend/mobile. Recognizing the individual contributor’s interest in user experience/security/governance etc and enabling space for that one of the most enabling things an engineer leader can do.

  4. Growth and Ownership: 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.

    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.

    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’s belief in their people, sending them to conferences, training and giving license for creativity.

  5. Work Environment: 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.

    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.

When things fall apart

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.

Jersey Half Marathon 2018: Race Report

“Gatoradeee!! Water!” 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.

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.

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.

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.

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.

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.

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.

Lower Degrees of Separation With End Users

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.

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.

Who we are “engineering” 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.

It should also not always be the product manager’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.

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.

Disclaimer: Thoughts expressed in the article are mine only, and does not represent the positions of current or past employers.

NYC Marathon 2017: Training and Race Report

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.

Training

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’s Club and Austin Runner’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.

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’d ever done. However, at this point I had to cut back since the workload was triggering overuse injuries in calves and ankles.

This is what my peak weak mileage looked like

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