Red Squirrel Reflections Dave Hoover explores the psychology of software development

On my flight home from Detroit this week, I hit chapter 9 in The Fifth Discipline. This chapter is hitting home more than any other. The previous chapters were more descriptive and instructive. They provided me with a better understanding of systems thinking and the fundamental system archetypes. But "Personal Mastery" is not so much teaching me, as reminding me of how I want to live.

"Personal mastery...means approaching one's life as a creative work, living life from a creative viewpoint as opposed to a reactive viewpoint." (141)

The act of creating is deeply satisfying to me, and one reason I so much enjoy software development. I'm reminded of something Fred Brooks said in The Mythical Man Month:

"First is the the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake." (7)

For me, a fundamental part of the creative process is learning. Apparently, this is a fundamental part of Peter's understanding of personal mastery:

"People with a high level of personal mastery live in a continual learning mode. They never "arrive"...it is a process. It is a lifelong discipline. People with a high level of personal mastery are actually aware of their ignorance, their incompetence, their growth areas." (142)

This ties into my reaction to reading Unskilled and Unaware of It.

Posted by Dave [Link]

I picked up The Fifth Discipline with great expectations and I have not been disappointed thus far. I was introduced to systems thinking in graduate school when I learned about family systems theory and its chief luminary Murray Bowen. Reading Peter Senge's take on systems thinking has been enlightening thus far.

I do have one bone to pick, though. Peter makes some strong statements about social structure and its influences on behavior:

"Structure produces behavior, and changing underlying structures can produce different patterns of behavior." (page 53)

His statement bothers me. It doesn't seem to account for the diversity of the human condition. I believe this thinking leads to the assumption that I would behave the same way as anybody else given the same social structure. I think it would be more accurate to say that structure strongly influences behavior, while produces goes a bit too far.

Ironically, Peter goes on to to say: "Western languages, with their subject-verb-object structure, are biased toward a linear view." (page 74) Which leads him to point out that: "All causal attributions made in everyday English are highly suspect!" (page 78) I agree with this view, and believe it should be applied to his statement that "structure produces behavior," (a.k.a. subject-verb-object) which strikes me as a bit linear.

In my experience, individual and group behaviors occur as a result of myriad systemic forces, individual idiosyncracies, thought models, belief systems, etc., not just social structure.

Posted by Dave [Link]

A recent comment-spam attack on some of my postings from late 2002 gave me a chance to reflect on where I was then and where I am now. Although that was about half a career ago, I was surprised to see how little my perception of my abilities has changed:

"The more that time goes by, the more I see that my niche will most definitely not be in any specific technology or application of computer science, but in the dynamics and interactions of the teams that create software. This is what I am passionate about."

As I throw myself into a new, technically challenging project at DaimlerChrysler, I see great opportunities for deepening my technical abilities. But I also find myself in the familiar position of Waking Holgar. I believe that I will contribute more to my current project by working to improve the team than with any technical contribution I could make. This appears to be becoming a recurring role for me...and I enjoy it immensely.

Posted by Dave [Link]

At the heart of my passion for software development is the desire to cultivate relationships and comprehend dependencies. I posted the following comment in response to something Laurent wrote in this post:

Laurent:
"You sometimes hear that managing a team is "all about the people", but that's a gross oversimplification. It's about managing relationships between people, which is a much more complex proposition..."

My reframe:
"You sometimes hear that object-oriented programming is "all about objects", but that's a gross oversimplification. It's about managing relationships between objects, which is a much more complex proposition..."

I've started wondering if there are any similarities between what it takes to manage inter-object relationships and what it takes to manage interpersonal relationships. Eric considers the topic in Domain-Driven Design, page 495:

"The essence of good object design is to give each object a clear and narrow responsibility and to reduce interdependence to an absolute minimum. Sometimes we try to make interactions on teams as tidy as they should be in our software. A good project has lots of people sticking their nose in other people's business. Developers play with frameworks. Architects write application code. Everyone talks to everyone. It is efficiently chaotic. Make the objects into specialists; let the developers be generalists."

Posted by Dave [Link]

[Archive Index] [Main Index]

Powered by Greymatter