The pragmatic programmer: my takeaways
Tags: programming, books, devjournal
Published: 2022-08-29 07:04:31

I have recently finished the book '_The Pragmatic Programmer:
Your journey to mastery_'. 

A very interesting reading, packed with **tips** and **ideas** to improve as a developer.

So I've decided to write down here my personal takeaways. They might not be the best ones, but they are at least, the most **relevant** for **me**.

I hope you like them.


## 1. Does your work environment suck or you find your job boring? Do something about it.

---

> “Does your work environment suck? Is your job boring? Try to fix it. But don’t try forever. As Martin Fowler says, “you can change your organization or change your organization.”

---

Try to **fix** whatever is wrong with your work environment, if you can't, **change** jobs. So far, our industry and the market is giving us that opportunity. Embrace it.

## 2. Don't make lame excuses

Before telling anyone that something can't be done or whatever excuse you're going to say. Stop and think about it. Is it a lame excuse? How will it sound when you say it?
Instead, come up with **options**.

## 3. Don't leave broken windows
In the book, they explain the concept of 'broken windows'.

The concept is simple. If you leave something **broken** or in a bad state, that **reinforces** the idea that either nothing can be fixed or that no one cares. 

The same happens with software, do not leave broken windows, if you find one, fix it or find the time to do it (and actually do it). Needless to say, do not break windows by yourself.

## 4. Keep an eye on the big picture
If you don't see the big picture, you'll miss everything happening around you and you won't be able to react properly.

## 5. Invest in yourself

- **Invest** in your knowledge portfolio regularly
   - Even if it's only a bit every day
- **Diversify** your knowledge
   - Do not focus only on one technology/language/framework
- **Manage risk**
   - Evaluate which technologies/languages/frameworks are better to invest in than others
- **Emerging** technologies
   - Keep an eye on what is coming or new, being an early adopter, if it takes off in the market, can put you in a very valuable position.
- Keep always yourself **up to date**
   - Same as we do with our OS and libraries, keep yourself up to date

## 6. Be part of the community
Find out what people are working on these days, especially outside of your company and actively participate in discussion groups.

## 7. Make your code easy to change
If your code is easy to change, it will most likely be well designed and decoupled.

## 8. DRY
The DRY (Don't Repeat Yourself) principle does not apply to code **duplication**, it applies to which intrinsic **knowledge** the code contains.

---

> “DRY is about the duplication of knowledge, of intent. It’s about expressing the same thing in two different places, possibly in two totally different ways.”

---

You might have two pieces of code that are exactly the same, but they are intrinsically expressing different knowledge. That is not a violation of DRY.

## 9. Keep your code decoupled
Try the **Law of Demeter** in your code, to make sure you write modules that don't rely on other modules.

## 10. TDD and unit tests
Use **TDD** and write **unit tests**.

## 11. Prototyping is a learning experience
The value of prototyping is the **learning**, not the code itself. So don't be afraid of missing error handlings, using dummy data or not having the most complete functionality.

The prototype is not the final product.

## 12. Find better ways for repetitive tasks
If you find yourself doing the same thing **multiple** times, ask yourself if there is a **better way**.

## 13. Engineering daybook
**Write down** all the learnings, keep it in some doc, notes, whatever. So you can go and check it out in the future if needed.

## 14. Write shy code
Be clear and **strict** on what the code is expecting as an **input** and promise as **little** as possible in **return**.

## 15. Don't chain method calls
Try to avoid more than one "." when accessing something.

Example from the book:
`amount = customer.orders.last().totals().amount`

## 16. Refactor is not a full-on rewrite
Don't fool yourself, a refactor should not take week/s of work. Refactor is something **small**.
And keep in mind a refactor or full-on rewrite it's not meant to add new features. That comes later.

## 17. Naming things
Naming variables, systems, functions and so on is a big part of our work. And let's be honest, we are usually **not** good at it. Name things according to the **role** they play.

## And that was it

There are way more tips, and very well explained in this book. These are, in my personal case, the ones that I want to keep in mind the most and put into practice more often. 

Have you read the book? If so, which ones do you think are the most important for you?

If not, what are you waiting for? Get the book, some tea and enjoy :D