I've finished reading "Founders at work" (www.foundersatwork.com) by Jessica Livingston during the past holidays. It's been a very interesting read. There's two reasons why I liked this book.
First, it is a valuable resource concerning IT History, a topic I am fond of. As a matter of fact I think anyone should know well the history of his field of expertise. The lack of chronological references in the computer science courses I followed at school didn't allow me to understand properly how and why technologies (languages, hardware architectures...) rises and falls.
Second, this books shows that there's no magic recipe for a successful product or business. Some founders are technology enthusiasts, some are driven by money only, some wanted to succeed, some just wanted to have fun. This results in very different companies almost all achieving some success.
There's a particular excerpt I particularly liked from the interview of Philip Greenspun, co-founder of ArsDigita, it sums up what are my thought on the job of software engineer (and why I insist not to be a programmer).
To my mind, a programmer is not an engineer, because an engineer is somebody who starts with a social problem that an organization or a society has and says, "OK, here's this problem that we have - how can we solve it?" The engineer comes up with a clever, cost-effective solution to address that problem, builds it, tests it to make sure it solves the problem. That's engineering. If you look at civil engineers, architects, they're all dealing directly with the customer and going through the whole process.
[...]
I want them [computer science students] to be able to sit with the publisher of an online community or an e-commerce site and say "OK, I've looked at your business and your goals; here are some ideas that we can bring in from these 10 other sites that I built, these 100 other sites that I've used." And be an equal partner in the design, not just a coder.
[...]
I was very careful about trying to encourage these people to have an independent professional reputation, so there's code that had their name on it and that they took responsibility for, documentation that explained what problem they were trying to solve, what alternatives they considered, what the strengths and limitations of this particular implementation that they were releasing were, maybe a white paper on what lessons they learned from a project. I tried to get the programmers to write [...].