Journey of the Software Professional: The Sociology of Computer Programming

Overview

A comprehensive guide to the software development process that will help software developers at every stage of their career: improving personal performance, learning to work well in a team, and managing to create an environment where others can be most effective. Addresses the psychological and sociological aspects of software development, presenting a thorough model of individual and collective software problem-solving behavior, and practical techniques for enhancing the process. Covers the structures, processes...

See more details below
Available through our Marketplace sellers.
Other sellers (Paperback)
  • All (19) from $1.99   
  • New (5) from $5.95   
  • Used (14) from $1.99   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$5.95
Seller since 2014

Feedback rating:

(21)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
Book is in very good condition.

Ships from: Pleasant View, TN

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$19.51
Seller since 2007

Feedback rating:

(23385)

Condition: New
BRAND NEW

Ships from: Avenel, NJ

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
$24.54
Seller since 2009

Feedback rating:

(10268)

Condition: New
New Book. Shipped from US within 4 to 14 business days. Established seller since 2000

Ships from: Secaucus, NJ

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
$40.24
Seller since 2014

Feedback rating:

(2)

Condition: New
New

Ships from: Idyllwild, CA

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$53.00
Seller since 2010

Feedback rating:

(7)

Condition: New
10-7-96 other 1 BRAND NEW! ONLY Expedited orders are shipped with tracking number! *WE DO NOT SHIP TO PO BOX* Please allow up to 14 days delivery for order with standard ... shipping. SHIPPED FROM MULTIPLE LOCATIONS. Read more Show Less

Ships from: San Jose, CA

Usually ships in 1-2 business days

  • Canadian
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
Page 1 of 1
Showing All
Close
Sort by
Sending request ...

Overview

A comprehensive guide to the software development process that will help software developers at every stage of their career: improving personal performance, learning to work well in a team, and managing to create an environment where others can be most effective. Addresses the psychological and sociological aspects of software development, presenting a thorough model of individual and collective software problem-solving behavior, and practical techniques for enhancing the process. Covers the structures, processes and outcomes common to most software development projects, and how to improve them. Presents ideas on using tools and training more effectively, and on improving the performance of teams. Shows how to build on your personal and management successes, and avoid the most common errors. Programmers, developers, software managers, students, and anyone involved in the software creation process.

Read More Show Less

Product Details

  • ISBN-13: 9780132366137
  • Publisher: Prentice Hall
  • Publication date: 10/7/1996
  • Pages: 416
  • Product dimensions: 6.00 (w) x 8.90 (h) x 1.10 (d)

Meet the Author

LUKE HOHMANN, Education Technical Director at ObjectSpace, Inc., has taught object-oriented technology and software engineering management for companies such as Sprint, Kodak, E-Systems, Ernst & Young, and Bell Atlantic. From 1985 to 1993, he worked at several positions for Electronic Data Systems, including Vice President of Systems Engineering at EDS Fleet Services. From 1988 to 1992, he was also a member of the Highly Interactive Computing Environments (Hi-CE) research group led by Elliot Soloway, Ph.D., at the University of Michigan, where among other projects, he designed programming environments to help novice developers learn design skills.

Read More Show Less

Read an Excerpt



It was my first managerial assignment. I was ready. I had worked as a developer for several years on many different projects. Some were successful. From these I learned what to do. Some were failures. From these I learned what not to do. I was armed with a masters degree in Computer Science and Engineering from a prestigious University. I had studied software engineering and was ready to apply it. I read a lot of books on managing people and projects, from Peopleware to The Mythical Man-Month. Their advice and insights from the trenches of software development made sense. I was going to follow all of it.

The cold truth slowly sank in. My first job as a manager was less than a stellar success. Yes, the project was completed, the system was implemented, but I could have done a far better job. Since then I've led other projects and in the process learned many things. Past project experiences don't always apply in new projects. In fact, what brings success in one context causes failure in another. Learning about software engineering is far different from doing software engineering. And, while all the advice given in “Peopleware” books is definitely useful, I found myself continually asking, “What are the underlying principles of software development? What might guide or drive the advice and insight of people like Gerald Weinberg, Frederick Brooks, Larry Constantine, and Tom DeMarco1?”

