Best development book I've read, has no code in it.

Apprenticeship Patterns by Dave Hoover and Adewale Oshineye is a great guidance book for technical craftsmans. For me the main doctrine of the book is walking the long road. As the book says: "The people who walk The Long Road are not the heroes who sprint for a few years and burn out—they are the people moving at a sustainable pace for decades."

Here are some of my highlight from the book:

Mastering is more than just knowing. It is knowing in a way that lightens your load.

If you’re worried that your current job is rotting your brain, it probably is.

The best way to learn is to be in the same room with people who are trying to achieve some goal using the skills you wish to learn.

“How long will it take to master aikido?” a prospective student asks. “How long do you expect to live?” is the only respectable response.

Expose Your Ignorance. Tomorrow I need to look stupider and feel better about it. This staying quiet and trying to guess what’s going on isn’t working so well.

Just as the runner training for a marathon develops stronger leg muscles. She’s not training to have strong legs; she’s training to run. Like the motivated developer who after working on a Python project for two years achieves a deep knowledge of Python, the marathon runner’s strong leg muscles are a means, not an end.

Be the Worst. Be the lion’s tail rather than the fox’s head! Surround yourself with developers who are better than you. Find a stronger team where you are the weakest member and have room to grow.

Software development is composed of two primary activities: learning and communication.

You have been drinking steadily through a straw. But there are seasons in an apprenticeship when one must drink from the fire hose of information available to most software developers. Expanding your ability to take in new information is a critical, though sometimes overwhelming, step for apprentices. You must develop the discipline and techniques necessary to efficiently absorb new information, as well as to understand it, retain it, and apply it.

We can all benefit by doing occasional “toy” programs, when artificial restrictions are set up, so that we are forced to push our abilities to the limit.

If you hang on long enough, people will start calling you “experienced,” but that should not be your goal. All experience indicates is that you have been able to survive. It does not indicate the amount you have learned, only the time you have spent. Your goal should be to become skilled rather than experienced.

Software is not a product, it’s a medium for storing knowledge. Therefore, software development is not a product producing activity, it is a knowledge acquiring activity.

Sometimes the best tool for the job and the one you’re most familiar with are different. At those times, you have to decide if your productivity is more important than the team’s productivity.

Being a genius, lucky, rich, or famous doesn’t make you a master. These things aren’t essential to craftsmanship. Skill across all facets of software development and the ability to transmit that skill in ways that move the discipline forward are at the heart of the craft.

For a craftsman to starve is a failure; he’s supposed to earn a living at his craft.

Working with masters is the best way to learn a craft.

Check my other posts