Программист прагматик руководство юбилейное издание к 20 летию выхода книги

While many complain about already knowing everything in the book, or that it’s outdated, I believe they are quite missing the point. Perhaps this book didn’t speak to you at the point you are at in developing your skills and crafts, but it might speak to someone else just beginning. Rating the book low for the reason it wasn’t what you needed is rather disingenuous, as a rating should be a guide to the quality of the book overall.

The information contained in this book is essential for software developers who want to develop their skills and knowledge into a craft worthy of renown, to become masters of the field. It is essential for anyone working in a team or working solo.

The book is dated in the specific examples it uses, as would any book become so dated. What is *not* dated are the principles, the tips, the stories, the **wisdom** of this book.

As I was reading it, it felt all so familiar. Yes, most anyone who has been at the craft of software development will probably recognize much of this. I felt like the authors had been following me around during my consulting practice in the 90s as they pull from the same stories, lore and practice that I taught. Reading this book now, in 2012, I recognize all this and am grateful for the review. One may know a lot of practices, but having a refresher on the extent of what matters in software development helps.

As I approach a new team, a new job, I am looking to convey a lot of these concepts to people who may have only been cursorily exposed to them, and develop the team into a high quality, high craftsmanship group. This book will aid in that quite a bit, I hope (although the Russian translation may be lacking).

If you are just starting out, read this book.

If you are in the midst of your career, read this book.

If you are an experience veteran of the craft, or feel yourself a master, read this book, THEN TEACH IT.

This is essentially a self-help guide for programmers, the kind of book that enumerates the habits of Good and Happy People and makes you feel slightly guilty about not practicing most of them, but probably won’t result in you forsaking your evil ways and stepping on the path toward Nirvana. Hunt and Thomas are friendly but occasionally annoying gurus. Their cloying metaphors (boiled frogs, etc) and kitsch jokes are offputting, and some of their advice borders on insult. One assumes that when they devote a whole section to interpersonal communication that they are targetting the particularly closeted and uncouth breed of computer geek recently emerged from the dark and brutish cave of high school, struggling to make headway in a world full of messy, inconsistent, emotional people who don’t even know how to reverse grep an Apache log.

That said, I think there are nuggets of good advice for everyone all over the book. Programming, like reading and writing, is ultimately a private, personal activity, and to be honest, most of us software engineers were that closeted high school nerd at some point, and draw upon that focused, single-minded persona when we do things like coding, so there are lessons to be learned from taking a step back occasionally and examining the craft, as Hunt and Thomas do. They are, as I said, occasionally infuriating, but even their silly aphorisms and mantras are usually memorable (what software engineer isn’t constantly trying to stay DRY?). I’ve no doubt I’ll be flipping through it again in the future, especially when I feel like I’ve hit a wall, fell in a rut, or found myself exploiting tired and hackneyed idioms that don’t do the English language any justice.

I no longer have any need for mentors or friends now that I have AVClub (the AVQ&A and «Gateways to Geekery» columns in particular), Quora, and Stack Overflow.

Case in point: That I found this book. Over the past couple of years I have been gradually writing and less-gradually maintaining a code base for separate projects. It’s getting the point where I might as well figure out what the hell I’m doing. So I go to Stack Overflow and find my way to a question like «What programming book do you wish you had read early in your career?» This book is the top answer.

The think I like about this book is that it is very high level and it makes a lot of sense. They make their point and move on. But that doesn’t mean they aren’t touching on some key issues in knowing what they hell you are doing. When I found myself thinking, «yeah yeah,» that’s when I knew I needed to slow down and pay attention. Unlike most books on coding, this one has aged/will age very well.

Out of the many good points made in this book, three of them are my main motivation lately:

1. Don’t keep separate copies of important code or data. Eventually they will get out of sync and lead to madness. (This is summed up as the DRY principle: Don’t Repeat Yourself.)

2. Automate everything possible. If you are following (1), you will wind up doing (2) out of necessity.

