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.
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.
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.
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?
My full review of it is here: http://www.amazon.com/review/R269BBARXH1V6R/
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.
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."
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.
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!
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.
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.
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.
Did you at least read 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.
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.
You can even read the online version free from O'Reily if you want to get a taste: http://chimera.labs.oreilly.com/books/1234000001813/index.ht...
Now instead of looking for my second edition, I'll spend tonight debating if I should get paper, or Kindle version, or both. :)
Speaking of influential books, Peopleware and Mythical Man-month are the most influential software books for me.
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/
Here's a list of highlights that Kindle users have made:
My full review of it: http://www.amazon.com/review/R2OV0TG7MJGXGL/
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.
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.
"Programming with hand tools"
Lots of conference reviews nominated it in their favourite talks too.
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.
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...
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.
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.
I was lecturing a class on UML and Design Patterns to students who had never coded before (basically UML).
The class textbook, lecture notes and lecture slides I was given had a lot of coding examples.
During the 12 week class, I wrote a book on Object Oriented Modeling (staying two chapters ahead for the students) that had almost no source code.
It was a challenge to explain OOM, UML and Design Patterns to students who had no prior coding experience.
I do feel it is totally possible to teach people how to "program" without knowing how to code.
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'.
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.
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.
What were students supposed to be able to accomplish that they couldn't do before?
It was for the BIS program (http://www.rmit.edu.au/programs/bp138). You can get an idea of the program for graduates.
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.
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.
By the way, mutable state is also a design pattern. But it's sort-of invisible in Java.
What is the benefit here compared to learning programming by coding?
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.
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.
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.
Brand says the three enemies of a building are time, money, and water. What are the three enemies of a program?