Book provide 70 tips covering a wide range of topics from coding, tooling, methodologies, and team working. Target is mostly junior/medior software engineers however even senior engineers will find valuable information (or, in worst case scenario, confirmation about his intuition/experience). A lot of the chapter reminded me about mistakes I've done during early years of developing software (e.g "Dead Programs Tell No Lies"). Author is funny and it's a joy going from chapter to chapter.
Topics are covered from "high-altitude". Author state that covering topics in-depth would require a 10x bigger book (which I think it's an understatement... you could end up with 100x bigger book).

As a junior software engineer I would absolutely recommend going through (at least): "Software Entropy", "The Evils of Duplication", "Orthogonality", "Estimating", "Assertive Programming", "Decoupling and the Law of Demeter", "It's Just a View", and "Programming by Coincidence". For medior most other chapters are interesting.

My favorite topic by far is "Programming by Coincidence" something that I observe in my practice way more than I would like.

For me personally it’s one of the best guides about being a software developer. First it is very motivational and teaches you the right mindset to tackle your work related problems. It also provides a lot of useful practices, that you can see as a toolbox: now it’s up to you to pick the right tools for the job. This book is still interesting to read for the experienced developers, because it’s another way of explaining some concepts, and you might always discover a hole in your knowledge. Some concepts were better explained in Clean Code: for example ‘orthogonality’: I prefer the explanation by Robert C. Martin: “Avoid side effects”.

I think this book is highly over-rated.

Super practical book about maintaining good software design practices and working effectively on software projects. It covers a lot of ground and ranges from fairly basic to more technical (in my opinion), but the tips were connected by a common 'pragmatic' approach which I liked. Will definitely try to implement what I've learned and I'm sure I'll return to this one.

I just finished rereading Pragmatic Programmer. It's still full of great tips, and it was also interesting to recognize how far we've come since I read the book for the first time.

There's a lot of hype for this book, but I'd rate it as merely "ok". It has a lot of basic advice that is probably useful for beginner programmers; however, if you've been coding for a while, most of the advice will sound like common sense.

Some of the advice is actionable, but some is theoretical or ideological; some parts are language and framework agnostic, while others have become quite dated; there are a few bits of deep, meaningful advice, but mostly, the book consists of fairly simple aphorisms. It even has a detachable pull out with all the sayings.

It's an easy read, but rarely rises above the programming analog of "eat well and exercise regularly".

Some fun (and funny) quotes:

"Don't live with broken windows."

"Use tracer bullets to find the target."

"Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system. Think of prototyping as the reconnaissance and intelligence gather that takes place before a single tracer bullet is fired."

"Check their spelling, first automatically and then by hand. After awl, their are spelling miss steaks that the chequer can knot ketch."

"Distributed systems such as EJB are leading the way into a new age of configurable, dynamic systems."

"We who cut mere stones must always be envisioning cathedrals." - Quarry worker's creed

"The limits of language are the limits of one's world." - Ludwig Wittgenstein

Well, I am not a developer/programmer myself and I'm not planning to become one, I just work with people who are programmers. To possibly understand better what are these fundamental things and qualities people who program should have or pay attention to and definitely got a list of things to improve on for myself. Yes, I saw people writing that there are many things that are very obvious and people know this more or less before kindergarten, but having in mind that there are books about breathing, laughing, sleeping etc., this one definitely has the point. There are parts that are crucial for oneself to change into how you might think or approach problems and tasks, or how one might be used to solve challenges. So all in all - good guide book that is definitely not for programmers only, but should be read by ones as well and I'll be recommending this for anyone in a team or workplace who are leaning towards development from other areas or beginning to advance in their careers.

IT галузь розвивається настільки стрімко, що навіть добра книга може стати застарілою всього за кілька років. Власне, це той випадок. Це скоріше набір 100 корисних порад для початківця-інженера, що прибув з безлюдного острова. Для сучасного ж айтівця, вона може здатися простою і нудною. Тут ми бачимо багато очевидних порад, таких як користуватись гітом, писати тести, спілкуватись з командою. Мова авторів досить складна, є переклади технічних термінів (про що автори попереджають на початку), часом мова абстрактна або занадто формальна. Автори використовують приклади з різних мов програмування: Eiffel, Elixir, Lisp, Bash, Python, що з одного боку цікаво, а з іншого - часто код просто прокручується. Приємною родзинкою стали кілька анекдотів та низка фанових прикладів.

Починається з теми "Філософія прагматизму", і це можливо єдина цікава частина, в основному книга дещо нудна. Ключова порада, яку я для себе тут знайшов - завжди мати при собі щось для читання, якусь кишенькову книгу, це гарна ідея. Надмірне прикрашання продукту може навіть зіпсувати його, як за мазками художника може зникнути сама картина. Влучний час влучній темі. Розширюйте контекст. Використовуйте фіча-флаги.

Я можу рекомендувати книгу скоріше через її структуру аніж за якість вмісту. Короткі глави, які можна прочитати під час короткої перерви від комп'ютера, ідеально підходять на заміну думскролінгу соціальних мереж або мобільних ігор.

Як висновок, наведу найважливішу пораду книги за версією її авторів: "У вас є свобода вибору", що можна доповнити словами Мартіна Фаулера - n  "Якщо вам щось не подобається, змініть організацію, або змініть свою організацію"n

I have changed my job after reading this book. So be careful :-)

Эту книгу нужно ОБЯЗАТЕЛЬНО прочитать КАЖДОМУ студен��у, который учится на специальностях, связанных с ИТ. Причём лучше прочитать уже на втором-третьем курсе, чтобы студенты не только знали языки программирования и алгоритмы, но и принципы разработки, чтобы они понимали, что значит «быть разработчиком».

Книга состоит из небольших глав, сгруппированных в разделы, читается легко, авторы не «лезут в дебри», да и в целом книга небольшая, так что с учётом этих причн, я, опять же, в первую очередь рекомендую эту книгу студентам.

Следует учитывать, что книга (в оригинале) написана в 1999 или 2000 году, так что некоторые пункты потребуют пересмотра в плане средств и методи, но тем не менее, почти все они до сих пор актуальны.

(4.0) Good for new programmers

This seems to be a favorite in the office, so before I participating in the recommending of this book to new hires, I figured I should check it out first. There is definitely some good stuff in here, but most won't be new for anyone who's been programming professionally for 2 or 3 years or more. I think most engineers' problems is that they don't do what they know is the right thing.

I think many people have said this before, but at the risk of duplication I'll say that the book contains a lot of common sense codified. The other interesting bits are the 'suggestions' for ways to behave as a good engineer. Thing is many of them feel more like personality traits than things you can 'learn' or 'decide' to do....such as:

* learn new things (languages, editors, frameworks)
* see how things work
* if something's broken find out why, don't just get tests passing
* if you find rotten code, refactor
* try to learn keyboard shortcuts
* write time-saving scripts and tools (like Robert just did! :) )
* automate everything especially testing
* test hard

But if you want to be better and don't do some of these, maybe reading this will remind you how important it is to do them.

Každý, kto knihu prečítal asi tvrdí, že ľutuje, že ju nečítal skôr. Ja nebudem výnimka :) A pritom tam nie je nič prevratné, “iba” všetko dôležité pokope a zrozumitelne. Treba dať do ruky každému programátorovi a znovu a znovu sa k tomu vracať.