3. Keep everything, even the dinkiest script, under source control. With tools like Dropbox that have a «packrat» option, this is easier than ever. But a formal source control system is preferable.

With these three principles you can pretty much bootstrap yourself to any level of competency. Now I look at the regular manual tasks that I perform (and others perform) with utter disdain. And I understand why Doc Brown automated feeding his dog in Back To The Future. It is the only way forward.

I bought this book to read on a flight to NY. But I found it so motivating that a few chapters into the book I got out my laptop and started implementing the ideas that were popping in my head. Good stuff.

(Their love of Perl strikes me as a little misguided, but who am I to judge?)

Who is this book for?

Certainly not for experienced, skilled software developers. Considering myself at least experienced, I found most of the material in this book a rehash of methodologies and techniques I’ve used for more than a decade. Granted, there were a few gems here and there, but mostly I was bored because I didn’t learn anything new.

One has to respect that this book is from 1999, so in that perspective, it must have been quite ground-breaking. Had I read it in 1999, I wouldn’t have known any of these things.

The question is, though: would I have been able to use this book for anything back then? While I found myself agreeing with lots of advice given in the book, I also found that the reason I could agree with so much is that the advice is so vague that you can read your own interpretation into it.

Perhaps you could view that as a strength of the contents. It attempts to plant a lot of seeds into the readers’ minds, without ever being prescriptive or dogmatic. In that sense, it lives up to its titular pragmatism.

Still, it leaves me with the feeling that if you don’t already know how to work in this way, will you be able to learn it from the book? I don’t think so.

As an overall observation, it seems that most of what the authors call pragmatic programming is simply what’s later become known as agile development. Thus, I have much respect for the authors; in 1999, they were certainly at the bleeding edge of modern software development (perhaps they still are today), but I don’t think the book stands the test of time.

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

For a total beginner, the concepts will be difficult to internalize. For a seasoned programmer (on a good team…), it will be little more than a general reinforcement. While it’s hard to imagine the right time in one’s career to read the The Pragmatic Programmer (probably, often), it’s a classic. It’s written at a high enough level that very little material is outdated. In fact, some of the arguments ring much truer now than they would have in 1999.

See this review and others on my blog

کتابی که هر برنامه‌نویس باید بخونه! شاید این جمله خیلی تبلیغاتی باشه، راستش قبل از این که خودم این کتاب رو بخونم، وقتی این جمله رو در مورد این کتاب شنیدم چنین حسی داشتم‌ اما الان به جرات می‌گم که این جمله، اصلا تبلیغاتی نیست و یک توصیه حرفه‌ای است.
بخشی از حرفهای این کتاب رو، قبلا در کتب دیگه، بعضا با ادبیات تخصصی‌تر خونده بودم. مخصوصا در حیطه تست و ریفکتور. اما خیلی از مباحث تازگی داشت. به ویژه مباحث مربوط به حوزه مدیریت پروژه، چگونگی همکاری تیم، چگونگی ارتباط با کاربران و …. بسیار جذاب و اثر گذار بود.
من ویرایش اول کتاب رو نخوندم اما برای من بسیار جالب بود که نویسنده‌های کتاب، بر اثر بیست سال تجربه، بعضی نظرات گذشته خودشون رو نقض می کردند و اعلام میکردند که اشتباه کردند و بعد، بر اساس تجارب جدیدشون اطلاعاتی رو در اختیار خواننده می‌گذاشتند.
مثالهای ملموس کتاب، خواننده رو در درک بهتر کتاب یاری می‌کرد.
در مجموع کتابی است که توصیه می‌کنم بخونید. حتی اگر ویرایش اول رو خوندید، حتما ویرایش دوم رو مطالعه کنید. خیلی دوست دارم بعدها، مجددا این کتاب رو بخونم و ببینم چقدر تونستم توصیه‌های کتاب رو، عملیاتی کنم.

