her life shrinks or expands in proportion to her courage

Dear Reader,

The title of this blog is a modified version of a quote by American author, Anais Nin. I've modified it and adapted it to she/her/her as I feel recent events aptly express how I feel about my interactions and experience with a certain individual.

A colleague of mine at work passed away due a critical illness. She was battling a critical illness for a long time and when it appeared that she is getting back to normal, I got the sad news that she is no more. She was also my first female boss/supervisor/manager. I've worked with her for close to two years and directly reported to her. My prayers are with her family, friends and close ones. It will be a great loss to the family, organization, the community and women in technology.

courage -  the ability/quality/spirit to do something that you know is difficult or that frightens one; strength in the face of pain or grief.

I dedicate this blog to her courage. Not just when battling an illness but throughout her work and interactions with others. That is my biggest learning from her. And a trait that every woman in technology should inculcate. I can say without doubt that her life expanded in proportion to her courage.

Courage comes in many forms and is demonstrated in many ways. Courage to do the right thing, courage to fight for what is right, courage to do something knowing the risks, courage under fire, courage to believe in someone, courage to trust someone, courage to say what  needs to be said, courage to go on stage and shine in the limelight, courage to get things right when everyone is watching you, courage to tell the truth, and so many many more.

When I look back at certain events in my own life, I can definitely attribute some of the high moments when I demonstrated courage. However, this blog is not about me.

This blog is also not about my colleague. This blog is a shout out to all those courageous women in technology... to all those women waiting to make their mark - that - the one trait that you must have is courage.

And don't waste time ranting about how courageous you where in the past. Most people don't care. It is your personal high and your personal win. Just like my colleague, who went about displaying courage in so many ways but never talked about it. Even when courageously battling an illness, whenever she interacted with us, it just seemed like she was with us in that moment - doing what needs to be done.

Courage - Edgar A. Guest

Courage isn’t a brilliant dash,

A daring deed in a moment’s flash;

It isn’t an instantaneous thing

Born of despair with a sudden spring

It isn’t a creature of flickered hope

Or the final tug at a slipping rope;

But it’s something deep in the soul of woman

That is working always to serve some plan.

Courage isn’t the last resort

In the work of life or the game of sport;

It isn’t a thing that a woman can call

At some future time when she’s apt to fall;

If she hasn’t it now, she will have it not

When the strain is great and the pace is hot.

For who would strive for a distant goal

Must always have courage within her soul.

Courage isn’t a dazzling light

That flashes and passes away from sight;

It’s a slow, unwavering, ingrained trait

With the patience to work and the strength to wait.

It’s part of a woman when her skies are blue,

It’s part of her when she has work to do.

The brave woman never is freed of it.

She has it when there is no need of it.

Courage was never designed for show;

It isn’t a thing that can come and go;

It’s written in victory and defeat

And every trial a woman may meet.

It’s part of her hours, her days and her years,

Back of her smiles and behind her tears.

Courage is more than a daring deed:

It’s the breath of life and a strong woman's creed.

RIP

Thanks for reading.

Jyothin

Why You Should Write...

Dear Reader,

Do you have a therapeutic hobby? Something that you do when you are stressed or to get a change in mindset? Mine is writing. It takes me a good 3-4 hours to write a nice piece including all the research and fact finding that goes into the it.

While I don't have dreams of being a rich and famous author, research has shown that there are many emotional and physical health benefits to be gained through expressive writing. No matter what medium you choose—whether it be a public blog or a private journal—there’s a lot to be gained by getting your thoughts and emotions onto the page.

A study from the University of Texas at Austin found that people who write about personal details are healthier than those who don’t. The study, published in the Journal of Clinical Psychology, asked groups of students to write about an assigned topic for 15 minutes a day for four consecutive days. Later in the year, the pair asked the students about their health and found that those who had written about emotional topics made fewer trips to their doctors’ offices.

Similar studies have found that those who practiced expressive writing reported lower blood pressure, fewer days in the hospital, improved immune system function, and overall improved mood. One study found that patients suffering from rheumatoid arthritis and asthma experienced fewer symptoms after writing about stressful life events.

