Skip to main content

The essential reading list


One can spend a lifetime reading only a certain number of books. This list is to keep that reading focussed. The idea is taken from many engineering focussed reading lists, but I have added a bunch of books by myself too.

I will continue to update the list, both in terms of things left to read and the things I have read already.
  • How to Ask Questions the Smart Way, Eric S. Raymond
  • The Curse of the Gifted Programmer, Eric S. Raymond to Torvalds, 2000
  • On Bike Shedding, Poul Hennink-Kamp, FreeBSD list, 1999
  • No Silver Bullet, Fred Brooks (paper)
  • How to become a Hacker, Eric S. Raymond
  • HBR Guide to Managing up and Across
  • Suddenly in Charge: Managing Up, Managing Down, Succeeding All Around by Matuson, Roberta Chinsky
  • Principles, Ray Dahlio
  • Sapiens: A Brief History of Humankind
  • Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time
  • The Three Box Solution: A Strategy for Leading Innovation
  • The 7 Habits of Highly Effective People
  • Hooked: How to Build Habit-Forming Products
  • Lean In: Women, Work, and the Will to Lead
  • Inspired, Marty Cagan
  • Powerful, Patty McCord
  • Thinking - Fast and Slow, Daniel Kahneman
  • Zero to One, Peter Thiel, Blake Masters
  • The Hard thing about Hard Things, Ben Horowitz
  • Only the Paranoid Survive, Andy Grove
  • High Output Management, Andy Grove
  • Don’t Make Me Think, Steve Krug
  • The Elements of Style, Strunk and White
  • The Mythical Man Month, Fred Brooks
  • The Four Steps to Epiphany, Steve Blank
  • The Lean Startup, Eric Ries
  • The Goal, Eliyahu Goldratt
  • Masters of Doom, David Kushner
  • Hackers and Painters, Paul Graham
  • Lean Software Development, Mary Poppendieck and Tom Poppendieck
  • The Principles of Product Development Flow, Donald G. Reinertsen
  • Extreme Programming Explained: Embrace Change, Kent Beck
  • What Got You Here Won't Get You There: How Successful People Become Even More Successful!
Designers

  • 100 Things Every Designer Needs to Know About People, Susan Weinschenk
  • About Face: The Essentials of Interaction Design, Alan Cooper, Robert Reimann, David Cronin, Christopher Noessel
Developers

Extended Canon:

Comments

Post a Comment

Popular posts from this blog

सूनापन

मुद्दत हो गयी उन तन्हायियो को गुजरे , फिर भी इन आँखों में नमी क्यों है  ? तोड़ दिया मोहब्बत पर से यकीन मेरा, फिर भी मेरी दुनिया में तेरी कमी क्यों है ? हसरत है क्यों आज भी तेरी चाहत की मुझे, क्यों याद तेरी जेहेन से मिटती नहीं ? जलजला क्यों उमड़ता है ख्वाबो में मेरे, उस आशिकी की आगज़नी क्यों है  ? सन्नाटो में भी क्यों सुनता हू तुझे मेरी परछाई से क्यों तू जाती नहीं ? इन डबडबाती आँखों को तलाश तेरी, आज भी कहीं क्यों है   ?
6 comments
Read more

How the Python import system works

How the Python import system works From:  https://tenthousandmeters.com/blog/python-behind-the-scenes-11-how-the-python-import-system-works/ If you ask me to name the most misunderstood aspect of Python, I will answer without a second thought: the Python import system. Just remember how many times you used relative imports and got something like  ImportError: attempted relative import with no known parent package ; or tried to figure out how to structure a project so that all the imports work correctly; or hacked  sys.path  when you couldn't find a better solution. Every Python programmer experienced something like this, and popular StackOverflow questions, such us  Importing files from different folder  (1822 votes),  Relative imports in Python 3  (1064 votes) and  Relative imports for the billionth time  (993 votes), are a good indicator of that. The Python import system doesn't just seem complicated – it is complicated. So even though...
1 comment
Read more

What does it mean to “shift testing left”?

What does it mean to “shift testing left”? I used to think shifting left meant starting all these testing activities earlier in the process, but I realise it is more than that: it means  doing different things . Shifting left on testing means thinking about architecture and design differently, considering different stakeholders early and continually. Which in turn means shifting left on security, accessibility, and all the other dimensions of quality that we should care about. So shifting left on testing motivates all kinds of assurance activities, which can stop us over-investing in a solution that was never going to work. It is like TDD on steroids. As an unintended consequence, we can remove much of the traditional work that testers would have to do downstream when they only have late sight of the product. Again, we aren’t doing that work earlier, we are setting ourselves up to never need it at all!
Post a Comment
Read more