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
Top comments (0)