«    »

Personal Development for Software Developers

I am a big believer in the value of personal development, especially for software developers. I have already written a a number of articles relating to personal development, most of which focus more on professional development for your career. The full scope of personal development, however, is much broader. It is applicable to all aspects of your life outside of work such as relationships, health, and finances. It provides a myriad of ways to improve and grow as a person, many of which will reap benefits for you in your career despite not being considered within the realm of traditional professional development.

There are many resources for personal development but they tend to be fragmented and look at only one aspect of life: i.e. a book on health versus finances versus character-building. I recently discovered that Steve Pavlina, a renowned personal development expert, had developed a unified conceptual framework for personal development and was presenting it in his book Personal Development for Smart People: The Conscious Pursuit of Personal Growth. This peaked my interest so I took advantage of the opportunity to get a free review copy of the book in advance of the release date. What follows is my review of the book, particularly my impressions of it and how I think it is relevant for software developers.

The book consists of two sections: the first identifies the seven principles that make up Steve's unified framework for personal development, and the second section covers the practical application of these principles to all major aspects of life. The seven principles consist of three core principles: Truth, Love, and Power, and four derived principles: Oneness, Authority, Courage, and Intelligence that are combinations of two or more of the core principles. One of Steve's main thesis in this book is that all personal development issues can be addressed through the proper application of the three core principles. An interesting corollary is that one's problems in life can be traced to an imbalance or lack of one or more of the core principles. For example suffering from low motivation at work is likely a sign that your heart is not invested in what you are doing, which comes from the principle of love.

I think the book is worth reading just for this framework of principles. I love the way the material is logically organized in this first section; it appeals to my left-brain-oriented style. Each chapter within the first part covers a single principle and each principle is broken down into a small number of key components or aspects. The principle of power, for example, is decomposed into responsibility, desire, self-determination, focus, effort, and self-discipline. After covering the various aspects of a principle, the rest of the chapter covers obstructions to full use of the principle and exercises to help understand or connect better with the principle. I also like how the end of each chapter leads directly to the next principle. There is enough meaty material in this first section that it could have stood on its own, but fortunately Steve provided the second section.

Section two of the book covers the application of the principles to the areas of Habits, Careers, Money, Health, Relationships, and Spirituality. In each chapter Steve relates that life area to each of the seven principles and often provides exercises or tips for how to gain insight and improvement within that area. There is a lot of good material in this section, but at times I was left feeling like there could have been more. For example, I hoped to find in the Career chapter information related to developing and growing within your career. The focus of the chapter, however, is on ensuring you have chosen the right career, which is not what I was personally looking for. Some chapters do not explicitly specify any exercises, although some are implied. I view this second section as more of a reference or resource section where you pick and choose the chapters relevant to your needs.

One thing I found generally lacking in the book was the use of diagrams or pictures. This might have been because I received an electronic PDF review copy of the book, rather than a paper copy. But I would have liked to see a diagram showing the seven principles in the book's introduction (Steve used a nice diagram in one of his promotional articles about the book). I also would have liked to see a diagram, ideally a mind-map, at the start of each chapter in section one showing the principle being discussed in the center and the various components of the principle arrayed around it.

If you are not a regular reader of Steve's blog then you may be surprised by some of Steve's non-mainstream viewpoints on topics such as diet, career, and spirituality. Steve does a decent job of not pushing his own agenda, but given his passion for the topic of personal development, his viewpoints can not help but shine through. Steve does emphasize the importance of experimenting and figuring out what works for yourself (from the principle of Truth), and does say to ignore his own advice if it does not work for you.

My final impression of the book is that it is not really trying to provide specific answers but instead enables readers to discover their own answers and approaches. With this in mind, let me turn to the question of how this book is relevant for software developers looking to advance their craft and capabilities. I am going to follow the template used in section two and reflect on how each of the three core principles applies to software developers.


The principle of truth requires that our perception of ourselves and of reality is as accurate as possible. Assuming that software development is the right career for you still provides a wide latitude of options regarding the roles and responsibilities you have within this career. For example, do you like developing user interfaces or back-end batch processes? Commercial software, enterprise software, open source software, or public web sites? Focus on coding only, or include other activities such as design, requirements, or project management? Examine what you are currently doing: is it right for you?

We evolve our model of reality by encountering new experiences that fall outside our current model and force us to adapt. I liked Steve's statement "excessive routine is the enemy of growth". To continually grow we must therefore constantly be seeking out new experiences, challenges, and ideas. The Pragmatic Programmer's recommendation to learn one new programming language a year, preferably ones that use a different style of programming, is one example of doing this. The goal I aim for is do at least one thing new or different on each project. I like to refer to these as experiments, in large part because it removes the stigma of failure. If the experiment does not work out you still learn something. Here are some suggestions for experiments:

  • Use a new library, framework, or tool. I like to maintain a list of ones that I want to try out, and then if one of them is applicable to my current project use it. My current list includes Google Web Toolkit, TestNG, MavenMaven, and Joda Time
  • Work on a system with a different architecture such as web 2.0, client-server, rules engine, extract-transform-load process, reporting, or messaging.
  • Perform one or more non-coding activities that you normally would not such as requirements analysis, system testing, performance testing, project management, or database design.
  • Change your methodology or process. Try out practices such as automated unit testing, continuous integration, or code reviews. If you are doing iterative development, try changing the length of the iterations. Try doing less (or more) formal documentation. Try doing more design up front or as late as possible.
  • Use a different style of coding. Try test-driven development or design-driven development. Try to comply with particular design and coding principles such as the Law of Demeter.

