Category: books

On Reading, Creativity, and Self-Reflection

This week I had an interesting discussion with a close friend. We have known each other for more than twenty years and whenever we see each other we ask each other what we have learned since we last met. This one question leads to many other questions and we spend many hours discussing different aspects of life and work. 

Continue reading “On Reading, Creativity, and Self-Reflection”

My Notes on the “A Philosophy of Software Design” Book

This week I finished reading A Philosophy of Software Design book by John Ousterhout. I found the book easy to read and moderately thought provoking. 

The book talks about two approaches to reduce complexity of software systems – 1) embracing simplicity 2) embracing modular design. 

Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.

We know  we are working with a complex software system when:

Continue reading “My Notes on the “A Philosophy of Software Design” Book”

My Notes on Deep Work Book

I decided to spend year-end holiday time reading a couple of books. I like to read books that in some way help me solve problems that I face in professional and personal life. At work because of my title and circumstances I have to play three different roles – maker, manager, multiplier. 

  • Maker: Create stuff (software, powerpoint, design document, etc).
  • Manager: Talk to people about their concerns and hopefully resolve them or at least guide them in the direction that takes them on the resolution path. Keep the stuff moving.
  • Multiplier. Enabling people by helping them in software design, code reviews, estimates, hiring right people, etc.

I am fortunate that I get to work on many tasks that are cognitively demanding. At the same time, I also have to work on tasks that don’t demand such cognitive skills.

Continue reading “My Notes on Deep Work Book”

Present vs Future Focussed People

The below is the text from Hell Yeah or No book. It gives a good mental model to reason how one live their life. I don’t think one has to entirely in one list or the other. You will be more aligned to one list than the other. Also, I don’t think one is better than the other.

Present-focused people

  • Pursue pleasure, excitement, and novelty
  • Focus on immediate gratification
  • Especially appreciate life, nature, and the people around them
  • Are playful, impulsive, and sensual
  • Avoid anything boring, difficult, or repetitive
  • Get fully immersed in the moment and lose track of time
  • Are more likely to use drugs and alcohol
  • Are better at helping others than helping themselves

Future-focused people

  • Delay gratification
  • Are driven with self-discipline because they vividly see their future goals
  • Tend to live in their minds, picturing other selves, scenarios, and possible futures
  • Especially love their work
  • Exercise, invest, and go for preventative health exams
  • Are better at helping themselves, but worse at helping others
  • Are more likely to be successful in their careers, but often at the expense of personal relationships, which require a present focus

The 21 Lessons From “The Tao of Charlie Munger”

I read The Tao of Charlie Munger book this weekend and following are my favourite lessons from it. It is a book that you can read in half a day.

  1. Focus on your circle of competence. I have written about it in LIL #3.
  2. Diversification makes no sense for someone who knows what they are doing. It is a protection against ignorance.
  3. You should bet heavily when odds are in your favour.
  4. Patience is the key to becoming a successful investor. I succeed because I have a long attention span.
  5. Overconfidence destroys even the smartest among all.
  6. Wait for the right opportunity. All of the humanity problem stems from the man’s inability to sit quietly in a room alone.
  7. Try not be stupid rather than trying to be intelligent.
  8. Fear is essential to make people work.
  9. A great business at a fair price is superior to a fair business at a great price.
  10. There is no master plan. You have to keep iterating and improving.
  11. Spend each day trying to be a little wiser that you were when you wake up.
  12. Good people find other good people.
  13. Know big ideas from different disciplines.
  14. Watch out for people who always confidently answer questions about which they don’t have any real knowledge.
  15. Admit your stupidity
  16. Specialization protects us from the competition.
  17. Live within your means.
  18. To be successful in something, we need to be passionately interested in it.
  19. If you don’t need something, you don’t have to buy it. Be frugal.
  20. Become a learning machine.
  21. In marriage, you shouldn’t look for someone with good looks and character. You should look for someone with low expectations.

The Compound Effect

We all are looking for a quick way to earn money, lose weight, build relationships, get promotion in our job, or become successful in life. I have failed numerous times with my effort to achieve my goals. We all give up too quickly. Failing is not an issue if you failed after you have given your best. Most of the time we fail because we don’t try hard enough. We give up too soon.

Continue reading “The Compound Effect”

20 Lessons Learned from Reading Rework Book

