Dr. Liz Alexander visited ThoughtWorks Bangalore today (Sunday Apr 29, 2012) to give a talk about writing a non-fiction book. Many thanks to her for agreeing to give a talk on a sunday morning. It was great to hear from someone who has written 13 books and has a readership of a million.
Below are my key takeaways from talk.
Why to write a book?
- The question I like to answer is ……
- Who is my target audience?
- Where are the audience and how do I find them?
- Establish a writing platform, show up at places, expand reputation. Blogs, magazine, conferences matter.
SEO of book writing, it is OES
- O-Opt-in identifier. Take into account demography and psychography.
- E-Emotional hook. Can people relate themselves to the book?
- S-Special sauce. Our knowledge and expertise.
Help from others
- We need the help of proof readers, critical reviewers, layout artists, cover artists, page look and feel designers for a book to be of publishable quality.
- Vanity publishing vs commercial publishing
- Vanity publishing requires upfront investment from the author to get it to the market.
- Commercial publishing takes a lot of effort, credibility, being at the right place right time. Also pays upfront but a lion’s share of revenue goes to the publisher for the risk taken.
Ego vs care for readers
- It will be tempting to push an idea into a book through vanity publishing which is like a startup idea being tried in a small office space at the corner of the road without any business plans.
- The desire to sell the books written will also focus on what the readers want than trying to get the book published and not sell much.
- Critical reviewers are very important to shape the final look. Friends, relatives and fans will just praise the effort without helping to improve.
Once again I thank Dr. Liz Alexander for her presence and sharing the knowledge, Rajiv Mathew for arranging the meetup.
Image: Rajiv Mathew/ThoughtWorks
Retrospectives are very important for every team. It brings every one in the team together into a room and make them think, discuss, reflect and take actions based on their reflections. The usual way of running retrospectives is to run at the same time every week, iteration or phase of work. This predictability also brings an element of boredom if the retrospective format is the same every time.
I observed that by changing the format of the retrospectives as per personalities and the need of the team helped a lot in running it effectively and people taking action on what they have discussed and reflected. I have used the simple Postive-Delta format many times and it has helped me get every one in the room involved for the duration of the retrospective. I have also added a pre activity and post activity to this format.
Team size: 12-16 people
Time required: 1 hour
How to do this?
- Ice breaker or energizer – Any simple ice breaker to which can be completed within 5 minutes is a good start. It loosens up people and also makes them forget work if they were pre-occupied with some problem.
- Reflection time – Give the team around 10 minutes of silent time to think about what went well and what needs to change. They can write it down if they think they will forget.
- Writing space – Have two whiteboards or split the writing space into two. Mark one side as ‘+’ and the other side as ‘Δ’. Have white board markers in two different colours such that you can capture points in alternating colours. It is easy to read the board from every where in a hall.
- Positive round – Pass a soft toy around and request the person holding the toy to give only one top positive about the retrospective period. If their top point has already been expressed by another member then add a ‘+1’ to that point ask them for their second top point and write it down. Give every one in the room a chance to give at least one point and also make sure the one with the soft toy alone speaks. At the end of the round if anyone still has a point to speak note down that as well. Do not gather any explanation for any point other than the something which can help capture the point on the board.
- Delta round – Similar to ‘Positive round’ but ask for what has been nagging problem and they wish to change it. Go through the same process of capturing the points from the team as in positive round.
- Analysis time – This phase can get longer if not facilitated properly. Read each point on both sides and capture ‘Action items’ and ‘Ideas’ from the team. If any point gets into a debate or a solution mode then quickly interrupt and capture the resolution of that problem to be an action item for a focussed group or the team itself based on how severe it looks.
- Ownership for actions – Request for volunteers to implement the action items and try out new ideas. Capture their names against the line items on a poster to put it up in the team area later.
- Recognition time – Though teams should not have heroes or heroines, it is natural for individuals to go through phases of ups and downs which makes some individuals contribute more than the others in a given span of time. Give the team the last five minutes to reach out to the individuals whom they think that life was made easy because of their help or contribution; and thank them mentioning what made their life easy. The last time I requested the team to do this I was surprised to see so much of hugging, huddling and laughter all over the room. Every one left the room on a high note.
This format of retrospective helped me to make everyone in the team talk about what matters to them and finish it off within an hour while capturing the action items and their owners. This format works well with a group size of 12-16 and only to retrospect an iteration or a phase of a project. The content in retrospectives website
helps me to run effective retrospectives.
Image: winnond / FreeDigitalPhotos.net
Nat Geo’s air crash investigation series gives a good deal of idea behind what went wrong behind an air crash or failure. I was watching one of the episodes which was about the rudder malfunction of Northwest Airlines Flight 85 and how the pilots kept such a large plane in control and landed it safely. All the pilots in that plane continued to fly the plane by adjusting the engine thrust and ailerons to fly to the nearest airport and land safely.
As per the captain’s account it was a very tough thing to fly such a large plane manually. The captain is also a flight instructor so he had a sound understanding of the dynamics of the plane. When interviewed he said “Learning to fly manually is an art, sadly that is a dying art“. Increasingly planes are being designed and manufactured to fly themselves most of the times. This makes the lives of the pilots so easy that most part of the journey is assisted by the machines. But when the machines fail or not designed to handle failures, can humans take over?
What happens to other professions where there is an ever increasing assistance provided by the computers and machines? The result must be the same; when something goes terribly wrong; then there will be a disconnect between the man and the machine. From that point onwards it will be just trial and error handling if there is no deeper understanding of the system.
I read this article on leaky abstractions longtime ago. The author states that if something non trivial is abstracted then the abstraction will be leaky and put us in a spot. This article also prompted me to dive deeper into something if I am learning new. It is really tempting to hang on to the hello world examples & the new hello world of GUI “To do lists” and get away with a feeling that I have got a fair exposure. If I just learn that but not spend enough time to understand the internals, then I would be in a bad spot someday when I least expect.
Image: bk images / FreeDigitalPhotos.net
Bret Victor – Inventing on Principle from CUSEC on Vimeo.
I got a forward from one of my peers a month ago. Even though the video is just an hour long I was putting this away for a weekend. After watching this video I realized that I made a mistake of putting this away for a long time. This talk definitely made me think every problem differently. Bret Victor has also come up with reactive documents, he believes that most of what we do with computers were designed to be done on paper and we are not using the power of electronics.
Some of the quotes I captured from the talk in my own words.
When you have to compile, run and see what you have built chances are high that you won’t discover that a shimmering effect can be provided by just changing the radius of a circle.
If the feedback loop is longer; thinking something and seeing it much later does not bring any connection.
If creater needs to know about time, then need to know how to control time.
When we write program for the computer to do, why are we simulating in the head what a computer should do; instead ask the computer to do.
The languages were designed when there was batching through punched cards. No one wrote a program and was able to immediately see the output.
Ideas are precious, seeing an idea die hurts
One of my peers sent the following to my team as his take away from the talk.
Injustice, responsibility, moral wrong.. these are not the words we normally hear in technical field. We hear these in association with social causes. So things like censorship, gender discrimination, environmental destruction.. we all recognize these things as moral wrong. Most of us won’t see a civil rights violation and think that it is an opportunity. I hope not. Instead, we have been fortunate to have people throughout history who recognize these social wrongs and sought as their responsibility to address them. So this activist lifestyle where a person dedicates themselves to fighting for a cause they believe in. And the purpose of this talk is to tell you that activist lifestyle is not just for social issues. As a technologist, you can recognize wrong in the world. You can have a vision of a better world to be. You can dedicate yourself to fight for that principle. Social activist fight typically by organizing, you can fight by inventing.