Writing about stressful situations may seem counter-intuitive—wouldn’t it induce stress, not relieve it? Getting negative and stressful feelings out actually helps reduce their intensity. It can also help you figure out exactly why you’re anxious, which could lead to a solution. Writing removes any mental blocks you may have, and enables you to use all of your brainpower to find answers. Another benefit of writing about stressful experiences is that you can go back and look at previous entries to see how much you’ve progressed.

In addition, writing about people you know can not only help you understand the nature of your relationship with them, but understand them better as well. If you’re angry with someone, you may want to write them a letter. Even if you never intend on sending it, simply writing out your feelings and explaining why you feel the way you do can reduce your anger towards them.

But writing does not necessarily have to be expressive. I worked at a large e-commerce technology organization that did a great job in utilizing the benefits of writing. Status, reports, updates, product launches, press releases, etc. were all formally written and documented. There were 1-pagers, 3-pagers, 6-pagers and even 12-pagers. All with an emphasis on using writing as a way to get the facts right, commit to what you write, provide sufficient detail to what you write and express yourself and do justice to the topic itself. Of course, none of these pager documents were evaluated for the writing itself but more for the purpose of documenting the content.

More and more techies are losing this important skill. And honestly, it is getting harder to convince techies that they need to write, even if it is a technical whitepaper or patent. The general notion is that the marketing team or the patent team will take care of the actual writing and the techie just needs to provide the technical information. I don't completely agree to that notion. Moreover, I've seen some techies take a turn to writing when they see the benefits of a well written technical document. So, there is definitely an advantage to writing even in technology where most people spend time writing code.

You don’t have to write a Shakespearean sonnet or a Dickensian novel to reap the benefits of expressive writing. Keep in mind that when writing as a therapeutic hobby, the end result isn’t the important part—the process is. Try to write for at least 20 minutes a day to make the most of the experience. You don’t even have to adhere to the rules of grammar if you don’t want to. All that matters is that you get your thoughts down on paper. The best way to get started is to jump right in, and write now!

I think everyone should have a therapeutic hobby. Something that is personal to them, protected by them, cherished, and something that helps them get back into the regular grind.

Until next time. Keep writing.

Jyothin

PS: Most of the information in this blog has been picked up from another article titled 'Your Therapeutic Hobby: Writing'

PS: You just got juxtaposed!

Another feather in the hat...

Phew... took a while to get ready to take the exam!!

agile: (adjective) able to move quickly and easily.

... and there you have the official definition of Agile(1).

Similar: nimble, lithe, spry, supple, limber, sprightly, dexterous, deft, willowy, graceful, light-footed, fleet-footed, active, lively, quick-moving, nippy, twinkle-toed, fleet, lightsome, alert, sharp, acute, clever, shrewd, astute, on the ball

Opposite: clumsy, stiff, slow, dull

... and in the software world,

"relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans."

Welcome back.

I recently came upon a online article on Scenario-Focused Engineering: Take an Experimental Approach which has an interested snippet on Agile. Copy-Pasted below verbatim.

Agile was born from the software developer community in response to the need to build higher-quality software with less wasted effort in an environment in which precise customer requirements change over time and are hard to articulate upfront(1). Agile was invented independently by software engineers, but fascinatingly, it aimed to solve a lot of the same root problems that user-centered design aimed to tackle.

If you’re working on an Agile team, a lot of this chapter probably feels familiar. You already loop quickly in sprints, likely somewhere from one to four weeks in length. It’s easy to squint and see how one loop around the Fast Feedback Cycle could map to an Agile sprint, complete with a customer touch point at the end to get direct customer feedback on the increment you just delivered. It’s likely that some of the same activities we discussed already occur during the course of your sprints.