This is my favorite non-technical tech book. It explores good software development practices. In my opinion it is more than just a checklist of what you should do — it literally changed my approach to development with positive results.

Others have mentionned that they already knew most of the things in this book, and practice these good habits in their development environments. I’ve worked in dozens of environments ranging from very successful experienced companies, to fly-by-night operations that have no business writing code. Any one of these environments would have been vastly improved if some of these practices were incorporated. (And in several environments, I was able to introduce some of these concepts which led to increases in productivity and happiness)

If you and your organization already does everything in this book, and you see it as a «ho-hum» read, congratulations to you. For the rest of us, I think this is chocked full of high-level abstract concepts that will improve any development environment. It’s communicated in a very straight-forward manner, and also advises you to take a pragmatic approach to everything — only using the things that make sense in your situation.

Overall, a wonderful book.

I didn’t like the structure of the book. Some of the concepts were vaguely presented. I was also bored a little bit while reading it.

Some notes
Chapter 1. A Pragmatic Philosophy
Tip 3: Provide Options, Don’t Make Lame Excuses
Before you approach anyone to tell them why something can’t be done, is late, or is broken, stop and re-evaluate
Tip 4: Don’t Live with Broken Windows
Don’t leave «broken windows» (bad designs, wrong decisions, or poor code) un-repaired
Tip 5: Be a Catalyst for Change
Start with something, (hot water with stones to make a soup) and slowly people will be adding ingredients to your water and see how useful it can be
Tip 6: Remember the Big Picture
Constantly review the project, look out for the big pig picture, things can deteriorate pretty fast
Tip 7: Make Quality a Requirements Issue
Good software today is better than perfect or great software tomorrow, give your users something to play with and evolve from there
Tip 8: Invest Regularly in Your Knowledge Portfolio
Learn a new language, read a technical book every quarter, read non-technical books too, take classes, participate in local user groups, stay current, experiment with different environments
Tip 9: Critically Analyze What You Read and Hear
Tip 10: It’s Both What You Say and the Way You Say It

Chapter 2. A Pragmatic Approach
Tip 11: DRY—Don’t Repeat Yourself
Duplication can happen when it’s imposed by the environment, when developers don’t realize they’re duplicating code, when we get lazy, code duplicated across different teams
Tip 12: Make It Easy to Reuse
Through the following:
Tip 13: Eliminate Effects Between Unrelated Things (Orthogonality)
unrelated modules should be self-contained and independent, if you change one, the others shouldn’t change dramatically
Tip 14: There Are No Final Decisions (Reversibility)
Tip 15: Use Tracer Bullets to Find the Target
get the code out there
Tip 16: Prototype to Learn
Prototyping is a learning experience. Its value lies not in the code produced, but in the lessons learned. That’s really the point of prototyping.
Tip 17: Program Close to the Problem domain
Tip 18: Estimate to Avoid Surprises
Tip 19: Iterate the Schedule with the Code

Chapter 3. The Basic Tools
Tip 21: Use the Power of Command Shells
Learn some shell
Tip 22: Use a Single Editor Well
Tip 23: Always Use Source Code Control
Tip 25: Don’t Panic
Tip 27: Don’t Assume It—Prove It
Tip 28: Learn a Text Manipulation Language

Chapter 4. Pragmatic Paranoia
Tip 30: You Can’t Write Perfect Software
Tip 31: Design with Contracts
The caller must not pass variables which violate the conditions (example: sending negative numbers to sort). It’s not the responsibility of the method itself.
Tip 32: Crash Early
Tip 33: If It Can’t Happen, Use Assertions to Ensure That It Won’t
Tip 34: Use Exceptions for Exceptional Problems

Chapter 5. Bend or Break
Tip 36: Minimize Coupling Between Modules
By following the law of Demeter: (a function should only act on it’s parameters, objects it creates, methods in the object it creates)
Symptoms of ill-code: (Developers afraid of changing the code because they’re aren’t sure what might be affected)
Tip 37: Configure, Don’t Integrate
Tip 41: Always Design for Concurrency
Tip 42: Separate Views from Models

