Tag: learning

Categories
Agile Learning

Reading List 2021

2021 was a good year for reading. I definitely read more books for pleasure than for work this year, so I blew past my goal of 125 books much earlier in the year than usual. and the year is not over! I have a few I’m still hoping to finish before the new year begins.

See the books that I read and think have wide or general professional value here: https://www.goodreads.com/review/list/95756-carina?ref=nav_mybooks&shelf=2021-professional-reading

Stand outs include:

  • Think Again by Adam Grant
  • The Fearless Organization by Amy Edmondson
  • The Sum of Us by Heather McGhee
  • Subtle Acts of Exclusion by Tiffany Jana and Michael Baran
  • The Leader’s Guide to Unconscious Bias by Pamela Fuller, Amy Chow and Mark Murphy
  • The Agile Culture by Pollyanna Piston, Paul Gibson and Niel Nickolaisen

See all the books I read this year here: https://www.goodreads.com/user_challenges/25561002

Categories
General Learning Reflections

Gaining a Sense

My mother got a second cochlear implant last year and it was turned on last week. The first involved shaving a good bit of her head, much more invasive surgery. This time was much better, outpatient surgery, with a small incision.

Here you can see and hear the difference between her first, 20 years ago, and her new one.

I’ll say my mother is nothing short of amazing. She had never heard, her entire life, and even with the limited capabilities of her first implant, and despite being warned she’d never understand speech, she persevered. She spent hours studying, listening to audiobooks reading along, to *learn* to understand speech. If that’s not being a learn-it-all, I don’t know what is.

And… data makes a difference. The difference between the first and second implant, for me, is the difference between a single instrument and an orchestra.

Below you can hear the before and after comparison – what she heard with her first implant and what she can hear now. This difference is striking.

See the original post here.

Categories
Agile

Fail Early

On the subject of fail early – I had a great lesson in this in the fall of 2013.

I went to a shooting range for a social event. I participated in 3 rounds at three different locations. It was the first time I had ever held a gun let alone shot one, and I was really intimidated at the first station. We were grouped in teams, and each person got two shots per turn at clay pigeons that came from varying locations. Then the teams would switch.

At the first station I received minimal instruction and minimal feedback. I would take aim and fire, but only ended up hitting one over the entire series.

At the second station, each person still took a turn to shoot, with a rotating launcher for the pigeons that might send your target out in any direction, but this time only one shot per turn. The feedback was very detailed. I got feedback after each shot. I shot maybe two total in the series.

At the third station, in the same location, we then shot each person, each turn, and I being the only lady in the group, got to call when to release the pigeons. I shot and hit every one.

For me, being able to participate and get immediate feedback on every shot without pause between to wait for others taking their turn was essential for my success. I needed the experience of taking the shot, every time for all the feedback I had received to really work. You could have spent all night talking to me about how I needed to aim higher or to the left, or not to pause when I got the target in my sights, but none of that could substitute for the actual experience of aiming, shooting, then repeating the whole thing again.

Developers need that experience in their work as well. Taking aim at a target, attempting to complete it, and learning from that experience. The most important part of this equation is learning!

Eric Ries, author of The Lean Startup was rumored to release up to 100 times a day for his product IMVU. The product was released after 6 months. It was buggy, but it got out and into use with the people who were interested in it, allowing improvement and refinement of the product to the customer’s needs.

He compares the release of IMVU and it’s buggy performance so bad it didn’t perform half of the time when presenting to venture capitalists to the release of another perfectly planned over the span of 3 years that failed miserably.

The difference is that they didn’t try to predict what was wanted or needed in 3 years, they tried to figure out what was wanted / needed now, and got fast and early feedback from customers to quickly iterate over the product to make it more and more into the ideal.

We should take these lessons to heart. Getting early and often feedback is important. Making mistakes is essential to improving and innovating. Finding out about these mistakes early has a much lesser cost to fix than finding out about mistakes late.

Fail early, fail often – otherwise you aren’t stepping out of your comfort zone into what is possible and stretching your potential. Otherwise you are playing it so safe you never take a risk at all. That might be comfortable, but it also probably won’t get us very far in the long run. The problems we have today will be the same problems we talk about in one year or two years.

Take a risk and try something new. Maybe even consider the possibility that we may want to start something radical – like the new management of the Toyota plant Nummi – taking the roughest union workers and turning them into team players by treating everyone as valuable, allowing anyone to stop the production line when there was an issue, using a pull workflow, and problem solving together.

This goes beyond methodology and into practice. What do we want our work environment to be like? Do we want to look forward to working together as a team, and value all contributions? Do we want to raise the level of accountability to the products we work on and to our teammates? Do we want to encourage innovation and measured risk taking? Do we want to look forward to the possibilities new technologies may offer us and experiment with what they might be able to give us?

Change is a scary but necessary and expected part of technology work. Expecting things not to change is like expecting it to rain and to not get wet.

Rather than avoid change- let’s embrace it, and the learning potential it brings with it, whenever we can.