Steve points out that uncertainty is an essential part of reality that we need to accept and even thrive on. The idea that we cannot plan or anticipate everything in advance and that change will happen is closely aligned with the principles of agile development. I believe that agile approaches are more successful than other approaches (i.e. waterfall) because agile is a better match for reality. In terms of Steve's framework, agile aligns more closely with the principle of truth.


It probably seems weird at first glance to discuss how the principle of love relates to software development. But that is just the cultural baggage behind the word "love". Consider how being passionate about your work might be relevant to our effectiveness as software developers, and suddenly it does not seem so bizarre. In fact I believe that all three aspects of the principle of love – connection, communication, and communion – are very relevant to software development.

Steve defines the act of connecting as "to give something your attention, to think about it, and to engage with it." If our goal is to learn and grow as software developers, connecting with the craft of software development in terms of giving it our time and thinking about it sounds necessary. Part of the key is to consciously choose what to connect with versus disconnect from: aspects of software development that do not interest you or that you feel you have mastered and can gain no more from should be discarded in favor of aspects that you feel drawn to.

Communication is ever-present for most software development efforts: there is communication between the users or clients and the development team, communication between team members, communication between development and maintenance or quality assurance teams, and communication between the team and management. Effective communication is therefore almost always a critical success factor. To emphasize this point I want to share a discussion from a recent continuous improvement meeting I chaired. We were discussing the development activities of a particular team that had experienced repeated problems with users finding numerous issues and defects in acceptance testing despite an apparently-thorough successful system test. The team representative mentioned that code reviews were not really being done and that automated unit testing was haphazard at best. I quickly jumped on this as the reason for these problems and began trying to identify improvement opportunities. The team rep stopped me, thought a bit, and then surprisingly stated that he did not feel lack of reviews or unit testing were really the root cause of this problem. As he reflected and we discussed further, we identified that the real culprit was that users were not sufficiently involved throughout the development activities. Brief requirements were gathered from users at the start, documented, and reviewed by the users, but then there was no further interaction until acceptance testing. Limited communication between the business analysts gathering requirements and the developers was also a contributing factor.

So if effective communication is critical, how can it be achieved? Steve points out that face-to-face conversation is the richest form of communication. This happens to be one of the principles behind the agile manifesto: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." Steve goes beyond this surface level, however, by saying "genuine communication requires mutual understanding rooted in ... trust.", and trust is in turn based on establishing a connection with the other party. Again there are echoes of this in one of the agile manifesto's values: "Customer collaboration over contract negotiation".

Communion is the sense of bonding that arises from communicating and establishing a connection. DeMarco & Lister in Peopleware discuss the importance of what they call "jelled" teams in making a drastic improvement in team performance. Actually elsewhere in the book they instead use the term "bonded team" (see page 121), which maps directly to Steve's terminology. I believe that this can be expanded beyond just the boundaries of the team to include users, clients, and management. This is sometimes referred to in a diluted form as "partnership" or "mutual respect and trust". I think many of the less-efficient or dehumanizing aspects of software development are due in large part to this lack of communion. Typical industry examples of this include: management requiring extended unpaid overtime from developers, us-versus-them attitudes between developers and testers or developers and users, clients requiring detailed statements of work with fixed price estimates in contracts, and vendors winning a contract using senior resources and staffing the contract using less experienced resources. The net effect of this disconnection is either more overhead or reduced developer motivation.

I recommend the values & principles of the Agile Manifesto and reflect on how much of it actually aligns with the principle of love in terms of relating to either connecting, communicating, or communing. I think one reason for both the effectiveness of agile approaches and its wide-spread adoption by the development community is this alignment.


The principle of power is essentially about making decisions and taking action. The two primary sources of power are motivation and willpower.

The strongest motivation comes from pursuing goals that you are passionate about and are committed to. Psychologists classify this as intrinsic motivation and contrast it with extrinsic motivation, which in the workplace consists of factors such as paychecks, promotions, and pressure or praise from peers and superiors. This suggests that an important element of asking people to do work, whether it is your development team starting a project or just a coworker to which you are delegating a task, is to share your passion and commitment by explaining why this activity is important and worth pursuing. This can backfire if you are not sincere, so make sure you have that intrinsic motivation first. Steve provides an excellent metric for determining if a goal is sufficiently motivated: "If your goals don't inspire you at least as much as going on vacation, they're lousy goals." One counter-intuitive strategy for boosting productivity is to choose activities to perform based on your current motivation rather than the priority of the task. This helps maximize throughput, as you will tend to be more productive on each task.

Motivation based on passion and commitment is actually an interaction of the three core principles: passion comes from the principle of love which we need to become aware of via the principle of truth and then decide to commit to via the principle of power. While motivation is a necessary ingredient to achievement, it is not sufficient. As Steve says: "Motivation starts the race, but self-discipline ultimately crosses the finish line."

Willpower, or self-discipline, needs to be applied intelligently. Steve says "This includes having the discipline to get things done on time without resorting to extreme measures." When I read this, I immediately thought about the common practice of overtime in software development, which I consider an extreme and unintelligent measure. Many of the causes of overtime can be traced back to one of two sources: The first is an unrealistic project plan, which is a failure to align with the principle of truth. The second is a desire by management to get the software done faster with no regard for the people working the overtime, which is a failure to align with the principle of love.


The main message of Steve's book is the subtitle "The Conscious Pursuit of Personal Growth". Part of my vision is to help software developers learn and grow, and I hope my points on how the core principles of personal development – truth, love, and power – apply to software development inspire you. I leave as an exercise for the reader to consider how the other four derived principles of oneness, authority, courage, and intelligence apply to our field. I recommend that you get the book to help answer this question and guide you along your chosen path.

If you find this article helpful, please make a donation.

2 Comments on “Personal Development for Software Developers”

  1. george naing says:

    Hi Basil,
    thanks for your postings.

    you may find this a bit interesting too.



«    »