Scenario-Focused Engineering differs from Agile in two main areas, which we believe help fill in some missing gaps. First, we believe that it’s not necessary for every sprint to deliver shippable code(2). In early sprints, it’s often more efficient to get customer feedback on a sketch, mockup, or prototype before investing in production code. However, we completely agree that getting customer feedback at the end of every sprint is absolutely essential, whether that sprint built prototypes or production code.

Second, we believe that the product owner is actually a mythical creature. We challenge the idea that any one person on the team, no matter how senior, no matter how often they talk with customers, can accurately channel exactly what real customers need and desire and provide accurate “customer” feedback at the end of a sprint. Agile oversimplified the whole business of understanding customers by giving that job to one person—the product owner(2). Anything beyond the most basic customer needs are too complex for that approach to work reliably in today’s market. We hope you’ll find that the ideas in this book give you practical ways to break out of that mold and actually talk to real customers(3).

Interestingly, most Agilists have concluded that shorter sprints work better than longer ones: sprints of one to two weeks are better than sprints of three to four weeks. We have come to a similar conclusion; you should probably aim to finish a single cycle within two weeks(3). Left to their own devices, most teams will spend too long on an iteration. Time boxing is key to keep people moving, and Agile sprints are a really natural way to time box on a software project.

Here are a couple of things that I agree and disagree in the above paragraphs,

Agree -

1. move quickly & easily - that is the crux of Agile. If Agile does not allow a team to be nimble and dextrous then it is not helping. This certainly does not mean individual team members are themselves fast which is a common misconception that most sr. leaders have. The movement is never within a sprint. It is always at the boundary of a sprint.
2. It is really not necessary for a team to deliver shippable code every sprint. This is another common misconception that most sr. leaders and especially product managers have that if you are not shipping code at the end of the sprint then you are not delivering anything worthwhile and hence have not done ANY work. Software development is a thought process even the 'Build' stage of the Fast Feedback Cycle, can be broken into 'Design', 'Development', 'Test', 'QA', 'Deploy', etc. which is a much longer and involved process.
3. Two weeks is the sweet spot for a sprint. I've worked with teams have have 4 week sprints and also with teams that have 1 week sprints. In neither of them did I see an improvement in meeting sprint goals. In many organizations, this is usually left to the team and I completely support that. Some teams work well in 4 week sprints and some in 1 week sprints. At the end of the day, is the team delivering an incremental change in the product.

Disagree -

1. If customer requirements are hard to articulate upfront, to me, that means the customer does not know what they really want. If a customer knows exactly what they want, it should be much easier to articulate it and convert it into a technical requirement specification. Is anyone ever going to tell a customer, 'You have no idea what you need?', I doubt that. Hence we continue to live with customer requirements that are hard to articulate and unclear.
2. There needs to be a designated product owner for a product. The job of the product owner is not just 'talking' to customers but much more than that. This is where most product owners fail. I've come across product owners that are totally customer focused and detached from the development team. They have no clue as to what has been shipped and what has not. On the other hand, I've come across product owners that are totally development focussed and lose sight of the customer. It has to be a balance.
3. If everyone in the team ends up talking to real customers (or end customers) then who is going to do all the work? It is not possible for an individual to talk to real customers, 'Observe', 'Frame', 'Brainstorm', and 'Build' at the same time. It is different if your customer is not an end customer but maybe an intermediate upstream/downstream team that is using/supporting your product.

Let me know what you think in the comments section.

Jyothin

Covi-blog

Dear Reader,

Hope you are doing well, healthy and fine in this pandemic. We are all battling this pandemic in our own ways and so am I along with my family. We are all deep into the battle against COVID-9 and there is hope that we will be out of this soon. However, I don't think we will ever get back to our old way of life.

This blog is not about my thoughts on the pandemic but a Ctrl+C & Ctrl-V of an article I read that summarizes the situation today.

From Kevin C,

I’m reading lots of information about the latest virus “surge” – as virologists and epidemiologists all over the world try to make sense of conflicting information on the coronavirus infection rate trends.  Rather than debate what is/isn’t a surge, I am going to stick with an analogy that makes the most sense to me right now: a forest fire.

