Best development book I've read, has no code in it

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!

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.

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.

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 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."

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.

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.

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.

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.

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.

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/

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.

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.

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.

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.

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.