This book was written for three reasons. First, it explores the underlying principles of software development through a simple but comprehensive theoretical framework. Second, it shows how to put this framework to good use through practical advice built on top of the theory. Third, it contains specific advice for both developers and managers in a clear and understandable format.

Why include practical advice and the theoretical framework supporting it in the same book? If a book gives practical advice but lacks a theoretical foundation you are left wondering from what credible principles the “advice” is drawn and how to successfully apply the "advice" in your environment. If a book provides only theory, you are left wondering about its practicality. Even the most elegant theory requires examples of how it is used to provide value. Theory is important for providing a way of thinking about a topic, but theory without practice is a car with no engine. While the majority of the book consists of practical advice, it contains the theory necessary to support it.

One advantage to practical advice is that it can provide a ready response to a tough situation. But, what happens when you are faced with a situation not described in this book? Alternatively, what happens when you disagree with my advice? Once again the theoretical foundation of this book becomes essential, for it provides you with the tools you need to create your own advice and respond effectively to novel situations.

Finally, you may have wondered why I've included specific advice to developers and managers in the same book. Their jobs are decidedly different and often antagonistic, right? A book certainly cannot give advice to both at the same time, right? Wrong. Certainly the jobs of developers and managers are different. So what? Take any difficult problem faced by a group of developers and their management. Unless each member of the group understands what they can do to improve the situation and plays their role things are not likely to improve. Isn't the real job of every person involved with the development effort to ship the best system possible? Instead of emphasizing differences, perhaps we should emphasize the ways developers and managers can work together. This book was not written for the intersection of the population of developers and managers. It was written for the union.

“What's In it For Me?”

Here is what this book will do for you:

- it provides a simple and comprehensive theory of how developers and teams of developers create software.

- it shows how advice found in other books makes more sense when applied in the context of this theory. After reading this book, you will never think of a data model or a coding standard in the same way again!

- it will introduce you to several new strategies and techniques on improving you and your team's effectiveness.

- it makes understanding and implementing these strategies and techniques easier by giving explicit advice to both managers and developers. I don't want you to waste any time trying to determine if the practical advice in this book is intended for a manager or a developer. Instead, I want you put these ideas into practice as quickly as possible.

- it addresses a broad range of topics and issues not usually addressed in most books on software development you will encounter over the course of your career. While you may not have an immediate need for every chapter, owning this book means you will be prepared to address these issues when they do arise. And they will.

Finally, it seeks to entertain you with personal stories and anecdotes that illustrate, expand, or otherwise bring to life the ideas in the book. These are offset from the main text in an italicized font.

Content and Organization

This book is organized in five parts.

Part I describes the mental processes of software development. It integrates cognitive models (models of how we think) with software methods (specifications of the activities we should undertake when developing software).

Part II explores a wide variety of topics on how individuals and their managers can improve performance using the SPO framework presented in Part I. My goal is two-fold. First, I hope to show how some of the traditional advice found in other books on such topics as code reviews makes better sense when applied in the context of the SPO framework. Second, I hope to introduce you to some new ideas such as future perfect thinking and how (and when) to make pancakes!

Part III applies the SPO framework to teams. It moves from cognitive models (which describe the individual) to organizational models (which describe interactions between individuals). Integrating organizational models with methods shows how the SPO framework provides a single, cohesive framework helping us to understand, predict, and guide both individual and collective behavior.

Part IV mirrors part two by using the SPO framework as the foundation for practical advice designed to enhance the effectiveness of teams. Again, I hope to show how traditional advice on such topics as the importance of standards make better sense when discussed in the context of the SPO framework. Of course, I also hope to introduce you to some fresh approaches to common problems such as building trust between developers, creating appropriate system architectures and structuring teams to support them, and writing useful status reports.

Part V concludes with a discussion of issues related to context-such as learning how to avoid poor working environments. It also deals with creating (or finding) the right context in which to apply the advice contained in parts two and four and serves to round out the book.

There structure of the book is as follows:

The Individual Chapters

Part One: Theory 1 - 2

Part Two: Practice 3 - 6

