I joined a book club and finished reading The Pragmatic Programmer which is a famous book that I think you must read.
There are a lot of useful tips which you can use from today in this book. After reading this book I now have a different perspective on my daily work and career.

I took notes of what was most impressive to me about the book.
I am applying what I learned to my work now and hope to add more of what I learned from this very useful book.

🔖 This emoji means what I would like to do from now on.
✅ This emoji means what I have done since reading this book.

---

Chapter 1 - A Pragmatic Philosophy

Take Responsibility

You should have responsibility for yourself and your actions. Don’t just trust and count on anyone who is like an influencer, and don’t blame someone or something else, or make up an excuse because it is unprofessional and inefficient.

Good-Enough Software

The following three points would be unprofessional.

• Ignore users’ requirements and simply add new features
• Promise impossible time scales
• Cut basic engineering corners to meet a deadline

I promise impossible time scales and cut basic engineering corners to meet a deadline sometimes. When I promise like this, I realize it is impossible but project managers often ask me to meet the deadline so I feel I have to.
This makes no sense and no one will be happy because the product might be on time but it will not meet the quality expectations of management and users which would be problematic. Therefore, I am now more likely to tell a project manager when I feel the current deadline cannot be met.
✅ Discuss schedules honestly

Building Your Portfolio

The authors recommend regularly reading books to develop your portfolio. This made sense to me because by reading I can get useful and organized tips by reading books so l am making an effort to read more books.
🔖 Read technical and nontechnical books

Communicate!

After I read this topic, I reviewed the way I write commit messages. This book does not say about commit messages but I think a commit message is one of the communication tools. So I started to use Conventional Commitment. It is good so far because it is easier to understand commit logs.
✅ Implemented Conventional Commitment

Chapter 2 - A Pragmatic Approach

ETC

Tip 14 Good Design Is Easier to Change Than Bad Design

The ETC (Easier to Change) principle is a value which is a thing that helps you make decisions. It is not a rule. It should lead you in the right direction.
In order to acquire this value, you should always be aware of the need to reinforce this value.

Sometimes, you won’t have a clue about how to write easier to change. In this case, you can do two things.

1. Try to make what you write replaceable
2. Note the situation where you were uncertain about what to do in your engineering day book

I have encountered situations where I was uncertain what to do but I have never written them down. So I haven’t been able to review and assess those situations.
🔖 Note the situation when I don’t have a clue and review and assess to overcome roadblocks in my work

DRY

There is the only way to develop software reliably and to make our developments easier to understand and maintain. It is the DRY principle.
Is it just a duplicate code DRY? No. It’s the duplication of knowledge, of intent. That is a coincidence, not a duplication.
If just a simple fix makes an effect to change other codes, it is possible to violate DRY.

We discussed the following DRY in the book club when you join a new team or project.

• Share knowledge by Pull Request review to prevent violating DRY
• Share what you’re going to do with the team
• Detect it by using tools but it may be too much

How Accurate Is Accurate Enough?

The smaller the deadline duration is, the more accurate an estimate sounds.
However, when you are asked to estimate a deadline, you should say “I’ll get back to you”. You almost always get better results that way.

Chapter 3 - The Basic Tools

Shell Games

This section says about GUI. You should use CUI too because GUI environments are normally limited to the capabilities that their designers intended.
🔖 Avoid only use GUI

Debugging

When I read this section, I wanted to read it when I was a junior developer. There are a lot of useful things you should do when debugging.

Here is what you should do when debugging:

• Don’t panic
• Beware of myopia when debugging
• Make sure that you are working on code that built cleanly
• Gather all the relevant data when trying to solve any problem
• May need to interview the user who reported the bug in order to gather more data than you were initially given
• Read error messages
• Explain the bug to someone else. You may suddenly gain new insight into the problem
• Should not suspect the Os, the compiler, or a third-party product first
• Don’t assume it, prove it

The Binary Chop

I learned there is the binary chop feature in Git. It is called git-bisect.

Chapter 4 - Pragmatic Paranoia

Design by Contract

