I am sorry, but for me that book was a no. It just felt like a self help book, but for programmers, which is kind of ok if you are feeling any sort of personal trouble in the field. Not that this is not already told on the back cover, but no, I would not call this book the best development book. I did not buy it, instead, it was the result of participating in a local dev Google something, but it really surprised me how much bullshit the book was full of.
If you are into inspirational quotes, and repeating the same thing over and over again on your head until you believe it to then get into "hacking" fully inspired and into the productive zone, then this book is for you.
Agree, I also dislike the book's pseudo-villification of management, architecture, and anything that isn't typing code in an IDE. I read it, I wouldn't recommend it to others.
Hmmm... in that case may I recommend "The Passionate Programmer"?
The guy who wrote it had a pretty interesting career trajectory - went from being a jazz musician, to a self-taught dev, working his way up to a manager of a large scale outsourced team, to a dev again doing Rails and the like.
It had a feel and structure like Robert Greene's books - little 3-5 page segments focused on one idea, interspersed with personal stories and interviews illustrating the points. It seemed particularly focused on working within a corporate structure in a positive manner.
Have you (or anyone else) read Code Complete? If so, how do you feel about it? I started reading it because everyone recommended it, but I stopped at page 100 or so, because I felt it was getting no where.
Code Complete was overwhelmingly the most influential programming book I've ever read. But it's been around for 20 years, and much of the material has now been rehashed in many other books, videos, forums, blog posts, etc. I think that's what other posters are getting at when they say it's just common sense: this kind of thing is everywhere now.
Much of the book is spent making arguments for and providing evidence for things that are considered obvious today.
So if you stopped because the material sounded obvious and redundant, then maybe it is for you. But if you stopped because the material seemed seemed unimportant or trivial, then I strongly urge you to start up with it again.
Even if a lot of the ideas are also present elsewhere, I still think it is a great book, especially the parts on how to actually write code. For example the chapters on naming, code lay-out, conditionals and methods/functions. I don't know of any other book that covers that as well as Code Complete does.
It is a thick book. But you can still learn a lot even if you don't read it cover to cover. Even if it only makes you a better developer by 0.5%, isn't that still worth it?
Books like these can be quite a shock to a large set of devs out there. Think enterprise code jockeys who don't read tech books or pay attention to what is going on out there and learn everything they do on the job.
I read Code Complete 2 after developing software for maybe 6-7 years in an environment like this. Much of it was obvious, but the rest was a revelation. Same with The Pragmatic Programmer.
Several years later I read a book called "The Passionate Programmer", which was like the book described in this article - soft, career development skills. That was probably the most important book I've ever read. In fact it's how I found out about Hacker News in addition to a whole bunch of different books. It lit a fire in me.
4 years later, I have a career that is so dramatically different I don't even know where to begin. On the same token, I reread that book (Passionate Programmer) recently and it does seem like common sense I would absorbed over time from things I read on HN.
How long had you been programming when you read it? Code Complete and The Pragmatic Programmer had been on my Amazon wishlist for nearly ten years when I finally ordered them a couple years ago. I had the same reaction as you to both. I had already learned all those things through experience. On the other hand, I don't know if the books would have done much good for me ten years ago. Maybe I needed to learn those things on my own, over time.
I think more people read those books and say, "yes, I agree with all of this already" than read them and think, "oh, here is a new thing I haven't thought before and will use from now on."
It's a great book for people who started coding 10-15 years ago.
Since then most of the lessons in Code Complete have become part of the soul of modern languages, frameworks and libraries. So you learn them through proxy.
Still, I still come across people who could learn from reading it again, especially what it says over comments, testing and generally writing legible code.
I was helped tremendously in my early coding days by the section in Code Complete on naming things.
The book is about the tiny details of coding. Getting the small things right, as in any sport or profession, gives you the tools to get the big things right.
But if you are in a section that bores you, skip around a bit!
I think Code Complete is the kind of book that if you don't already know what's in it it's not going to help you and if you do know what's in it it's not going to help you.
That said, it has a lot of solid advice. It also has some less than solid advice which is more of an opinion.
I would still recommend people read it. I also recommend they read the references. I also recommend they talk with other people, look at their experiences, and try to figure things out for themselves.
Adding another thought here:
Some things have to be learnt through experience. You can read a really great book about swimming but it probably won't make you a good swimmer. So that's one thing.
The other thing is that I found the book trying to be very rigorous about subjects where it's simply impossible to do so. There are so many different ways to approach different problems and things like cost vary hugely between different businesses. Sometimes doing things one way makes sense in a given context and not in another. What we need is for people to develop that understanding rather than simply learn some rules.
I read it when I started my first "real" job. Back then it was really influential and had tons of interesting stuff. I usually recommend it to summer-trainees to put on their read-list (not as the first book to read though).
Like many have already pointed out that participating in the HN gets you the same information :) So don't sweat it too much, you already know that stuff.
I do not think it is a book you are supposed to read from start to end. It is more a book you randomly open when you feel bored or tired, read part of random length and then close.
Kind of book equivalent of opening facebook/news for 5 minutes and then going back to work. Except that you learn little bit each 5-10 minutes long session.
Useful information, generally good guidelines, but it very much feels like a book for managers to read, and run through the checklists when assessing those they oversee.
Generally, for a programmer, I'd say skip it. Or pick it up in a library and skim over it, and you'll get 90% of the benefit. And yeah, the whole thing could be condensed into a large blog post / small handbook and it would be immensely improved.
It was a gift for participating in a local Google event, sorry if it wasn't clear enough. By not 'buying it' I wanted to highlight that my opinion on the comment would be inherently negative, as I am not in the target audience of the book (as in, if in a store, I would not buy it).
Yes, I have read it. It is not a terrible book, heck, it might be good for what it is meant to be (guidance for disoriented developers), but it is far away from being the best development book, and thus should not be called what it is not.
FWIW, you're faulting him for a claim he isn't making. He says it's the best development book he's read, not the best development book in general. There's a big difference.
I found Apprenticeship Patterns to be a great book to read in your first few months working professionally (or during an internship). It's had a huge impact on me and is one of the three books I recommend to every new hire that I meet (the rest are here: http://mdswanson.com/blog/2013/05/31/summer-reading-list.htm...).
Some of my favorite sections:
* The Long Road: keep your focus on the long term, value growth over salary
* Find Mentors: seek out and learn from those that are ahead of you
* Create Feedback Loops: how to get useful feedback
* Confront your Ignorance: what to do when you identify a skill gap that you need for daily work
The book is so grounded and feels real. And after having the pleasure of meeting Dave and Ade at conferences, you can tell they are very genuine.
Agreed. The Mythical Man-Month by Fred Brooks is another great book. It is famous for Brooks's law: "adding people to a late project makes it later".
But for me, even better with that book was one page at the end of chapter one, entitled The Joys of the Craft. There, Brooks described what's so great about programming. I really loved that part, and wrote a blog post about it: http://henrikwarne.com/2012/06/02/why-i-love-coding/
Yes! This one should be required reading for anyone managing people or projects. It's a bit like "The Design of Everyday Things" - it isn't necessarily the material in the book, but rather the patterns of questioning and thoughtfulness produced by the book that will stick with you. Peopleware is beyond being a "software" book - it's really about how to create an environment where professionals can thrive.
Seconded! All-star programmers talking about both technically deep topics and general reflections of good work practices and viewpoints on life. A great book for programmers of any skill or type.
Here's a list of highlights that Kindle users have made:
Coders at Work is great - easy to read (but long), with a lot of interesting information. Some sample questions the author asks:
"How do you design code?", "What is the worst bug you've ever had to track down?", "What's your preferred debugging techniques and tools? Print statements? Symbolic debuggers? Formal proofs?" and "As a programmer, do you consider yourself a scientist, an engineer, an artist, or a craftsman?". I think these are all excellent questions, and I learned a lot by reading all the different answers.
Founders at Work is by Jessica Livingston (of ycombinator fame) and Coders at Work is by Peter Seibel (of Practical Common Lisp fame, who took inspiration from Founders at Work).
I first read the few quotes and they made sense. I thought this is good.
Then I went to HN and saw the cynicism. It is one of the moments when am thankful for the cynicism. I should waste my time on something more specialised. It's worrying how naive sometimes one gets until one gets another POV.
I've found woodworking to be an incredible analogy (and also contrast) to software dev. The guy at http://woodgears.ca/ was formerly a software engineer, and I find it interesting how this influences he approaches woodworking.
I want to agree. Watched this just yesterday and really, really liked it. Its a bit slow in the beginning and but it really ties to getter in the end. Better then I first thought.
Its a really important point and I often have trouble explaining this to people, now thanks to this talk I have a much clear handle on what the point is.
It can be used when arguing things like ORMs and things like that.
Is Mythical Man Month that well known that there's no need to even bring it up? Surprised to not see it in this list yet. No code, but reading it will surely influence your approach to software.
One of the best development books I've read is Thinking Forth [1]. Don't let the Forth aspect put you off. It's full of great design tips and ways of thinking about programming.
I can only speak for myself, but I am tired of these "soft" software development books and the various "movements". They seem to be attempts to transform our technical field from solving real world problems via math and deep understanding into something like politics or religion.
I think recent success of these soft topics may be based on people's feeling of self improvement and enlightenment. I can understand that it creates a nice feeling, but prefer to be enlightened by actually learning to solve real things in a more elegant, efficient way than before and I prefer to learn the rest via actual work experience.
Real self-help would mean to become independent from advice from the outside and looking into yourself and finding out how you can do something better by actually doing it...
Values like efficiency and elegance are mediated and determined by the community and the subjective individual. They're neither unambiguous nor universally agreed upon. Even on the very simple, immediate level - is elegance more like readability or concision? Is efficiency a matter of performance or maintainability? Now expand your view to encompass all the problems and questions that come up in the course of your job—the majority of them, as noted above, having more to do with other people than writing better code.
Being better at your job isn't simply a matter of advancing along the numberline of skill and smarts. And unfortunately, many of those who think it clearly is, or can be, are assholes who are lousy at working with others.
> They seem to be attempts to transform our technical field from solving real world problems via math and deep understanding into something like politics
The problem with that perspective, as I see it, is that all cooperative human endeavors are inherently political. You can't "technology" your way out of those dynamics, and you can't simplify your worldview to ignore them because they frequently-enough have real impacts on the work.
So what I see a lot of these movements doing is recognizing and reacting to those dynamics, rather than trying to build solutions based on a model of the world without them.
It is possible with the help of flowcharts and pseudo-code; the issue I've run into many times is depending on the class, you'll lose student interest over not actually doing anything. If it is a matter of limited resources, ala no computers, then go for it, but looking back, I'd feel a little short-changed if I couldn't walk out of the class without a functional program, no matter how insignificant.
This is where I liked MIT's EdX course. Mostly Python interpreter, but around the end you were given a GUI simulation of controlling a Roomba. You wrote the Roomba's logic and then ran the simulation. You could walk away from the class and say 'Look at this... I built this'.
I do agree that there is really nothing to show that you've done: program wise. On the other hand, the students did learn a lot about critical thinking which, I feel, is a great start to programming.
This was also for a BIS degree (not a CS degree) which focused on the "business" side of information science: so most students weren't interested in coding (though I felt this was not to their advantage).
Really, it was a bit the fault of administration for placing the class in the first semester of the degree when students had not taken any programming classes yet.
I'm in the same boat, business side of IS, teaching Visual Basic.
If you don't mind me asking, what textbook did you use (or atleast company)? We use Cengage currently and I'm just appalled at some of the stuff I have to cover. I've been searching for a replacement.
I look at coding as a way of programming but not all programming needs to be done by writing code. There are other ways to program a computing device: a.k.a alter the behavior of a program.
> What were students supposed to be able to accomplish that they couldn't do before?
I don't recall the ILO's (Intended Learning Outcomes) of the class but I do recall one was being able to apply Design Patterns in their analysis and design.
I'm not saying I agree with people designing software systems without also having an ability to code but I do think people can think critically about solving problems using tools like UML without having to code out the solution.
Thanks for taking my somewhat flippant questions seriously. Thinking about design seems useful.
Learning about the `classic' design patterns seems silly. They are basically workarounds for shortcomings of OOP. And if one can not program, one does not need to know about workarounds.
Did you include a study of the Mythical Man Month?
Design patterns exist within all programming methodologies including functional programming, structured programming, etc. In some cases, the pattern is incorporated within the methodology, some within a specific language, some are incorporated within the framework and others are used at the domain level.
Just because a design pattern has become so ubiquitous we don't even know we are using it doesn't mean the pattern does not exist. The iterator pattern has been weaved into languages for both functional and object oriented programming. Java has implemented it at the framework level. Maybe it should not have been done there.
In all cases, this really has nothing to do with shortcoming of OOP (or any programming methodology for that matter). It has to do with allowing us to recognize common patterns of design within software.
> Did you include a study of the Mythical Man Month?
Yes. But not in the above described BIS class. It was in another class in the CIS program.
In my opinion, writing software requires two "primary" skills.
A) A student needs to be able to map real world systems to a computing device. This requires a lot of critical thinking and is basically the process of automating a real world problem.
B) A student needs to be able to code out the problems they have solved above.
Where it gets difficult is that students are usually taught how to code before they are taught how to do that mapping from the real world "thinking" to computer world "thinking". I feel their internal model of programming becomes tainted with concepts like scope, functions, methods, parameters, pointers, lists, arrays, data structures, inheritance, composition and so on. All useful tools, but hard to mentally picture without understanding why the exist.
I look at learning to code before learning to critically solve problems like learning all about a motorcycle without understanding it's purpose: to move you from one location to another. Sometimes, students have ah-ha moments and they would be like "Oh, now I see why we are learning about motorcycles. It is because we've learned about these roads things and we can use the motorcycles to move us from here to there using these road things we learned in a prior chapter".
Where it gets even more difficult is that students are often expected to learn how to think critically to do that mapping thing (A) and at the same time learn to code (B).
In my opinion, the optimal way to learn how to program would be to teach the critical thinking aspects and associated tools in A and then teach implementation (programming) in B (then alternate) with about a two week gap. One class on A, then two weeks later a class on B, then two weeks later a class on A.
This is an iterative approach to learning that allows students to master concepts in software development and then apply those new skill by programming (by coding or other means) solutions in a computing device.
I was thinking more along the lines of IOCCC. No matter how unreadable the code is, if it compiles and runs without grievance, it is superior to most of the nonsensical, god-awful English seen on the web.
> Something like "A Retargetable C Compiler" maybe?
Shit - come back to me in ten years time, then I might be able to answer.
Still one of the best books out there about getting a product out the door. (Showstopper--about the development of Windows NT--is another.) Of course, I may be biased :-) I worked at Data General for about 13 years. I started a few years after the events of the book but knew many of the people portrayed in it, including Tom West.
Haven't read it (still on my shelf), but have you had a chance to read Dreaming in Code? That's the book I would describe as "the best book about getting a product out the door", or not, in this particular case.
It was not written with software in mind, but the core respect for the user translates enormously well. If you can't tell whether you should push or pull a door to open it, it's the fault of the door designer, not the door opener. This translates very deeply into interface (user or technical) design.
General subject is correct: the more code is pasted in the book - the lesser value it usually is. These 1,200 page overpriced heavy monsters in a bookstore are usually sheer waste of paper.
+1, the principals of optionality and bimodal strategies apply very well to development, and help to explain things such as the dramatic rise to prominence of Github (similar to Taleb's Hydra analogy).
Also Zen and the Art of Motorcycle Maintenance, although a bit dated and often dismissed as hippy pseudo-philosophy, has some very practical aspects about mental approach to technical problems, dealing with "gumption traps" etc.
Good for dev, even better for ops. Controlling risk is central to day-to-day ops work, and the book gave me many useful insights about large-scale and distributed systems behavior, and just generally about what happens when things are pushed to their limits. Highly recommended.
Non-code books for programmers? I always recommend How Buildings Learn, by Stewart Brand. It's a well-written and elegant study of the lifecycle of buildings, and holds many lessons for anyone who realizes their software continues to exist and change.
The best development books almost always have no code in it. Success or failure of projects is mostly caused external constraints, pressures and relationships and learning control those factors, and not the specific technologies/programming languages themselves.
This is a prime example of someone spending a lot of care on making their blog very pretty, and then desperately filling it with whatever they can so that someone will click the link at the bottom and give them a job.
I have not read it but "The Pragmatic Programmer" remains the best development book for me. Interesting how the "Apprenticeship Patterns" compares to it?
It is a common misconception that to be programmer one should read lots of books. It is as wrong as to say that in order to learn to swim or ride a bicycle one should read books instead of trying.
Only code by the very best people (Abelson & Sussman, Norvig, PG, Armstrong, Marlow, Odersky) is worth reading. Common crap found on blogs (especially about Haskell or Lisp) or github (especially PHP and Ruby code) does only damage by giving a very wrong impression of what programming is really.
There is a good hint: read the standard library of "extraordinary" programming languages - Lisp, Smalltalk, Haskell, Erlang, Scala and, sigh.. Clojure)
But the very same law holds for any art, be it poetry or music composition, or fiction - 95% is just stuff, a mediocre crap.
btw, ''The Mythical Man-Month'' has no code in it.) And the first two chapters of ''The Programmers Stone'' (which are the only worth reading) has no code in it also.
There is some value in being able to read non-expert code, you're more likely to run into non-expert code during your day to day job. Someone like Abelson, or Armstrong, will write clearer almost effortless code. Someone at work may spend a thousand lines trying to munge an associative array out of a database result. You have to be able to read both.
If you are into inspirational quotes, and repeating the same thing over and over again on your head until you believe it to then get into "hacking" fully inspired and into the productive zone, then this book is for you.