Chapter 6. While You Are Coding
Tip 44: Don’t Program by Coincidence
plan, document, test
Tip 45: Estimate the Order of Your Algorithms
Tip 46: Test Your Estimates
Tip 47: Refactor Early, Refactor Often
«Don’t try to refactor and add functionality at the same time.”
“Make sure you have tests first!»
Tip 48: Design to Test
When you design a module, or even a single routine, you should design both its contract and the code to test that contract
Tip 49: Test Your Software, or Your Users Will
Tip 50: Don’t Use Wizard Code You Don’t Understand

Chapter 7. Before the Project
Tip 51: Don’t Gather Requirements—Dig for Them
Tip 52: Work with a User to Think Like a User
Tip 53: Abstractions Live Longer than Details
Tip 55: Don’t Think Outside the Box—Find the Box
Is there an easier way?
Are you trying to solve the right problem, or have you been distracted by a peripheral technicality?
Why is this thing a problem?
What is it that’s making it so hard to solve?
Does it have to be done this way?
Does it have to be done at all?
Tip 56: Listen to Nagging Doubts—Start When You’re Ready
But how do you tell if you’re procrastinating or if it’s a good judgment to wait?
A technique that has worked for us in these circumstances is to start prototyping. Either you’ll be bored and start doing the real work or that you realize something isn’t right and you’ll find a solution
Tip 57: Some Things Are Better Done than Described
As a Pragmatic Programmer, you should tend to view requirements gathering, design, and implementation as different facets of the same process—the delivery of a quality system. Distrust environments where requirements are gathered, specifications are written, and then coding starts, all in isolation

Chapter 8. Pragmatic Projects
Tip 62: Test Early. Test Often. Test Automatically.
Tip 63: Coding Ain’t Done ‘Til All the Tests Run
Tip 65: Test State Coverage, Not Code Coverage
Tip 66: Find Bugs Once
Tip 67: Treat English as Just Another Programming Language
Tip 68: Build Documentation In, Don’t Bolt It On
Tip 69: Gently Exceed Your Users’ Expectations
take the extra mile
Tip 70: Sign Your Work

More like 3½ stars. I mean, not a bad book at all, and I’d probably recommend this to a young graduate getting started in the field of professional software development for LOB (Line of Business) applications, or someone who’s been working for a while and feels like getting stuck, e.g. not making much progress. There’s some solid advice from the authors who have 30+ years of experience in developing software, and I agree with most of it, though I find most of it unoriginal (still, curating and compiling experience, when done well, is a worthwhile effort).

The thing is, the book is a mix of many sub-fields of software development and doesn’t go into much depth. More a like a limited and lightweight survey. Of course, if you haven’t yet come across techniques and concepts such as property-based testing, FSM (Finite-State Machines), BDD (Behavior Driven Development, Cucumber, etc.), DSLs (Domain Specific Language), Reactive Manifesto, Functional Programming, challenges of concurrent programming, etc. those parts of the book can be an eye opener, provided that you venture into more in-depth research about these.

Another weird thing they do: jumping from one language to another for very short code snippets, e.g. using Ruby, Elixir, Rust, JavaScript… I can understand the reasons behind this approach, but still it presents somewhat ad hoc view, making it difficult to form a more unified view.

As I said in the first paragraph, I can recommend this to software developers just getting started, or people who think they’re stuck in a limited domain / set of technologies + ways of working and want to see if there are better ways. On the other hand, if you’ve worked in a modern and intensive software technology environment for more than a few years, building complex applications and data solutions, and if you’ve followed ongoing trends even minimally, you’ll most probably be familiar with most of the stuff in this book.

In fact, it’s a good book… if you’re just beginning to program. I’ve just read it late, so it contains nothing new to me. I can’t imagine that there are software developers who don’t know about practices described in this book. Besides, it’s already outdated (RCS? Really?).

