What kind of book is it?

Not a textbook, its more a collection of short stories written from the second person. Meaning as the readers, we feel more involved and can begin to imagine ourselves in having to make decisions in  similar scenarios. 

The concepts explored are not provided in “neatly packaged prescriptive advice” and they are not handed down through “another stream of stern admonitions from the hilltops where expert programmers live," I just love that line. It’s really true in this egotistically industry. 

Instead the concepts are mean to be explored through discussions with others. And not to be just pacifically consumed.

The most important lesson of all will come from noticing the friction points and meaninguful differences between the real you and the characters I've written for you.

I enoy a good entrance

I want to take a moment and look at how Gregrey T. Brown opens up the book. For being such a straightforward opening, it has this optimism. This positive feeling that is both refreshing and motivating. His tone of voice is just so focused on providing encouragement, it's contagious.

We're in this together, and with you help, I think we'll do just fine. Buckly up friend. It's time for our journey to begin.

Where I'm at while reading

In the begining there is a page of the book titled simply, "The Journey". In it are paragraphs providing a high level summary for the assumed profeciency level of the main character within each chapter's story.

At this moment I consider level of expertises to fall in line with the following description:

Chapter 3 : You gain a deeper understanding of the costs of rushed decision making, especially at the integration points between you own code and the outside world. You've learned a great deal from past mistakes, and have started to focus on the complex relationships between business, customer service, and technical work.

Exploratory programming techniques

TL;DR

• Set expectations about functionality with wireframes.
• Religlously question if you really need the functionality now. YAGNI.
• Use prototypes to explore the problem space.
• Ask questions to help validate any assumptions and to efficiently better understand how other stakeholders view the problem.

Set the stage for a shared understanding of the work to be done

With early initial early prototypes, the goal is to explore the problem space as efficiently as possible. Prototypes allow quick feedback and provide a shared language for defining the problem and more importantly, on long term projects; they highlight assumptions early and with clarity. In my experience, the best prototypes are defined by a few key qualities:

Valuable Prototypes

• Have quick feedback loops to test assumptions and hard problems.
• Provide a shared language for technical and non technical people to communicate.
• Strike a good balance between an abstract sketch and a high fidelity design.