patkua@work

The intersection of technology and leadership

Page 11 of 53

Book Review: The Art of Learning

I like reading books that describe how people grow. It’s useful as a Technical Leader to help you grow your team, it’s useful as an agile coach to help people build new skills and useful to you to look at how you can grow yourself. Thanks to pop-economics books like “Outliers” people might spend 10,000 hours working on a skill but never really master it. As I have heard people say before:

You don’t develop mastery by doing the same thing over and over again

Here’s a good post why top achievers 10,000 hours may be different to yours.

The book is written from the perspective of Josh Waitzkin, a guy who has had an incredible life mastering a couple of disciplines that couldn’t really be any further apart, Chess and Pushing Hands. He’s even had a movie made out of his life.

The Art of Learning Book

What I liked about the book
Waitzkin has already led a life ripe for several movies, and he describes his journey like a story book unfolding. I found it engaging because it is personal. He writes about detail that others could not know and he’s happy to disclose difficult parts of his life. I think these details made me relate to him much more.

I sensed he thinking deeply about himself, and in a way, observing this in his writing gave me respect he already knew a lot about learning (it’s hard to get better if you have no idea what you’re doing!) He isn’t particularly prescriptive about his learnings

I find it clear that he thinks deeply about his own self, and in a way, I think that makes him already very effective as a learner. He isn’t particularly prescriptive about his method of learning, talking about some general steps that take the form of chapters and draws upon his own personal anecdotes to make examples of them.

What I didn’t like

Although I found his personal stories captivating, I felt they were slightly embellished because of the way he discusses what other people were thinking during certain events (particularly during competition). Take it with a grain of salt, but it slightly tarnished some of the storytelling for me.

I also enjoyed the linking of the personal journey to the chapter titles, but would have been useful to have a summary providing insight into making it a bit more practical concrete. Reading other reviews on sites like amazon also give people some of this frustration.

His two personal situations were focused on competition and I think reflections some of the emphasis of “another opponent”. I found this difficult to translate into learning skills for self-development where you aren’t “opposed” to a single person such as learning a language.

What I learned

His chapter Using adversity gave me examples of how to turn difficult situations into learning opportunities. His drive and motivation reinforce other ideas about learning I have read about (that it’s about dedication and not necessarily innate skill that drives success).

The chapter Slowing down time reminded me about the differences between expert and beginner’s mindset that demonstrate what is “magic” to one person is perceived differently and working on how to break the “magic” into smaller, learnable, and practices steps accelerates the learning process. I think this requires a lot of self-perception, and the importance of exposing yourself to more difficult, challenging situations.

Conclusion

I gave this book away to someone recently because I felt they would benefit from it. However it is definitely one that I will be trying to read again sometime as I am sure to have a different insight by focusing on different areas. If you’re interested in learning, this is an enjoyable book that teaches some good principles but lacking concrete actions. Still recommended reading.

His personal stories are particularly captivating, but I find it difficult for him to conclusively draw what other people were thinking in the way that he describes

Book Review: Quiet

I have read more books recently with so much more travelling. Susan Cain wrote the book I finished most recently, called Quiet: The power of introverts in a world that can’t stop talking. A provoking title and filled with a good level of research and stories talking about how today’s society views introversion as a negative trait, but can actually provide people and organisations with positive outcomes.

Quiet

What I liked about the book

Cain provides a different, refreshing perspective about the strengths introverts can offer. She highlights (mostly American) cultural influences that make it difficult for people with introverted tendencies to operate and some practical suggestions along the way on balancing the needs. For example, introverts often need time to digest, prefer to do deep analytical thinking and need time to restore after heavy interaction with many people. Another example is that extroverts tend to take more risk, particularly under stressful conditions, while introverts tend to take more take.

The book made me think about practices like “pair programming” and how agile methods impact introverted people and their need for space. Sidenote: I don’t see agile methods working against introverts but just that necessary balance must be found

I particularly enjoyed the section where Cain discussed how people with different extroversion/introversion tendencies can find a way to live, work and love together. It reminded me of interests based negotiation over positional based negotiation and that if people focused on what their needs were, instead of outcomes, they might find a new, slightly different solution that work for both parties.

