Hackers and Painters

Foreword

The author is known as the father of Silicon Valley startups, and this book is a collection of his essays, which has received high praise.

The first quarter of the book revolves around nerds. I read this part four times or even more, but not because I liked the content.

It was because I couldn't get through it; every time I got close to the end of the nerd section, I would give up, having no desire to continue. The next time I picked up the book, I would have to reread the nerd part. The reason I kept picking it up was that I didn't believe the whole book could be as boring as that section...

Disclaimer: The term "hacker" in this book can be understood as a computer technology enthusiast, without any derogatory or commendatory connotation; it is used to represent this group of people.

I. Hacker == Painter

If hacking were a profession, it would certainly be one where, like a painter, you pick up a brush and create as you please.

A painter can spread a canvas in their mind at any time, add some graffiti from a flash of inspiration, and then find a quiet and beautiful moment to hold a brush and wholeheartedly depict the world in their heart on paper.

Hackers should be the same. Technology practitioners != technology enthusiasts, but technology practitioners all started as technology enthusiasts. Later, for some reason, they forgot the world in their hearts and became pure technology practitioners. It is a very sad thing to forget that you can pick up a brush and become a painter at any time.

Practitioners are passive, while enthusiasts are driven by interest. Thinking about it carefully, I seem to be getting closer and closer to being a pure practitioner. My initial interest has slowly vanished, replaced mostly by passively completing tasks, implementing endless requirements, and fixing never-ending bugs... In my free time, I don't think about picking up a brush to depict the world in my heart. I'm like a street painter who only provides portraits to the customers in front of them, but has forgotten the vast world they meticulously sketched in their mind.

II. Is It Really So?

• Some say that technology X is the industry best practice, with strong community support and wide application, so choosing technology X is definitely the right move.

• Some say JQuery is slow and using vanilla JS is fast; improving response speed to enhance user experience is what matters most, so hurry up and give up on JQuery.

• Some say Zepto is slow and inefficient, making mobile development more trouble than it's worth.

Is it really so?

Before making a choice, we might as well ask ourselves: we seem to always have many reasons to choose something that sounds good or accept a viewpoint that sounds right. Only by questioning at such moments can we perhaps find the truth.

The book Asking the Right Questions emphasizes this point. When faced with a seemingly correct but actually false proposition, if you don't question it, you imply agreement. The next time you encounter a related problem, you will treat this false proposition as an axiom and make wrong choices based on it.

I learned JQuery but don't like using it because I heard it's slower than vanilla JS. To this, an interviewer replied: Actually, JQuery is not as slow as you imagine.

III. Be Willing to Accept a Better Language

Technologists more or less have some technological obsessions, such as the so-called "programmer hierarchy." They are reluctant to throw away a brush they have used for a long time. Why not change? Because it's good. Well, in what way is it good? Oh, it's just good, it's good in every way...

The latter half of the book basically emphasizes: Lisp is great, a hundred times better than Java. Of course, this is a bit tongue-in-cheek, but the author indeed believes Lisp is an epoch-making language with a design philosophy a hundred years ahead of its time (created in 1958 by MIT's John McCarthy based on lambda calculus). Whether this is true, I don't know, but the author did succeed in piquing my interest. At the very least, one should experience the advanced and powerful aspects of Lisp, shouldn't they?

The author is not asking everyone to give up the languages they are familiar with for Lisp, but rather wants to make a point: we should be willing to accept a better language.

Book Review

Well, except for the nerd part, everything else is fine.