One-liner: Read it. 3.5 stars
I came into this with super high expectations. Things I'd heard people say: "I make everyone on my team read this." or "Every developer should start with this book". So, I thought, "sweet, a great 'back to basics' book... I can't wait!". I read through this book with a host of colleagues all with quite different experience levels and in different areas of expertise.
It was the best of times. It was the worst of times.
Well... maybe not the wo ...more
"Conquer Complexity". High quality code manages complexity. No one can think of all of the levels of abstraction needed to fully understand a program at once; just admit it and try to make your code less complex. Complexity can be managed at every level of the ...more
This second edition is from 2004, and although obviously some of its content may seem a little dated, most of it still holds up well in 2015. Given that context, I find it difficult to find fault with most of the book. Much of the advice given is good advice, and as a programmer, you should adopt and i ...more
После повторного прочтения данной книги окончательно убеждаюсь в том, что данная книга должны быть прочитана, как минимум раз, каждым развивающимся разработчиком, менеджером связанным с разработкой, и тем, кто так или иначе связан с областью разработки.
Мое мнение может быть предвзятым, так как на момент написания - это единственная книга по разработке, которую я прочитал, но могу сказать, что автору удалось пролить свет на разработку как таковую, и мне, как начинающему разработчику она очень пом...more
The book is filled with nuggets of wisdom. Some of my favorite quotes, some from McConnell, some ...more
I mean, it doesn’t even feel like a proper programming book - it’s written in some “Easy way to quit smoking for dummies” style. Every idea is explained verbosely, then illustrated with some numeric stats, then with a 3D chart, then with some real-life anecdote, then with a reference to a 1973 paper, and finally reiterated in a ...more
The second half of the book is pretty much a catalog of refactoring techniques. It's definitely geared towards the aforementioned audiences.
McConnell covers a few other topics, related to design, teamwork, testing, and configuration management, but doesn't go into dept ...more
After spending some time in the industry and facing with harsh realities of software development, I decided to give it a try again. This time I gained much more insight than my first reading. Because now I had a chance to refle ...more
Don't get me wrong, it's hard to find fault with the content itself - all of it is excellent advice, ...more
I bought the first edition, read about 400-500 pages and then the book was lost in a move. A few years later I got the second edition and read it again from the beginning and probably got to something like page 700. I then moved overseas and once again the book didn't make it across the ocean. Therefore, I have to include a small disclaimer that I didn't read the whole book. It is close to 1000 pages.
I don't remember any useless or impractical chapter. The book ...more
So, I finished the other book (Mythical Man Month ...more
The book tackle ...more
The only problem I have with the book is the formatting. It's a nightmare of little quotes, references and key point icons (with a picture of a key - thanks...) cluttering up each page ...more
The new version, Code Complete Second Edition includes content about newer programming techniques, includ ...more
For a recent grad, I think this book will be filled with lots of information that can help the new grad avoid the gotchas that had to be learned the hard way by other people.
I think Steve McConnell takes a fairly pragmatic approach in this book, in that he's for the most part ...more
going to confuse you if you come from a different environment. For example, it took me a while to realize that the term "magic number" was used for hard-coded constants; in Unix, the magic number is used to identify file type as described in /etc/magic. Similarly, the author did not like the indentation standard use by Gnu. There was something he did not like about Kernighan and Ritchie either Overall, I still think it was a decent boo ...more
The author has a lot of experience building big software projects. He has some interesting insights about how the size and quality requirements influence the building process.
I also liked that he quotes results of existing studies and that he gives a lot of references to books and other material if you want to go deeper into a subject.
Only a five chapters in, I can see it's already improving not only my programming skills, but also with how to correctly deal with clients and bosses in order to minimize risk and increase productivity.
More thoughts on it will be posted later.
Many advises are advocated using statistics not only personal feeling
The author tries to take the best from each method avoiding religious commitment to one church
Goodreads is hiring!
Learn more »