The pragmatic programmer surprised me by being a no-code book, but started off by explaining how software engineering was an art and software engineers are craftsman, and went into somewhat philosophical speech about the art of making software. That drew me in. As a geek with no life and still in university, I just had to read it.
Albeit, I feel like I'm reading this book too early since you need to be working to actually utilize all of this knowledge.
Here I'll be briefly discussing the main parts of the book.
You should take responsibility
Don't be afraid to tell people that you don't know a particular technology. Don't tell people that you can't deliver some code because of lame stupid reasons. Think about what you're gonna say before saying it.
Does it sound reasonable?
Is it really reasonable for an app not to be done because you only like working with a particular language or framework? Don't make excuses or blame other people for your own downfalls.
Trust is important in a team environment. You could say a team environment relies on implicit trust between team members.
I take this advice to heart, because before reading I probably would have nagged about using new technologies
Software Entropy
This is by far the most important topic I've read so far (Currently @ Orthogonality). This term describes how much disorder exists in your software. The book discusses how to identify it. It could be a piece of code that needs refactoring, bad design choices or even plainly wrong decisions. If you find any of these problems and don't fix it, then your software is gonna end up badly.
Don't write bad code if the code base is already bad. Take your time to fix it, then write good code.
Your portfolio
As technology evolves so should your knowledge, otherwise you would be left behind. Keep reading books on technology even if you don't work in it. Learn new programming languages or paradigms.
Knowing when to stop
Sometimes It is best to publish your software and stop adding features. This problem is called feature bloat, where a program has too many features. Maybe you don't need all the shiny icons or offline notifications.
Communicate
Know what you want to say. Write an outline. Does it say what you want?
Know your audience.
Choose your moment.
Choose a style. Just the facts or detailed.
Make it look good. Check spelling. Good design.
Involve your audience. In drafts
Be a listener.
Get back to people.
Keep code and documentation together.
Orthogonality
Try to keep modules/classes dependent on themselves. This will significantly help in debugging, since the bug will belong to a single class.
DRY
Don't repeat yourself, but sometimes you should. If you find yourself copy pasting code, maybe you shouldn't be.
Staying on track
to be continued
Reversibility
Write code that is abstract and won't break if you change an underlying structure. As you may notice this relates back to orthogonality.
I'm gonna stop here to not ruin the experience of reading the book to people. As much as I would love to write a summary of the book to use for myself. I feel like people need to read it for themselves.
Great quotes
I'm not here to live up to your expectations, and you're not here to live up to mine - Bruce Lee
The greatest of all weaknesses is the fear of appearing weak.
You can change your organization or change your organization. - Martin Fowler
An investment in knowledge always pays the best interest - Benjamin Franklin
Every piece of code must have a single, unambiguous, authoritative representation within a system.
Notes
The cat ate my source code. page 111.
Don't live with broken windows: Topic 3 software entropy. No broken windows. Don't cause collateral damage, just because there's crisis.
Top comments (0)