As to Russian edition of this book, it’s translated very badly, it’s almost unreadable.

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

Originally posted here: https://erkinunlu.net/books/pragmatic…

8 out of 10 this time around.

I read the original book around 8-9 years ago. To be honest, it probably defined the engineer I am now, back then. I was kind of devastated with my first two professional experiences back in Turkey where there were either no engineering practices at all or if any, done poorly. So in the absence of a better example, this book is one of those books that I used to teach myself what software development profession must be like. The insights I got were definitely invaluable. For the 20th Anniversary Edition, Dave and Andy more or less rewrote all of the book and added some complete new sections to it (really good for my money). I still enjoyed the book a lot but this time I’ve seen some parts of that are a bit off to me which I highlight below. «**The Basic Tools**» section is still essential to all levels of software developers (with some minor exceptions).

## The good

— First of all, a confession: book starts its argument that as software developers we are responsible for our work and we should care about it, question it, and explore better ways of doing it all the time. This is a good wake up call to a cynical software engineer like me : ).
— The major benefit I got back then and also this time around is the concept of Tracer Bullets. Even though it’s a military term, this concepts explains the importance of implementing a thin layer for the final application in an end to end fashion, thereby unearthing most roadblocks that can happen along the way in one go and gives the team a solid footing in the start of the project and what may happen next.
— Another major concept is the infamous «No Broken Windows» theory applied to software projects. This theory has its origins from the last years of the crime surge in United States (has had much worse implications for the ordinary and poor people by the way). When applied to software projects, this idea suggests that quality throughout the whole project must be upheld all the time, meaning all code should be easier to change, no coupling, orthogonal modules. And this brings us to the next topic below:
— Book really emphasises the importance about **testing**. To this end, it even goes on and destroys one of its staple ideas: **Don’t Repeat Yourself**. There are more than a handful of sections dedicated to testing.
— Andy and Dave neatly summarises what it means to be **Agile**. They reiterate the famous «interactions with people over processes» and others and explain in more detail. It’s really nice to explain that «agile» is not about tools and documents etc, but how you do your work. More on this on the other side below though.
— Functional programming is explained much better in this version. Authors explain the notion in Transforming Programming section, liken the idea to pipes in terminals (which is of course spot on), which also decreases the coupling in the system. Not sharing the state, another benefit of FP is also discussed in detail.
— The book further delivers blows to Object Oriented Programming with its «Inheritance Tax» section. This is again an established notion which some people also call «Favour Composition over Inheritance». I hope that more people would come to the idea that OOP is not a silver bullet and should not be the first go of every software project out there.

## The bad

— At one point Dave confesses that he doesn’t write tests anymore! He justifies this with the fact that he is now a master programmer therefore, he doesn’t need to write the tests, he writes his code «testable» anyway, meaning that the software he produces is already loosely coupled and well though out with edge cases and contracts and so on.
— Even though I really like think that agile practices like estimations and user stories and others help with most of the corporate software we are building these days, authors should have asserted that some practices preached here is also not «One Size Fits All» ideas. This is still a minor point anyway.
— Furthermore, there’s this nice concept of «Design by contract» which is a good precursor to Property Based Testing. But how to breach the gap between User Stories (which are vague statements basically) and «Contracts» (which is literally human language way of writing mathematical properties) is a bit left out. You might simply deduce from the fact that if you are Agile, you’d be talking to your user all the time, but I still think this constant communication with users is a waste of time for everyone involved.
— Despite the fact that (arguably) most of the audience of this book will be American readers, I found the tone a bit too American and prophet-like (of course you cannot compete with Bob Martin in this regard).
— There’s just too much in the book. This makes it a bit hard to concentrate on what really matters (there are 53 topics inside the book!). I wished the authors would just pick up the core ideas and explain them in lengthier detail to make the point across better.