What others might struggle with in the book

Although Cain references a lot of research, the contents appear to me more anecdotal. She approaches this early in the book, writing about different definitions of introversion and peppers disclaimers throughout the book that “not all introverts act the same”. She also references studies but warns they are not conclusive because these are in early stages. For some, this may be a killer, but for me, still provided an interesting read.

At times, the guidance can be confusing. In some parts of the book, the message I took was that introverts don’t need to adopt extrovert characteristics. In others, I felt like the guidance changed to sometimes introverts need to adopt extrovert characteristics but they will need to time recharge and it helps to do so in areas you enjoy.

Conclusion
In some part of the book, Cain describes the world being at least thirty to fifty percent being made up of introverts. Some may be better at hiding it. I think everyone should read this book to understand more about a group that will naturally be more quiet and why that is.

Disrupt yourself, or someone else will

A couple of days ago, Apple announced their new range of iPads including a mini with a retina display and a lighter, thinner full-sized iPad. Notice anything strange about their prices?

iPad2 Pricing

As can see the new mini retina priced at exactly the same price point as the (old) ipad2. Seem strange? You’re not the only one to think so as outlined by a comment from this appleinsider article.

Comment

This isn’t the first time Apple have priced a new product at the same as an older product (and probably won’t be the last).

The Innovator’s Dilemma
In the book, The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail, the author shows organisations that fail to embrace new technologies because they focus on the success of a single product or technology.

By offering these lines (new and old) Apple effectively segments their market into the early adopters of technology while providing (older and probably less appealing) options to all others. A conflict of features (retina display in a smaller form factor) makes users decide what is more important to them.

By removing the older iPad2, they effectively force consumers to move to the new platform and some of their customers may be happy with the existing product. Apple is effectively disrupting themself before their competition can.

Uses our cognitive biases

Having the same price point for a newer technology also taps into the anchoring cognitive bias (sometimes called the relativity trap).

Without the older product in the lineup, the newer products would not appear so appealing. The “anchor” of the older product is effectively pushing people to the newer products.

A person would ask:

Why would I buy older technology for the same price?

and then make the trade off for a smaller size, or if they want a newer size, pay another premium for it.

Book Review: The Power of Habit

After a twitter conversation with Rachel Davies, I wanted to read a book about change, and so I decided to read The Power of Habit: Why We Do What We Do, and How to Change by Charles Duhigg. After reading the first chapter, I realised that I had read the book but neglected to write up my thoughts, so I thought I would re-read the book.

The Power of Habit

Much like many business books, this book is full of anecdote’s and stories to help reinforce the habit loop. Early on the book talks about the habit cycle that once formed, is often very difficult to break. It involves a simple three step process that our brain reinforces over time as a way of saving energy in the brain. The author tells about research into rats that displays the difference in brain activity when a rat is first exploring a maze, compared to one that they are are used to navigating which they habitually navigate based on expecting a reward.

The habit loop

Habits save time
Habits are interesting because they save us time, but of course, perils lurk when habits have bad consequences such as drinking, gambling or unhealthy eating (probably one of my worst habits!). Fortunately the author focuses on understanding what things we can do to adapt behaviour.

We cannot stop a habit, only override it with a stronger one
With my understanding, small changes in the environment might not trigger our habits and if we can work out our cues, we might be able to stop the behaviour we want to change. However if we cannot change the trigger (or we cannot identify the trigger), we cannot often stop the habit. We can, however, create a stronger habit that overrides the other habit if we can connect the cue and reward, simply replacing the behaviour with an alternative habit. We do have to be careful though because our underlying habit still exists, and we might still revert to it under times of stress.

The strength of our mind
Another interesting point is the power of our own mind in that for change to stick, we really have to believe it will work. Very similar to the placebo effect cognitive bias, our minds are amazing machines and sometimes the power of willing it to be so makes a big difference to whether or not something works. This is often why some people talk about change only sticking when someone has a crisis because it is at this critical point where a person will fully commit to (and believe) an alternative.

