Notes about The Pragmatic Programmer

Chapter 1 - Pragmatic Philosophy

There is a repeated pattern at the start of the book (tip 2), which its authors, Hunt and Thomas, use regularly. They think about their work while they are doing it and try to improve it. It is about e.g. repetitive stuff, which could be automated.

Tip 3 is about the attitude to business requirements. As a developers, we should be actively searching for ways to make business requirements possible, instead of giving lame excuses, why it is not possible. What would we think about a bank officer who makes lame excuses why he cannot do what we ask?

Tip 4 is about a theory, that technical debt is like broken windows in cities. Those are small problems, which, left unfixed, can raise to become huge problems. We should be fixing even small technical debt as soon as it is found. We should also think about, what is the root cause, that this technical debt happened at all.

Tip 7 elaborates whether software quality should be part of the requirements. The most of the users prefer a working software with bugs today than a perfect software tomorrow.

Tip 8 describes investing as a metaphor to learning. Almost every investment pattern can be translated to studying. We should invest in our education regularly, diversify our portfolio, etc. We should absorb the studied material always with the jaded eye (Tip 9). It is a good idea to talk about technology with someone outside our usual technical circle. 

Tip 10 is about communication, mostly in a written way. It is not just what we have to say, but also how we say it. Even a format is important.

Chapter 2 - Pragmatic Way

Tip 11 is a classic DRY - don't repeat yourself. I had some difficulties with this tip in the practice, because when I use is too dogmatically, I create a hard-to-use code. That's why I like Tip 12 more - try to make components, which are designed to be reused, very, very easy to reuse.

Tip 13 is about orthogonality. It is called cohesion in other publications, or SRP - single responsibility principle. It is about making our components self-contained, so they take care of their own stuff. It could be said that the components should be "shy".

Tip 14 says we should keep doors to changes in architectural decisions as open as possible.

Tip 15 are slightly different PoCs, which we use to build the foundation of future software. It is not a code to be thrown away, quite otherwise, it will show us whether the whole system could work. On the other hand, we use the actual PoCs, or prototypes (Tip 16), to learn something.

Chapter 4 - Pragmatic Paranoia

The chapter begins with Tip 30 - we cannot ever achieve the perfect software. If we are about to fail in the code, we should fail fast (Tip 32), so program defensively. If some situation cannot possibly happen, we add assertions that it does not happen (Tip 33). 

Tip 36 is partially about the Law of Demeter. If we would like some service from an object, we are not interested in receiving some other object instead, which has some other service, which we should call. We want it to just perform the service we want. We should minimize our dependency on the rest of the code modules. 

Chapter 7 - Before a Project

Tip 51 says that system requirements should not be just gathered. They have to be very actively extracted. They are hidden under layers of assumptions, ambiguity and politics. We should ideally work with the user to think like the user (Tip 52). As the project starts to grow, it becomes useful to start a glossary (Tip 54). 

Sometimes a diagram is worth more than 1000 words. But we should not be slaves to design tools (Tip 58). 

Comments

Post a Comment

Popular posts from this blog

Notes about the Clean Architecture book

The first look into the contents of the book was a bit scary. Some of these things were already explained in Robert Martin's previous books. Then I found out they are explained from a different (software architect's) perspective. Overall, I liked this book better than Clean Coder, but it was less useful for me than Clean Code book of the same author. Part I - Introduction The foreword contained two useful antipatterns: Too authoritative and rigid architecture. Speculative generality in software architecture. The main point of the preface is that not much changed for the last 50 years in software architecture. The rules of software architecture are the same regardless of any variable (time, type of project, ...). When you get the architecture of the software right, you magically don't need horde of programmers maintaining it. Chapter 1 - What is Design and Architecture? There is no difference between software design and architecture. There is a continuum of
Read more

Notes about the Building Microservices

These are notes for my future self about Sam Newman's book, Building Microservices 2nd edition.  Preface Microservices are an approach to distributed applications that use finely-grained services and change, deploy and release them independently. Microservices have become the default go-to architecture when designing system, which Newman finds hard to justify #surprised and want to share his view on why. Foundation Chapter 1 - What are Microservices? Microservices are independently releasable services modeled around a business domain . They are kind of SOA, but the one which is opinionated about how service boundaries should be drawn and where independent deployability is the key. Microservices should implement information hiding and expose their API in some way, e.g. via REST/JSON API or by emitting events. They should have their own database schema. To highlight that the services are as independent as possible, Newman draws them as hexagons, a homage to Alistair Cockburn's H
Read more

Notes about A Philosophy of Software Design

My notes about the book by John Ousterhout. It is quite a short book. Originally I made a mistake of reading just the Conclusions of the chapters but there is a lot of contents not in the Conclusions. After really reading the whole book, I started to like the Red Flags and other small pieces of hints. Chapter 2 - The Nature of Complexity Complexity is anything related to the structure of a system that makes it hard to understand or modify. Isolating complexity in a place where it will almost never be seen or touched is almost as good as removing it. There are many symptoms of complexity: Change amplification - when change requires modification in many places.  Cognitive load - how much a developer must know in order to make a change. Sometimes more code is simpler than less code because of cognitive load. Unknown unknowns - it is not obvious which places should be modified or what knowledge the developer must have to make a change. Complexity is caused by 2 things - dependencies and o
Read more