The Team

Part Three: Theory 7 - 8

Part Four: Practice 9 - 14

Context

Part Five 15 - 17

Audience

There are three distinct paths in the journey of the software professional. In the first, effort is focused inward, and the goal is improving personal performance. In the second, effort is directed outward, and the goal is improving both self and others. In the third, effort is directed upward, and the goal is to create an environment whereby others can be most effective. This book was written to address the needs of a developer on each stage of the journey.

Here are some ways specific populations can benefit from this book.

If you are a student or developer with less than 3 years working experience you are likely to be concentrating your efforts on stage one of the journey. If this is true then reading this book will provide you with the theoretical foundation necessary to understand how to improve your effectiveness. At times the book may be a bit challenging, but rest assured the effort you put into reading it will be worthwhile.

If you are an experienced developer (e.g., a senior architect or lead designer), then you are probably in the second stage of the journey. In other words, your primary job is to help others be effective by capitalizing on your experience. Such a job is uniquely demanding: you've got to marry technical and social demands. But how do technical and social issues really interact? Reading this book provides the foundation for discussing the answer. Of special interest to you are parts three and four which concentrate on teams, especially chapters seven and twelve.

Finally, managers of all levels of experience can derive several benefits from reading this book.

First, an understanding of how developers work both individually and in teams as they create software is a necessary prerequisite for the establishment of effective managerial practices. To see why, just read any Dilbert cartoon!

Second, the practical advice serves as a managerial handbook and provides specific answers to difficult questions in the context of a strong theoretical framework. Third, as a manager you have the responsibility for creating an effective work environment. A strong theoretical framework enables you to accomplish this effectively (see especially chapters nine, ten, and eleven).

How to Read This Book

First, read chapter one. The primary constructs of the SPO framework are established in chapter one. Reading this chapter first will provide a background in the primary terms as used in the remainder of the book.

Second, feel free to skip chapters in parts two and four. This book can be read quite satisfactorily in a non-linear fashion. Be forewarned some of the practical advice may seem a little out of place without the theoretical foundation in place to support it. Because of this, I do recommend you read part one before any chapter in part two, and part three before any chapter of part four.

Finally, read aggressively. Highlight or underline passages you think are important. Make notes to yourself in the margin. Dog-ear important pages for quick reference. Do whatever you need to do to make the most of it!

One Final Word

The writing of this book, like the creation of a large software system, is a strange journey, one never quite finished. To further my own personal journey, I ask you write me concerning the material presented herein. What did you like? What is useful? What benefits have you derived from reading this book? How can I improve the material in either form, content, or presentation?

I wish you a long and interesting journey, filled with an appreciation for our chosen profession. Thank you, and enjoy what follows.

Luke Hohmann lhohmann@objectspace.com


Read More Show Less

Table of Contents

PART I.

1. Setting the Foundation.

Problem Solving: Descriptions and Prescriptions. Cognitive Models. Benefits of Cognitive Models. Method. Benefits of Methods. Comparing Methods and Cognitive Models. Structures, Processes, and Outcomes: An Overview. Process. Linking Methods to Cognitive Models. Process Leveling and Experience. The Descriptive Benefits of Process Leveling. Process Leveling, Stepwise Refinement, and Opportunistic Design. Outcome. Preparing Outcomes for Understanding. Lessons From Architecture. Structure. The Structure-Process-Outcome Framework. The SPO Franewire in Action. The Critical Role of Feedback. Review.

2. The Integrated Framework.

Values. Personality. Goals. The Integrated Framework. Conflict and Tension Among Components of the Framework. Review.

PART II.

3. Fortifying the Foundation.

Create Structures and Processes to Achieve Outcomes. Practice Future Perfect Thinking. Review Early and Often. Kinds of Reviews. Formal Review Structures. Grow Your Experience. Use Multiple Models. Generate Alternatives. Differentiate.

4. Understanding Yourself.

Clarify Values. Understand Your Personality. The Kirton Adaption- Innovation Inventory. The Myers-Briggs Type Indicator. Relationship Between The KAI and MBTI. The Intersection of Personality and Values. Goals. Setting Goals. Organizing Goals. Know What You Are Good At.