A couple of weeks back I re-read Rework book by Jason Fried and David Heinemeier Hansson. Following are the twenty lessons that I learned:

  1. Meetings are toxic. Either schedule meeting for 15 mins or 2 hours. The default duration of 1 hour is not the right duration for most meetings.

  2. Say no to feature requests. Keep your product minimal and coherent. This way you can build a product that is more useful for the client. Creativity is subtraction.
  3. Look at by-products of your work. Blogging, books, other ideas form from your base work. Don’t miss this opportunity. When you make something , you always make something else
  4. Hire a better writer. If you have to choose between two programmers then choose the one who is a better writer. Writing requires you to explain things clearly. A good writer knows the important of good communication.
  5. Embrace laziness. Wait till the right appropriate moment before building a feature.
  6. Learning from mistake is overrated. Build the smallest possible thing that is successful and then iterate on it. Success is the experience that actually counts.
  7. Small is not just a stepping-stone. Small is a great destination in itself. The best way to build things is Do things that don’t scale. Sometime small is the right size.

  8. Start making something. What you do is what matters, not what you think or say or plan.

  9. Embrace constraints. Constraints are advantages in disguise. Limited resources force you to make do with what you’ve got. There’s no room for waste. And that forces you to be creative.
  10. Start at the epicentre. 
  11. Ignore the details early on. The reason: Detail just don’t buy you anything in the early stages. Besides, you often can’t recognise the details that matter most unit after you start building. That’s when you see what needs more attention. You feel what’s missing. And that’s when you need to pay attention, not sooner. This is the reason I feel discovery sprints are useless. They give an illusion to client that you can magically figure out everything in 2 week without building stuff. The real questions arise once you start building. This is when you can validate your assumptions, clarify doubts, reason along, and try different approaches.
  12. Be a curator. There’s a lot of stuff off the walls than on the wall. The best is a sub-sub-subset of all the possibilities. Don’t be a hoarder. Be a collector. Creativity is subtraction.
  13. Focus on what won’t change
  14. Don’t get obsessed over tools. The content is what matters.
  15. Sleep 8 hours daily
  16. Say no by default. Customer is not always right.
  17. Don’t confuse enthusiasm with priority.
  18. Learn to say Sorry.
  19. If everything is high priority then nothing is high priority.

  20. Inspiration is perishable.

Writing your First Technology Book

So I wrote my first book. It is a great feeling to find your book available on Amazon http://www.amazon.com/OpenShift-Cookbook-Shekhar-Gulati/dp/1783981202/. I have read many motivational books or quotes that suggest everyone should write at least one book in their lifetime even if no one reads it. I hope people will find my book useful and learn from it. This blog is not about my book but it is about the lessons I learnt while writing the book.

  1. Limit book scope: As a first time writer it is very tempting to include a lot of related topics in the book outline. I made this mistake in my book outline but as I started writing the book it became clear that I should drop few topics to write a cohesive book. Pay a lot of attention to the book outline and don’t try to put everything in the book. For example, my book is about OpenShift, a platform as a service that supports Java, Python, Node, Ruby, PHP, and Perl runtimes. In my book outline, I proposed to include everything except Perl and Ruby.  After writing few chapters it became clear that we can’t include everything in one book as it would lead to a book that covers lot of topics but none of the topic would be covered in entirety. Keep in mind book outline will change so always try to keep publisher updated on the same.
  2. Your Estimates will be wrong: The book started with the initial estimate of 250 pages and 6 months writing time. We ended with 430 pages and it took more than 10 months to finish. I suggest you take book writing as another software development project. Like most software development projects, book estimates can also be wrong. The better way to write a book is by taking an iterative approach where you re-estimate after writing each chapter. Consider book writing as an Agile software development project rather than a waterfall project.
  3. Plan your book: I suggest if you wish to write a book on a topic then you should first write a blog series on that topic. I have written close to 70 blogs on OpenShift and that helped me a lot. This not only help in content creation but also gives you an audience that would like to read your book. Make sure to tell the publisher in advance that you would use your blogs.
  4. Managing your time: Writing is a very tedious and time consuming task. Writing a technology book involves various tasks like writing book text, creating sample applications, learning new changes introduced in the topic etc.There would be days when you will be productive and write a lot of content and there will be days when you will not be able to contribute much. Be prepared for lean patches as book writing can tire you more quickly than writing code. Initially I used to write book only on weekends but that didn’t worked for me as my writing flow suffered during the week. I tried writing on weekdays after office hours but that too very quickly became tiring. It is very difficult to write a book with office work. Try to plan few weeks holiday to work on the book. I took a couple of weeks off and only worked on the book. This really helped me finish book and maintain my writing flow.
  5. Read books: As a first time writer there will be times when you will be unsure about a topic or how to correctly convey it to the readers. Reading books can help you learn some tricks or improve your writing style that will help you convey your point better to the readers. Try to steal ideas from good books and apply to your book.
  6. Become comfortable with the book format: I wrote a cookbook that required me to use a predefined template. This sometimes restricts you and slow you down.
  7. Keep all book artifacts in a version control system: I used a private Github repository to store all my book artifacts  including content, images, invoices, source code etc.This not only helps as backup and version control system but also helps to analyze your writing habits. For example, the Github repository contribution graph shown below clearly show my writing flow throughout book writing period.book_contributions_over_timeI also used a separate public Github organization https://github.com/OpenShift-Cookbook for the web applications I developed in the book. This helped me keep all book related application source separate from my own Github account.
  8. Plan for software updates: The biggest problem in writing technology books is that technology changes/deprecates very rapidly. There could be a significant change in the software library that would impact your book quality and correctness.

Hope you find these useful when you write your first book.