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.
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:
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.
- 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.
- 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
- 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.
- Embrace laziness. Wait till the right appropriate moment before building a feature.
- 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.
- 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.
Start making something. What you do is what matters, not what you think or say or plan.
- 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.
- Start at the epicentre.
- 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.
- 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.
- Focus on what won’t change
- Don’t get obsessed over tools. The content is what matters.
- Sleep 8 hours daily
- Say no by default. Customer is not always right.
- Don’t confuse enthusiasm with priority.
- Learn to say Sorry.
- If everything is high priority then nothing is high priority.
Inspiration is perishable.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.I 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.
- 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.