Book review: Lessons from  The Pragmatic Programmer

Book review: Lessons from The Pragmatic Programmer

Practical Advice for Writing Better Code

A Pragmatic Philosophy

It's your life

Don't forget that you don't have to stick to a job forever. This has nothing to do with loyalty, but rather finding something that fits your life and makes you happy.

You should always invest in your knowledge portfolio so that you'll always be ahead of the game.

Always speak up for yourself. If you want something, go for it. Take control of your happiness and make positive changes whenever you need to.

Take responsibility for your actions

You must take responsibility for your actions and be honest about your mistakes.

It's important to be trustworthy, so be someone your team can rely on. And you should be able to rely on your teammates too.

If something seems impossible or risky, you shouldn't be afraid to say no. Make decisions based on your own values and judgment.

If things get tough, think of different options, and don't be afraid to ask for help.

Software Messiness

We should always take care of software projects and not let them turn into a mess. If you ever find bad code or something you think could have been better, fix it.

Don't just leave it and ignore it. It's important to work with honesty and not let the code get worse.

If one person starts neglecting it, it can lead to a lack of care from everyone else, which can destroy the entire project.

Our learning journey

Since programming and technology are always updating, we gotta stay updated.

You should treat knowledge like a collection and invest in it regularly:

  • Learn different programming languages

  • Learn new technologies

  • Read books

  • Contribute to open-source

ETC - Easy to change

It is a guiding principle for software design. So, when we're writing software, we gotta think about what we're doing and if it makes the system easier or harder to change.

It's important because it saves time and effort by making future changes easier to do.

DRY - Don't repeat yourself

It means that you should avoid writing the same code over and over again in your projects.

It focuses on reusing knowledge and logic in your code, not repeating the actual lines of code.

The reason for that is because:

  • Repeating the same code makes your program slower and takes up more space. Avoiding repetition makes your code more efficient.

  • If we copy the same code in many places and then want to make a change, we would have to update it in all the other functions where we repeated it. By DRY, you only need to make changes in one place, which makes it easier to maintain and update.

For example, classes keep our code DRY. Instead of copying the same code for different instances, we can create a class with reusable code.

So we only need to make changes in one place, which makes it easier to maintain and update.

Orthogonality

It's when different parts of a system work independently without messing up with each other. If you make changes in one part, it won't mess up the unrelated parts. Orthogonal systems are easier to test and reuse.

Tracer Bullets

It's a way to test and improve software step by step, making sure it works before adding everything else.

For example, building a game. We wouldn't build the whole game at once. We start by making the character move and test it. If it works, we add more features like jumping or shooting and improving the game step by step.

Domain Language

It means using special words and phrases related to a specific topic.

It's important in code and communication because it helps make things clearer and easier to understand.

class BankAccount {
    constructor(accountNumber, balance) {
        this.accountNumber = accountNumber;
        this.balance = balance;
    }

    deposit(amount) {
        // Implementation logic for deposit
        this.balance = this.balance.add(amount);
    }

    withdraw(amount) {
        // Implementation logic for withdrawal
        this.balance = this.balance.subtract(amount);
    }
}

Decoupling

It's separating things so they can work on their own.

It could be functions, classes, APIs, etc.

By decoupling the logic, we make each unit easy to modify, test and understand.

We also avoid surprises since we know the current unit won't be affected by external changes.

Naming things

It's important to use names that say what things are or what they do. Don't use confusing or general names like "a" or "data.

// Bad names
const a = 5; // What does 'a' represent
const t = true; // Unclear variable name
function calculate(x, y) // Unclear function name
// Good names
const age = 5; // Clearly represents a person's age
const isAvailable = true; // Indicates availability
function caculateSum(num1, num2) // Descriptive function name

Collaborating

Pair Programming: two people working together on the same task or code

Mob Programming: the entire team works together on the same task or code

By collaborating and working together, we can accomplish more as a team:

  • Knowledge-sharing

  • Get more things done with increased quality

  • Improve the team atmosphere

Review

It's a great book. I highly recommend it to everyone who hasn't read it yet.

It's a very good resource that will inspire and help you in your programming journey.