Monthly archives: March, 2007

The Pragmatic Programmer: The review

The Pragmatic ProgrammerDue to the depressing previous post, I thought I had to do justice to the book, avoiding some comments about my career, and focusing on a good review of the book.

The book starts with the DRY principle (Don’t Repeat Yourself), and the authors remind this among the pages. The idea is trying to avoid the repetition of the information. It’s not only referring to the code (don’t repeat functionalities, create modules, avoid coupling, etc). But they look at a wider vision: the client requirements doc, the code, the database scheme… all reflect the same information. When something changes in the database, normally you have to change something in the code… so you are repeating information, and maybe it could be better to find a way to avoid this. The book explains a lot of inspiring ideas for helping you with this stuff.

It also speaks about a lot of engineering related processes. Ideas about prototyping, debugging, testing, requirement capturing… and, of course, programming. In my opinion, the most important thing in this book are not the individual tips, but the big picture. It is showing a sort of philosophy, an interesting one (to follow).

A must in an engineer’s bookshelf!

A pragmatic programmer

The Pragmatic ProgrammerI’ve finished the reading of a brilliant book: “The Pragmatic Programmer“. It’s a collection of really wise tips to help you becoming a better professional. I already follow some of their recommendations, but most of them were new for me. All were really useful, and I could’ve figured out some of them. And this is probably the reason that this book has made me feel a fairly bad programmer. I’m feeling a bit depressed!, regarding to my professional path, not being proud of some of my works, getting angry with myself, and with my university teachers.

Let’s start with the latter (angriness with university teachers), with an example. When I was studying in the University, we had a subject about compilers. In the practice exercises we had to build, using lex/yacc/bison (Unix utilities to create analyzers), a compiler to convert from a programming language (invented by the teacher) to a stupid assembler language for a stack-based machine. The problem was that those examples, with that such stupid language, created on me the idea of “lex/yacc/bison are useless utilities”. Why they didn’t show me some real examples of interesting use? Now, I read some suggestions in “The Pragmatic Programmer”, in which the authors recommend the use of these utilities, and I feel tricked by my teachers. I’m a bit angry with them, although they did a good job… but maybe they were a bit soft with us, or maybe they didn’t induce us to be real programmers. Anyway, that was university times, and now I’m discovering that some of the most (previously considered) stupid subjects are now the most interesting ones.

On the other hand, sometimes I’m not proud of my work, because I think I could’ve done better. I’m just finishing a project, and feeling I should re-start it from the beginning with a new focus. Maybe I’m a perfectionist, or maybe I learn a lot while developing a project, and when I finish it I feel that it is outdated. But, regarding to this book, I would like to apply some of those tips to my past projects, and they have probably finished in a better way.

I have a lot of doubts about my professional path. I’m not sure if it’s better to work alone, or in a small company (just my current status, with 3 department mates, without heavy standards or follow-lines), or a big company (with strong standards). Also I’m thinking of joining an open source project… but my time is not unlimited, and I usually arrive at home quite tired. Anyway I’m trying to shape up my professional skills, reading more technical books, learning a lot of methods, peeking some new languages, and trying to be up to date on the new technologies. Is this enough? Never is enough regarding to knowledge! This is the road.

Technical books are too big (=uncomfortable)

Smurf villageSometimes I’d like to have technical books in “smurf-size” format.

In the last months I’ve been reading some interesting books, but the reading experience was handicapped due to their uncomfortable format. Why do technical books have to be so big? It’s quite impossible to carry them and read on bus, or even in bed. It’s totally uncomfortable!

“Professional JavaScript for Web Developers”, “Ajax in Action”, “Designing Interactions” are interesting books, but maybe the authors can leave some information out, and make smaller books. But it seems that if you don’t break you arm while carrying them, they are not good. The only exception (of size) in my tech book list is “In the beginning… was the command line”, which is pocket-size (well, despite this name format, it doesn’t usually fit in my pocket), and it’s not really a tech book, but an essay.

Anyway, in other subjects the size of the books doesn’t matter, trust me! For example, I have some Go books, and most are pocket size (and some of them really are “pocket size”)… but the most interesting thing is that they are over-filled with information. Moreover, due to their useful size, you finally spend more time with them (reading and re-reading), carrying them everywere. The reading experience is really enjoyable!