Today is the age of pragmatic programmers not programmers. What it takes to turn a programmer into a pragmatic programmer is subtly described in this book. Although it is primarily intended to be read by programmers, what I found down the line was an invaluable set of insights for life alongside programming. It’s not even an overestimation to say at some points the psychological side of this book takes precedence over its programming side. We’re primarily programmers of our lives, so generalizing correspondent terms to both life and programming is not surprising.
Pragmatic programming stems from a philosophy of pragmatic thinking.
Setting the priority on the philosophy of pragmatic programming, the author sets the tone for an interesting voyage through the principles of pragmatic programming.

Taking responsibility is the first steppingstone in this voyage. When you take a responsibility for performing a task and its outcome, you’re held accountable for it. So take the responsibility. You can find valuable insights all over the book and it sounds impossible to share all of them in a single review.

Then the book takes a pragmatic approach by defining a set of important terms like Duplication, Orthogonality, Reversibility and etc which are described in detail as steppingstones to set the big picture(the software) always strong.

While coding: There are worthwhile steps to take along coding which are subtly presented in this book. Here are some:
Programming by coincidence: The overconfidence generated under programming by coincidence spells a dangerous point. It’s analogous to our own set of behaviors. There’s an overconfidence generated under cognitive ease, which spells a danger point in our judgments, programming by coincidence also takes the same process. The remedy is in a consistent effort to understand the exact procedure and process of each part of code.

Refactoring:Refactor Early, Refactor Often
Refactoring takes courage even in programming. It takes courage to return and claim some of your overrated assumptions and change paradigms , but the supremacy of refactoring shows its role in long term. Clearly, refactoring is an activity that needs to be undertaken slowly,
deliberately, and carefully. Since you’re setting up new structures, you have to consider refactoring a serious thing.

There are also some valuable insights to take before the project and in pragmatic projects.
Overall there is an analogy to draw among pragmatic teams and projects.
They comprise an interdependent set of independent parts. Each part is independent in its core and overall these independent parts are interdependent to set a stronger process.

As a software engineer with many years of experience, nothing in this book was new to me yet I’m rating it 5 stars because I can at least verify that the topics discussed in this book are all extremely important especially to those who are just starting their journey. It’s quite easy to get cocky as a junior software engineer and forget about the most important thing there is for us: we’re here to solve problems and deliver quality products to our customers. That’s it. And this book is very successful at explaining everything you need to get to that point.

I think I highlighted like 90% of this book.

As old as it is; it is still very relevant.

I highly recommend it.

The beautiful thing about a book like The Pragmatic Programmer is that it sparks ideas when you read it. Can you do something more efficiently? Can you do it more elegantly? Can you make the computer do the work instead?

I like to think that I already ask myself those questions all the time. Nevertheless, I found myself reading a page or two and then having to stop because I was having a great idea and needed to write it down. I filled six sheets of letter-size paper with dense, cryptic notes. That’s six pages of Great Ideas about software. Many of them had absolutely nothing to do with whatever I was reading in The Pragmatic Programmer at the time. The ideas bubbled up from the bottom of my brain like swamp gas.

The experience was as effervescent as it sounds. And completely invigorating. I ended the day with a finished book, those six pages of notes, and a whole new enthusiasm for my software projects. I should read these non-language-specific programming books more often!

I’ve loved the «broken windows» theory from the Software Entropy section in the first chapter since I read the excerpt online years ago. I’ve still never heard a better explanation of what happens when code quality and clarity starts to deteriorate. The message is clear: don’t let problematic code sit and rot. It’s not going to get better on its own.

I love the emphasis on DRY («Don’t Repeat Yourself») and the use of simple, elegant tools like domain-specific languages and plain text.

Another real stand-out for me was the Tracer Bullets concept from the second chapter. It’s a wonderfully visual metaphor for building enough of a software system so that you can demonstrate its functionality completely from one end to the other (i.e. multiple pieces of a system all working together, but supporting a minimal number of features). What I love most about a tracer bullet system: you will probably end up with something you can demonstrate to non-programmers! In my experience, that’s a huge benefit.