5. Working Smarter.

Use Tools Wisely. What Is A Tool? Impact of Tools in the SPO Framework. Limitations and Dangers of Tools. Tools for Software Development. Use A Project Notebook. What Is A Project Notebook? What Should It Contain? How to Use A Project Notebook. Managing Time. Structures, Processes and Outcomes for Time Management. Working With Support Staff.

6. Training.

What Is Training? Training In the SPO Framework. Self-Learning. A Competency Framework For Self-Learning. Breadth Vs. Depth In The Competency Framework. Learning Style and Delivery Mechanisms.

PART III.

7. Development Teams and The SPO Framework.

A Brief Word On Size. Methods And Teams. Beyond Methods: Group Activities. Organizational Theories. What Is An “Organization?” Organizational Interdependence. Rationality. Topologies. Summary. Group Processes. Identification and Distribution. Coordination and Integration. Process Leveling In Teams. Collective Mind and GroupThink. The Impact of Individual Ability. Other Aspects Of Process. Summary. Outcomes. The Creation Of Shared Outcomes. The Meaning Of Shared Outcomes. Reducing Ambiguity and Equivocality In Shared Outcomes. Managing Shared Outcomes. Structure. Essential Structures: System Architecture & Topology. The SPO Framework In Teams. Methods, Teams, and Topologies. Multiple Integrated Frameworks. Timing. Feedback Loops and Crosstalk. Review.

8. An Integrated Framework For Teams.

Values. Culture. Goals. Strategy. Corporate Knowledge. The Integrated Framework. Linking Individuals and Teams. Power and Politics. Summary.

PART IV.

9. Interpersonal Relations.

Reasonable Persons. Pulling, Not Pushing. Developing Trust. Impact Of Trust. The Johari Window. Interaction Styles. Increasing The Arena Of Trust.

10. Communication.

The Creation Of Shared Outcomes. Modeling Communication As Messages. What Is Meaningful Communication? Communication Structures. Communication Processes. Communication Outcomes. Changes Over Time. Know Your Notation. Standards and Guidelines. Status Reports. Effective Meetings. A Model For Effective Meetings. Project Repositories.

11. Fortifying The Team.

Values. Culture. Norms. Rituals. Stories and Symbols. Shared Language. How to Influence Culture. Goals.

12. Organizational Engineering.

Coupling and Cohesion. Software Coupling Revisited. Three Types Of Organizational Coupling. Benefits Of Loose Coupling. Drawbacks Of Loose Coupling. Achieving Loose Coupling. Cohesive Components and Teams. Determining Cohesion. Structural, Procedural, and Outcome Cohesion. Being Cohesive. Complexity and Variety. System Architecture and Organizational Topology. System Architecture. Traditional Topologies. Organization Paradigms: Working Within the Topology. Addressing Size and Growth. Putting It All Together. Roles. Implicit Vs. Explicit Roles. Roles in Support of System Architecture. Roles Associated with Teamwork. Problems Associated With Roles. Structure As Process. The Impact of Structure. More or Less Structure. How Much Structure? The Dangers of Too Much Structure.

13. Technological and Organizational Change.

General Observations on Change. Innovations. Innovation Structures. The Innovation Evaluation Process. Tools, Techniques, and Interrelated Outcomes. The S-Shaped Curve of Adoption. Making Innovations Happen. Reorganizations. Team Lifecycles. Entrances and Exits. New Organizational Topologies.

14. Team Oriented Training.

Training Benefits. When Is Training Needed? Breadth Vs. Depth In Teams. What to Train. Approaches To Training.

PART V.

15. Working As A Professional.

Job Mobility. Be A Good Follower. Helping colleagues. Avoid Office Politics. Office Etiquette. Take Care of Yourself. Eat In Moderation. Exercise Regularly. Work As Comfortably As Possible. Take Vacations. Get A Reasonable Amount of Sleep. Know When To Say No. Take Care Of Your Relationships.

16. Avoiding Bad Working Environments.

