[saddino]

Here's a shorter version: Are you so inspired by a software product or service that you are driving yourself mad thinking about how it was created? Great, do whatever you can to write your own version. Keep at it. Seriously, keep at it. Are you so obsessed with figuring this out that you are unaware that hours are passing by while you work? Awesome. You have discovered a true passion. Now you don't need to read things titled "How to Be a Programmer" because you will drive yourself to become one innately.

For everyone else, go ahead and try to read things titled "How to Be a Programmer" but don't expect it to actually help you, you know, BECOME one.

[GuiA]

Wow, hold your horses cow boy. Did you even read the article? It's about being a programmer in the real world; that is how to communicate effectively, know when to tell management that you think a certain decision was a mistake, how to approach project schedule estimation, and so on.

As a young hacker who's not sure yet where he belongs in the world of tech & science & engineering (worked freelance, worked in startups, worked in research as a grad student, worked in larger companies, and I still don't know what I want to spend my life as a hacker doing :-), I found it extremely useful and well written.

[Ma8ee]

Excellent way to become an arrogant coding cowboy. "My passion is so great so there is nothing anyone can teach me. Just by hacking alone in my basement my innate ability to write efficient and correct code have started to bloom."

[yeukhon]

+1. Your short version pretty much summarize what other 1000 people would say. And that's what I told people who came to my school's open house today: look around you and see what kind of things you wish you could control. You want to be able to get all the files with certain prefix? Figure out that linux/windows command.

The title "A Short, Comprehensive, and Personal Summary". This is not short. It's pretty verbose.

[gknoy]

It's hard to be short and comprehensive. This is shorter than a book, longer than a magazine article. (55 pages: OK, maybe a short book.) "Short" is relative. :)

His coverage of debugging, and how it's critical to overcome fear of breaking things, and of asking the right questions of how things might fail in this way, is a great explanation.