in Books, Reading books in 2014

Hacker And Painters

Hackers and Painters by Paul Graham

Hackers_&_PaintersI read this book December 2008 the first time. I don’t remember a ton of it. I wrote one blog post about the book. But I remember that I enjoyed it.

After rereading it I can say that it’s still a great book. One thing I noticed that he talked about a lot of things I later learned through experience. It’s hard to translate some words into wisdom but imho if you can take away one good idea from a book for around $20 it’s a good investment.

Why Nerds are Unpopular

The first essay  has a different vibe. Back then I felt good about hearing that it will be better in the future. But reading it now I feel sad for pg. It sounds horrible what happened in his high school years and I applaud him for opening himself.

In general, people outside some very demanding field don’t realize the extent to which success depends on constant (though often unconscious) effort. For example, most people seem to consider the ability to draw as some kind of innate quality, like being tall. In fact, most people who “can draw” like drawing, and have spent many hours doing it; that’s why they’re good at it.

If you read my posts for a while you probably know that I’ve started to program half-way seriously when I was around 15. Eventually I got pretty good – with around 19. I remember that some people told me that this was my destiny and I was born to program. But I wasn’t really.

When I was younger I began to play the drums. I think I started at 13. When I was 16 some people said I had a natural talent for playing them. When I started I was horrible – just like my programming. But I put a ton of work in it. I played around 2 hours every day at the drum kit, spend time listening to music and played it the beat with my fingers, I read stuff online, etc.

But this investment was small compared to that into programming. When I started half-way seriously at 15 I spent about 1.5 hour per day into programming. This lasted until I was 17. This was the time I switched school. This meant that Monday – Friday I had about 3 hours per day school-related exposure to programming / cs. Furthermore, around 1 hour talking to friends at school, learning or writing code around 2 hours at home and maybe talking another 1 hour on irc. This makes on average 3+2+1+1 = 7 hours a day. This was 3 years, so I spent around 7000 hours engaging to programming.

I would even say that I took longer at the beginning to learn the fundamentals. Or when I first learned Haskell it took forever. I sat there trying to write code to reverse a list (which is super easy). It took me I think about 4 hours. That’s why I like Lisps / functional programming general because you don’t have to be so clever to understand it. It’s pretty simple and less complex imho.

Hackers and Painters

What hackers and painters have in common is that they’re both makers.

I describe the maker as a creator. It’s the same concept, it’s about making something from nothing.

You should figure out programs as you’re writing them, just as writers and painters and architects do. […] It’s unrealistic to expect that the specifications for a program will be perfect. You’re better off if you admit this up front, and write programs in a way that allows specifications to change on the fly.

n.c.

When it comes to code I behave in a way that would make me eligible for prescription drugs if I approached everyday life the same way. It drives me crazy to see code that’s badly indented, or that uses ugly variable names.

This is something I developed over the years. Aesthetics plays a role for me. I want to look at code and it should already say what it does just by the form of it. This why I like Python because it forces you to at least indent correctly.

What You Can’t Say

Although fashions in ideas tend to arise from different sources than fashions in clothing, the mechanism of their adoption seems much the same. The early adopters will be driven by ambition: self-consciously cool people who want to distinguish themselves from the common herd. As the fashion becomes established they’ll be joined by a second, much larger group, driven by fear. This second group adopt the fashion not because they want to stand out but because they are afraid of standing out.

n.c.

Taste for Makers

But if your job is to design things, and there is no such thing as beauty, then there is no way to get better at your job. If taste is just personal preference, then everyone’s is already perfect: you like whatever you like, and that’s it.

A relativistic viewpoint becomes more and more prevalent. pg talks about a more objective standard to beauty. I agree and so does most of science. Even something subjective as the beauty of a face is consistent through cultures and people. I don’t know enough about the subject, yet. So take this with an extra grain of salt.

When you’re forced to be simple, you’re forced to face the real problem. When you can’t deliver ornament, you have to deliver substance.

n.c.

GOOD DESIGN IS TIMELESS. In math, every proof is timeless unless it contains a mistake. So what does Hardy mean when he says there is no permanent place for ugly mathematics? He means the same thing Kelly Johnson did: if something is ugly, it can’t be the best solution. There must be a better one, and eventually someone else will discover it.

Related to this is Occam’s razor. It’s rather funny that you can look at some piece of code and think “that’s looks way too complicated” and you work on it and finally you found that you can make the code easier and in most cases less buggy.

GOOD DESIGN LOOKS EASY. Like great athletes, great designers make it look easy. Mostly this is an illusion. The easy, conversational tone of good writing comes only on the eighth rewrite.

I thought I’ve written about that but I hadn’t. This is a famous concept in Taoism called Wu wei which translates approximately to non-action. However, there are several interpretations of non-action. Here’s a video which explains these as levels:

  • concisely not acting – you observe
  • Patience – you’re not actually doing something actively
  • Flow / Effortlessness – it’s looks easy because the person mastered it
  • Doing without wanting – very spiritual

GOOD DESIGN IS REDESIGN. It’s rare to get things right the first time. Experts expect to throw away some early work. They plan for plans to change.

n.c. – see Borland Software Craftmanship

Nothing is more powerful than a community of talented people working on related problems.

n.c.

Design and Research

Design doesn’t have to be new, but it has to be good. Research doesn’t have to be good, but it has to be new.

I love this. I will just comment on the design part. Reusing good design is a good idea. If we apply that to software development there are obviously design patterns or better OOP patterns. I know there are some database and architecture patterns but I never looked into it. Definitely something I will look into it in the future.

And yet, making what works for the user doesn’t mean simply making what the user tells you to. Users don’t know what all the choices are, and are often mistaken about what they really want. It’s like being a doctor. You can’t just treat a patient’s symptoms. When a patient tells you his symptoms, you have to figure out what’s actually wrong with him, and treat that.

n.c.

To get good design you have to get close, and stay close, to your users. You have to calibrate your ideas on actual users constantly.

This is was bad graphic designer often do. They do aesthetics instead of design. Design follows customer requirements in a sense of ‘what the customer needs’.

In the software world, this idea is known as Worse is Better. Actually, there are several ideas mixed together in the concept of Worse is Better, which is why people are still arguing about whether worse is actually better or not. But one of the main ideas in that mix is that if you’re building something new, you should get a prototype in front of users as soon as possible.

n.c.

Building something by gradually refining a prototype is good for morale because it keeps you engaged. In software, my rule is: always have working code. If you’re writing something you’ll be able to test in an hour, you have the prospect of an immediate reward to motivate you.

I agree and edw519 had an other great way to say this:

I love this example:

I now have a working program[sic] – Woo hoo! You say you want more features? No problem. Let’s start enhancing it.

Write a Comment

Comment