Demonstrate Your Skills. Evaluate the Product Release Strategy. Have A Defined Role. Examine the Turnover Rate. Examine the Opportunity for Advancement. Are the Big Three Practiced? Review Outstanding Bug Reports. Interview Your Direct Manager. Talk With Other Developers.

17. Working In A Poor Environment.

Is It Really That Bad? Work To Improve. Maintain Your Network. Control What You Can Control. Improve Your Skills. Use A Bomb File. Burn Bridges Carefully.

Read More Show Less

Preface

It was my first managerial assignment. I was ready. I had worked as a developer for several years on many different projects. Some were successful. From these I learned what to do. Some were failures. From these I learned what not to do. I was armed with a masters degree in Computer Science and Engineering from a prestigious University. I had studied software engineering and was ready to apply it. I read a lot of books on managing people and projects, from Peopleware to The Mythical Man-Month. Their advice and insights from the trenches of software development made sense. I was going to follow all of it.

The cold truth slowly sank in. My first job as a manager was less than a stellar success. Yes, the project was completed, the system was implemented, but I could have done a far better job. Since then I've led other projects and in the process learned many things. Past project experiences don't always apply in new projects. In fact, what brings success in one context causes failure in another. Learning about software engineering is far different from doing software engineering. And, while all the advice given in “Peopleware” books is definitely useful, I found myself continually asking, “What are the underlying principles of software development? What might guide or drive the advice and insight of people like Gerald Weinberg, Frederick Brooks, Larry Constantine, and Tom DeMarco1?”

This book was written for three reasons. First, it explores the underlying principles of software development through a simple but comprehensive theoretical framework. Second, it shows how to put this framework to good use through practical advice built on top of the theory. Third, it contains specific advice for both developers and managers in a clear and understandable format.

Why include practical advice and the theoretical framework supporting it in the same book? If a book gives practical advice but lacks a theoretical foundation you are left wondering from what credible principles the “advice” is drawn and how to successfully apply the "advice" in your environment. If a book provides only theory, you are left wondering about its practicality. Even the most elegant theory requires examples of how it is used to provide value. Theory is important for providing a way of thinking about a topic, but theory without practice is a car with no engine. While the majority of the book consists of practical advice, it contains the theory necessary to support it.

One advantage to practical advice is that it can provide a ready response to a tough situation. But, what happens when you are faced with a situation not described in this book? Alternatively, what happens when you disagree with my advice? Once again the theoretical foundation of this book becomes essential, for it provides you with the tools you need to create your own advice and respond effectively to novel situations.

Finally, you may have wondered why I've included specific advice to developers and managers in the same book. Their jobs are decidedly different and often antagonistic, right? A book certainly cannot give advice to both at the same time, right? Wrong. Certainly the jobs of developers and managers are different. So what? Take any difficult problem faced by a group of developers and their management. Unless each member of the group understands what they can do to improve the situation and plays their role things are not likely to improve. Isn't the real job of every person involved with the development effort to ship the best system possible? Instead of emphasizing differences, perhaps we should emphasize the ways developers and managers can work together. This book was not written for the intersection of the population of developers and managers. It was written for the union.

“What's In it For Me?”

Here is what this book will do for you:

- it provides a simple and comprehensive theory of how developers and teams of developers create software.

- it shows how advice found in other books makes more sense when applied in the context of this theory. After reading this book, you will never think of a data model or a coding standard in the same way again!

- it will introduce you to several new strategies and techniques on improving you and your team's effectiveness.

- it makes understanding and implementing these strategies and techniques easier by giving explicit advice to both managers and developers. I don't want you to waste any time trying to determine if the practical advice in this book is intended for a manager or a developer. Instead, I want you put these ideas into practice as quickly as possible.

- it addresses a broad range of topics and issues not usually addressed in most books on software development you will encounter over the course of your career. While you may not have an immediate need for every chapter, owning this book means you will be prepared to address these issues when they do arise. And they will.

Finally, it seeks to entertain you with personal stories and anecdotes that illustrate, expand, or otherwise bring to life the ideas in the book. These are offset from the main text in an italicized font.

Content and Organization

This book is organized in five parts.

Part I describes the mental processes of software development. It integrates cognitive models (models of how we think) with software methods (specifications of the activities we should undertake when developing software).

