I have finally gotten around to reading (listening) “The Code Breaker: Jennifer Doudna, Gene Editing, and the Future of the Human Race” by Walter Isaacson. And in one of the first chapters, the writer talks about Jennifer Doundna’s thoughts (I think) on how often it’s the practical application of science or in solving a problem, we improve/revise our understanding of the fundemental building blocks (basic sciences) involved in solving the problem. And that is what Matt Ridley discussed in the book “How innovation works” in the context of the “Linear model of technology” - where he writes “We make a mistake if we insist that science is always upstream of technology” (I haven’t read the book, I got the quote from another website’s notes on the book).
This resonates with me. My approach to learning after the first 10-12 years of cramming in early schooling years to get good scores in exams have been really to build things first and then seek out the finer details of what constituted the building. For me, that exclusively meant writing computer programs and applications for any problem i could think of. This also meant, I ignored a lot of stuff, and never made time to learn those things because I couldn’t find a way to make use of them. And although I do have a fair few regrets about following that approach and not being invested enough in learning the “basic building blocks”, I am beginning to accept it, now that i am getting to a certain age and point of time in my professional career. If i live long enough, I will eventually get to learning those things too! In part, the acceptance is also the reason I am able to learn new things, as I am following what works for me.
My approach to learn something new is thus comprised of three parts:
- Goal to Build X
- Commit to Build X
- Learn everything that’s required to Build X
As it turns out, for me, (1) and (2) above has so far been - decide to write a book and sell the idea to a publisher, respectively. Then, get on with (3). That’s exactly how my third book was conceived and executed.
Parachuting into the world of Go programming
Patrick Radden Keefe (an American investigative journalist and writer) used this phrase “parachuting” when he was asked about how he approaches his works. He used it to indicate (i think!) that he usually starts a project, by not knowing anything about it, and then sort of figuring it out, immersing himself and then leaving to parachute into a new world for his next project. I believe that’s why his projects are wide ranging.
When I signed the contract for my new book, I was parachuting into the world of the Go programming language. Then, i used the next 12 months completely immersing myself into it as I worked on the book. The title is “Practical Go: Building Scalable Network and Non-Network Applications”, published by Wiley publications.
The book aims to not have the answers for all your questions as you want to improve your ability to use Go. It does however have a bunch of carefully selected topics that help you apply the language to build your applications. And thus, scale up your own understanding of the language itself.
You can learn more about it at the book’s website. I hope you will check it out!