Why isn’t DBC used more widely?
I think there are two reasons.

1. It is difficult to implement
   1. OOP doesn’t support inheriting assertions so there is a way to create duplications
   2. Preconditions to use postconditions cannot save
2. Everyone has different requirements

If you implement DBC, you should think about Preconditions, Postconditions and class invariants. And these force us to think and spend a lot of time. The return on the invested time is going to be a solid system but every system doesn’t want to get the return.
I think it is similar to the question: Which one is better Static typing or Dynamic typing?. The more you use a static typing language, the more secure your system is going to be. But everyone doesn’t use a static typing language because everyone has different requirements.
That’s why DBC isn’t used more widely. But even if you don’t use DBC, maybe you check input values in advance which are similar Preconditions, or maybe you do testing which is similar Postconditions. So you could say you implement DBC partially.
And also, the concept of DBC is important because you can decide what you should do in a contract and it’s going to be more secure.

Assertion

When I googled Assertion, I saw articles which say you should turn off an assertion feature in a production environment. But the authors say you should turn off only those assertions that really hit you. Make sense. I thought it was odd to turn it off in production when we didn't even know if the performance was off or not.

Chapter 5 - Bend, or Break

Decoupling

Decoupling is important because it’s also easier to change(ETC). We learned about ETC in Chapter 2.
The TDA(Tell, Don’t Ask) principle is introduced in this section. By telling a value of an object as a method, the developer does not need to ask for an object's value.
But it is just a pattern to help us recognize problems. You shouldn’t just obey it. In every application, there are certain top-level concepts that are universal.

The Law of Demeter

Anything in your application should be considered likely to change. Therefore, try not to have more than one chain “.” when you access something.

Juggling the Real World

The strategy called FSM(Finite State Machines) is introduced. It is managing states and events on a table of an array. It is a great way to handle workflow requirements and it can keep the state in external storage.
🔖 Look for applying FSM strategy

Chapter 6 - Concurrency

I have not used Concurrency much in practice and could not note anything.

Chapter 7 - While You Are Coding

Refactoring

Refactoring is not a once-in-a-while activity but a day-to-day activity.
If you would like to refactor, I think it needs test cases. It means if you don’t test, it is too difficult to refactor. The next topic is about testing and it is such an important and core thing in programming. I could learn it from this book.

Test to Code

Why do you test? Just finding bugs? No. “Tip 66 Testing Is Not About Finding Bugs”
Testing has a lot of useful activities. For example, thinking about writing a test made us look at it from the outside and you can reduce coupling codes and improve flexibility. A test is the first user of your code. It is very important and useful.
There is a method of implementing software programming called Test-Driven Development(TDD). It has a benefit for people just starting out with testing but you shouldn’t become slaves to TDD. Don’t forget to stop every now and then and look at the big picture.
I thought testing was a very important part of programming. If you don’t do testing, you can’t refactor, find broken windows, reduce coupling, and so on. Conversely, if you do testing, there is a lot of room for improvement in your system.

Chapter 8 - Before the Project

Requirements Are a Process

Requirements are not absolute things. Therefore, it is going to get a better result if a client and a developer talk to each other than either only a developer or a client does. Requirements are learned in a feedback loop. In this book, it was expressed as “exploration”.
🔖 Explore. Don’t push your idea or suggestions

Pair Programming

One of the book club participants asked about Pair Programming and it feels like consuming two human resources. And someone familiar with Pair Programming answered as follows:

• There are good returns in the long term since the lower-skilled can learn from the higher-skilled and the level gap is filled.
• You can point out the reviews that you’d like to say in a Pull Request while Pair Programming. It is worth the resources of two people.

Chapter 9 - Pragmatic Projects

Coconuts Don’t Cut It

There is no single plan you can follow when you develop software. So when I become a senior developer, I should avoid getting attached to only one plan. I thought it would be wonderful if we could pick up the good points of a plan and communicate with team members to improve it.

Delight Your Users

Whatever my title is, I want to be a problem solver and delight users, not just write up code.

Pride and Prejudice

🔖 Have pride of ownership!