Part II explores a wide variety of topics on how individuals and their managers can improve performance using the SPO framework presented in Part I. My goal is two-fold. First, I hope to show how some of the traditional advice found in other books on such topics as code reviews makes better sense when applied in the context of the SPO framework. Second, I hope to introduce you to some new ideas such as future perfect thinking and how (and when) to make pancakes!

Part III applies the SPO framework to teams. It moves from cognitive models (which describe the individual) to organizational models (which describe interactions between individuals). Integrating organizational models with methods shows how the SPO framework provides a single, cohesive framework helping us to understand, predict, and guide both individual and collective behavior.

Part IV mirrors part two by using the SPO framework as the foundation for practical advice designed to enhance the effectiveness of teams. Again, I hope to show how traditional advice on such topics as the importance of standards make better sense when discussed in the context of the SPO framework. Of course, I also hope to introduce you to some fresh approaches to common problems such as building trust between developers, creating appropriate system architectures and structuring teams to support them, and writing useful status reports.

Part V concludes with a discussion of issues related to context-such as learning how to avoid poor working environments. It also deals with creating (or finding) the right context in which to apply the advice contained in parts two and four and serves to round out the book.

There structure of the book is as follows:

The Individual Chapters

Part One: Theory 1 - 2

Part Two: Practice 3 - 6

The Team

Part Three: Theory 7 - 8

Part Four: Practice 9 - 14

Context

Part Five 15 - 17

Audience

There are three distinct paths in the journey of the software professional. In the first, effort is focused inward, and the goal is improving personal performance. In the second, effort is directed outward, and the goal is improving both self and others. In the third, effort is directed upward, and the goal is to create an environment whereby others can be most effective. This book was written to address the needs of a developer on each stage of the journey.

Here are some ways specific populations can benefit from this book.

If you are a student or developer with less than 3 years working experience you are likely to be concentrating your efforts on stage one of the journey. If this is true then reading this book will provide you with the theoretical foundation necessary to understand how to improve your effectiveness. At times the book may be a bit challenging, but rest assured the effort you put into reading it will be worthwhile.

If you are an experienced developer (e.g., a senior architect or lead designer), then you are probably in the second stage of the journey. In other words, your primary job is to help others be effective by capitalizing on your experience. Such a job is uniquely demanding: you've got to marry technical and social demands. But how do technical and social issues really interact? Reading this book provides the foundation for discussing the answer. Of special interest to you are parts three and four which concentrate on teams, especially chapters seven and twelve.

Finally, managers of all levels of experience can derive several benefits from reading this book.

First, an understanding of how developers work both individually and in teams as they create software is a necessary prerequisite for the establishment of effective managerial practices. To see why, just read any Dilbert cartoon!

Second, the practical advice serves as a managerial handbook and provides specific answers to difficult questions in the context of a strong theoretical framework. Third, as a manager you have the responsibility for creating an effective work environment. A strong theoretical framework enables you to accomplish this effectively (see especially chapters nine, ten, and eleven).

How to Read This Book

First, read chapter one. The primary constructs of the SPO framework are established in chapter one. Reading this chapter first will provide a background in the primary terms as used in the remainder of the book.

Second, feel free to skip chapters in parts two and four. This book can be read quite satisfactorily in a non-linear fashion. Be forewarned some of the practical advice may seem a little out of place without the theoretical foundation in place to support it. Because of this, I do recommend you read part one before any chapter in part two, and part three before any chapter of part four.

Finally, read aggressively. Highlight or underline passages you think are important. Make notes to yourself in the margin. Dog-ear important pages for quick reference. Do whatever you need to do to make the most of it!

One Final Word

The writing of this book, like the creation of a large software system, is a strange journey, one never quite finished. To further my own personal journey, I ask you write me concerning the material presented herein. What did you like? What is useful? What benefits have you derived from reading this book? How can I improve the material in either form, content, or presentation?

I wish you a long and interesting journey, filled with an appreciation for our chosen profession. Thank you, and enjoy what follows.

Luke Hohmann lhohmann@objectspace.com

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)