Keystone habits
The book moves on from individual habits to organisational habits and from here, I felt the book explained the emergent behaviour out of a complex system through the lens of habits. For example, they talked about the organisational shift Alcoa went through when Paul O’Neill mandated a focus on fixing safety in their organisational.

The author describes this relentless focus on improving safety as a “keystone habit”, or a habit that if changed had the ability to trigger multiple other changes. In a systems thinking world, these would be leverage points or root causes. Same idea, explained differently.

Conclusion
I found The Power of Habit: Why We Do What We Do, and How to Change an easy book to read, and offers a lot of insight into why we might behave as we do in certain ways. I like its suggestions about actions we can take to create change, although I don’t necessarily agree with all of the anecdotes as I believe there are other ways of explaining the situation.

The ThoughtWorks Anthology, Volume 2 Released

I’m pretty excited to announce the release of The ThoughtWorks Anthology, Volume 2, a varied collection of essays in the field of software development.

The ThoughtWorks Anthology, Volume 2

Alistair Jones and I contributed a chapter titled, “Extreme Performance Testing” that I have talked about in the past. In this chapter, we discuss how we apply over decades of agile experience (particularly Extreme Programming) to the field of performance testing. We describes techniques and approaches for faster feedback that you can immediately apply to performance testing.

Why we moved off heroku

We recently made the move off heroku to a more basic box because we ran into a couple of issues. Although I don’t think that these are issues you will face in many other places, it proved to be worth moving.

First, it’s worth noting a bit of context for the application we were building. Although being web-based, we are building a prototype application connecting up a pre-designed user interface to a number of backend systems. We do not own the backend systems, we simply integrate with them. Our goal is to quickly see how difficult some of the implementation of an interface such as one envisaged would be, and also to discover gaps or contradictions in the data structures we get back by working through a real example.

Our First Problem
The first problem we had is a hard timeout, limited to 30 seconds and enforced by the routing layer by Heroku. They document it very well here. As they mention in their document, “the timeout value is not configurable” and is a reasonable constraint on normal web applications that you want to scale. Given our current design and architecture, moving away from a synchronous, stateless application to a model of asynchronous, polling would certainly add more application complexity to our code.

Our Second Problem
The second problem we had was strange behaviour with a java application deployed. When connected up to other external systems, the java application seemed to continue growing in its memory use. Restarts, new redeploys didn’t seem to fix it. We tried this labs feature (log-runtime-metrics) to get more insight but could only see memory go up and up. We tried setting the max heap size to a small amount but that didn’t seem to do anything. Concerned we had a real memory leak, we ran the code locally with the same production settings with a very small heap size and could not replicate it.

Our conclusion
Given where we are, we wanted to move fast without worrying about the infrastructure taking more development time, or unnecessary application code complexity. So we simply moved off. Spun up a new virtual box and were up and running in about half a day. It probably took another day and half to move all of our continuous deployment tasks to our new platform too.

Number of commits in git

I have been working on a project that required me to work out the number of commits in a git repository. I thought github would show that in their display, but could find no such statistic once you get over a certain number. The only number I could find that indicated it was over 1000.

Git commit count on github

Searching around, there are a few solutions including most recently:

git rev-list HEAD --count

or

git shortlog | grep -E '^[ ]+\w+' | wc -l

The Karma Test Runner’s dreaded Script Error

I have been using Karma Test Runner for javascript testing and like using PhantomJS as the test browser as it runs headless and is super fast. However every so often, I encounter the dreaded line:

Error: Script error

The error often looks like this in the console:

Error: Script Error

Since I work often in small cycles of test-code-commit (or just code-commit), my solution is often to rollback and try again. I thought I’d spend some time trying to work out how to get better diagnostics. A bit of digging around and the suggested way is simply to change browsers that give you a view of the javascript problem.

You do this by changing your karma configuration. In my karma.conf.js file I would tweak the value as below:

Karma.conf.js for different browsers

I then run the test again, and look at Chrome’s in built javascript console and look for errors:

Missing resource

Voila! A HTTP Not Found (404) for a resource I had declared in one of my require scripts. In this example, I intentionally added it in to cause that error, but this technique is useful for when you just can’t work out why something is not working.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