A forest fire starts with a spark – it could be from lighting – it could be from a careless camper who doesn’t extinguish a campfire fully.  While the cause of the forest fire is something to investigate, the more urgent question is how to best limit the amount of damage the fire causes.  How, where, and when the virus started will be important to determine one day, but the pandemic has been underway for more than a year now – and the battle lines are all about damage control – just like a forest fire.

 

The forest fire grows and spreads by finding fuel – dry wood that is easily consumed by the inferno of a forest fire.  The more it finds, the hotter it burns.  This coronavirus (SARS CoV-2) is no different.  It spreads by finding fuel (humans) who lack sufficient immunity to fight it off.  Forest fires are often accompanied by hot, dry wind – which accelerates the spread, and makes the resulting fire larger, more explosive, and more difficult to fight and contain.  In the case of SARS CoV-2, the hot, dry wind can be compared to the mutations (variants) that are occurring – changes in the virus that make the contagion shift shape and direction, making it harder to fight and contain, just like a forest fire.

 

The last part of the analogy is the firefighters, the brave men and women who expertly fight the fires, and risk their lives trying to limit damage to life and property.  I think of vaccines as the firefighters of the pandemic.  Vaccines are racing against the hot, dry wind of the variants.  Where the virus finds dry wood (unprotected, unvaccinated humans), we can expect “hot spots” or “flare ups”.  And those hot spots will burn until they are contained – either through non pharmaceutical interventions, like physical distancing and face protection – or until they can’t find any more dry wood to burn – due to immunity conferred by having had the disease, or by immunity conferred by vaccines.

The fight against the virus is very active right now, but only in certain parts of the world.  And just like what happens during forest fire season – there are ebbs and flows – progress and setbacks – that make it very hard to keep score as to which side is winning.  In the U.S., Europe and Brazil, it looks to me as though the virus is currently winning.  While vaccine distribution is ramping up in many places, SARS CoV-2 had a massive head start, and is not having any trouble finding plenty of dry fuel to burn.  Global infections are increasing by 30% (14-day average), a sign that the virus continues to build on its lead in certain parts of the world.

 

Forest firefighters often encounter people who don’t want to evacuate or leave their homes.  They want to stay and “ride it out” – just like we find with hurricanes, or floods, or other natural disasters.  They have many reasons for wanting to stay in place – they don’t believe the fire will affect them – they’ve survived prior disasters before, so why will this one be different?  They don’t like anyone telling them what to do.  The list goes on.  We see the same beliefs and attitudes playing out in this natural disaster.  Although I am sure the firefighter banging on the door telling someone they really need to evacuate is incredibly frustrating – in the end, people are going to make the decisions they think is best for them.  It is hard for me to understand this, but I’ve come to understand I don’t have a right to impress my values and beliefs on others in this regard.  All we can do for those who are vaccine hesitant is to educate and answer questions in as balanced a way as possible.  For the truly “vaccine resistant”—like those who choose to shelter in place during a forest fire—I accept we’ll need to focus our attention elsewhere.

 

Forest firefighters are very confident in their tools and training, but they realize that their tools and training are no match for the power of nature.  When temperatures are high, or winds are strong, forest fires are impossible to extinguish – nature is in clearly in charge – no matter how talented the firefighters might be.  But when it begins to cool – when the winds die down – or best of all, when it begins to rain – firefighters make enormous headway, and eventually, the fire is extinguished.   

 

Back to the other side of the analogy one last time:  we badly need some “rain” in the battle against the pandemic.  We need the vaccine distribution process to strengthen.  We need non pharmaceutical interventions to stay in place for longer.  With every vaccination, we throw water on the dry wood – and we make it harder for the virus to find fuel.  Each day, millions of people all over the world are receiving the vaccines, which will speed up the end of the pandemic.  

 

Like a forest fire – it is really a race against time – to give the firefighters a chance to succeed.

Hope you found this summary useful. Thank you Kevin C for this analogy.

Until next time.

Jyothin

PS: Let me know what you think in the comments section.