There’s a large amount of ground covered and nothing is covered in depth. Which is great. I appreciate the low page count and Hunt and Thomas supply examples to make each concept clear. It’s an information-rich and idea-rich book. You could do a lot worse than to simply follow all of its avenues and master them. Much, much worse.

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

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

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

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

A great non technical book that goes into codifying the good practices about software development. It is a must read for neophytes in software industry with a couple of years of experience.
If you have worked or are working in a good team and good project, you can easily relate back and forth about the goof things that are talked about.

It is simple to read, still relevant in 2016 and is worth investing couple of weeks to read this if you are aspiring to be a pragmatic programmer.

This was a great book for programmers to read. It had a lot of very general, yet very useful advice for programmers. I loved the broken window theory of programming. Malcolm Gladwell argues the same theory cured New York’s crime wave in the 90’s in Blink

It is a great book every software developer, architect, designer or even QA engineer should read. It focuses on principles and giudance so it may feel like it MISSES some level of details.

When I started my IT learning journey almost a year ago, this book constantly popped up as the recommended first read to all programmers, no matter their level. Because I was so overwhelmed with all new coding «things», like definitions, principles, syntaxes and good practices, I simply avoided a new headache of responsibly researching what should come into my «future IT reading list» and just took this «mainstream must-to-read». I. e. «The Pragmatic Programmer».

Admittedly, I wasn’t hoping much from it. Most of all, I was anxious that my low-level understanding of this field will make it impossible for me to read and understand all that gibberish stuff in the book Yes, I haven’t understood many things but I understood many others!

«The Pragmatic Programmer» is very comprehensive and it gives a broad view of the industry and touches on many different aspects of the path chosen by programmers. It’s not strictly technical, the book talks about general principles and patterns of how to approach technical aspects/ problem solving, about many «soft» aspects of this field, and gives many tips on how to enhance your performance.

Many things were new for me and I faced them for the first time ever in my life but I said to myself that that is fine. Now I get 10-15%, the next time when I will be reading it will reach 30%. Early on I decided that this book is one for re-reading because it should award readers with different things at different stages of their «technical» growth. For now, it helped me to understand the scope of this field and shaped my mindset on how things should be done by pragmatic programmers. The next time I’ll understand technical aspects better and somewhat in the future, I believe, this book will be helping me to become a highly professional software developer … Oh, it seems, that escalated quickly

In any case, «The Pragmatic Programmer» covers many topics and proposes a guiding hand while navigating this binary jungle. It doesn’t dive that deep into every topic but it shows you what you should know. And the rest of the digging is on you

So, yeah, if you are interested in the IT industry and you also would like to become a software developer, it is a really helpful text. You will go through all phases of software development, including working with people and understanding clients.

A carefully selected list of software engineering tips. Compelling and plainly laid-out arguments for making successful software projects. Some tips are dogmatic and controversial but each chapter is thought-provoking at least and behaviour-changing at most.

Surprisingly, I thought the weakest tips were ones that brought up specific code or language features. You can tell the authors have thought long and hard about how the perfect software engineer would behave. Each tip had me thinking and challenging my assumptions and I think many will be valuable to remember or refer back to later.

I would also definitely recommend reading the 20th-anniversary edition. It has some useful reflections on how the first edition was interpreted and revisits the DRY principle.

The Pragmatic Programmer is centered on good programming practices. It is very well written and is able to persuade you to want to change your habits and behavior. I intend on re-reading this book on a regular basis (anually, perhaps) because there is certainly a learning and adaptation curve to all the techniques that are introduced. Although I do use some of them on my day-to-day work, it’s very difficult to start using every single tip at once, so I’ll introduce them gradually on my working flow and hopefully become a better overall developer!

This is a brilliant book if you are getting into software engineering, full of tips and really practical advice. However, if you have been developing any kind of software professionally for at least a year, you are unlikely to learn much from it. Still, it might be worth reading as a ‘recap’ for some.