When I wrote this section of The Coding Samurai, I was primarily imagining people who brag at work, whether subtly or overtly. People who brag are trying to get attention, or power, but more often than not, it turns people off. When I think about communication, I think about connecting with others. Bragging automatically puts a wall between you and the other person. Rather than moving closer together, the person whose self-expression is bloated with self-praise finds themselves building moats instead of bridges. This likely isn’t the path to success in the workplace.

If you haven’t read the first post, I recommend reading it first. Otherwise, keep reading.

Self-expression

“Look at how beautiful I’ve made this bonsai, Father,” said Tama as Mitsuhide arrived home on his horse for lunch.

“I can still see you in this bonsai,” said Mitsuhide, pointing at a scar on the tree’s bark. “There should be no trace of the artist in the bonsai. Only display your work when your touch can no longer be seen.”

Tama looked at her father, disappointed. “It would make me happy to have your approval,” she said.

“You honor your father, Tama. Don’t be discouraged, but if you rely upon others to give you satisfaction in your work, you lose the power of self-respect. If you put your heart and soul into your work, it will be self-evident to those who matter.”

“I understand,” she said.

Lao’s commentary

Self-expression is vital to the human spirit. However, at work, self-expression must be tempered. Refine how your personality and feelings are conveyed as well as the timing of when to convey them.

Regularly congratulating oneself in front of coworkers won’t have the desired effect, which is to be appreciated. It’s far better to point out the merits of others, which will create trust and rapport. Even if managers and coworkers don’t give the praise one feels entitled to, don’t try to elicit praise or brag about your accomplishments. Others have their own agendas and are mainly concerned with how your efforts make their jobs easier.

Accept compliments and criticism alike with grace. Being complimented for a job where you didn’t try your hardest can have negative consequences. You might start believing that you don’t need to try your hardest to get praise and, as a consequence, stop trying to do your best. Likewise, don’t dwell on criticism, as it’s just one person’s perspective. Find any value you can in the feedback and move on.

The Coding Samurai lets his personality shine mostly through craftsmanship. This doesn’t mean walking around stone-faced and unemotional, which would likely only alienate you from your peers and others. Show playfulness, ingenuity, smarts, and wit through your work. At the office, this is where your spirit will be most evident, not in chitchat and trips for coffee.

Don’t forget that you must be appreciated for your long-term efforts and talents. Plenty of managers and organizations confuse the humility of The Coding Samurai with weakness. I once had a manager who always came to me with big problems before presenting “her ideas” to upper management. This attention felt really good for a while until I realized that I was getting the same cost-of-living raise as everyone else on the team and she was getting a 15 percent annual bonus. Careers might seem long, but wasting too much time in an ungrateful environment can wreck the trajectory of a promising career path.

If you liked this, please consider sharing this post with your network. Thanks.

BUY THE BOOK ON AMAZON

Other links in this series

• Man or machine?
• On Relating to Co-workers
• Maintaining a Balanced Mindset While Working
• On the Perils of Fame and Infamy
• Do You Know Your Company’s History?
• Be Entertained and Thrive With This IT Survival Guide

Ian Felton has more than twenty years of professional experience writing software for organizations such as NASA, Mayo Clinic, Thomson Reuters, and many more. He is the author of, “The Coding Samurai - The Way of the Computer Warrior.” His blog, The Psychologist Coder, explores IT through the lens of psychology. Ian is also a published author of haibun, a prosemetric Japanese form of writing, mainly centered around travel and journies to far-off places. In addition to writing and wildlife photography, his interests include running his nonprofit organization, which puts musical instruments into the hands of children who need them, and practicing meditation, Chinese, and several Chinese martial arts. He’s also a graduate student pursuing a Master of Arts in Psychology and Counseling Services.

We’ve come a long way since the first post of this series, where I discussed the difference between values and goals, and how only focusing on the latter at the expense of the former results in lower satisfaction and well-being. In the second post, we did a workshop on identifying personal values to carry into the workplace. The second workshop involved creating a team working agreement and using the sprint retro as the venue for evaluating whether the team is working according to their values or not. In this final post in this series, I will tie this all together and paint a picture of how this all fits together. For the bulk of this post, we will look at a fictional team, their values, their working agreement, and how they use it in their retros. We’ll also discuss how they create action items and put them in the sprint either as part of stories, or stories of their own.

An example team’s values

Imagine a small team of four developers, a QA tester, and a scrum master. They all sat down and did the first workshop to identify their own personal work values. After doing the first workshop, each person had their own personal list of values that they wanted to carry with them to the workplace and put into their work. As with everything, not everyone was completely sold on the idea, but after going through it, even the ardent naysayer admitted that it helped them clarify some things.

Later in the sprint, the team members were involved in making the team working agreement using the workshop in part two. The core values that this team selected during the second workshop include: quality, performance, humor, and honesty. To summarize in one sentence what this team values, we might say they are a group “that works to build high-quality, high-performing software, in a fun and open environment.”

Their working agreement

After identifying their team values, they constructed their working agreement, and here it is!

• Only check-in code that has performance metrics that meet our criteria
• Be honest regarding estimates and feedback
• Take time to lighten the mood if things are getting too serious
• Don’t leave before verifying check-ins deployed successfully
• Team activity on Fridays
• Get mentored on how to write faster code and queries at least once a week
• Someone SPIKE on improving performance once per sprint
• If you break CI and leave before fixing it, you buy the team treats

An example retro

In a recent imaginary retro, this team put the team working agreement on the projector (or holographic display if you’ve read The Coding Samurai). They went through each part of the agreement and talked about successes and places where the team slipped and could refocus their efforts.

For example, because the team had a deadline, they decided that they wouldn’t spike on a performance gain. Even though the entire team agreed to skip the task, it moved them further away from their goals. It doesn’t take long for a lack of commitment to the working agreement to result in things going back to status quo—a valueless, goal-driven team that lacks meaning, purpose, and culture.

In this team’s retro they mainly focused on how the team worked according to the agreement. However they also brought up other issues that needed to be mentioned even if they didn’t relate directly to the agreement. The working agreement isn’t intended to create a barrier to comprehensive dialogue about the sprint, it is intended to focus it, to give people plenty of touchpoints to address, and to be able to objectively examine the sprint. It can’t encapsulate all of the important discussions, nor should it.

Action Items

At the end of the retro, the team agreed to make action items as a result of examining the sprint against the retro. Since they skipped a performance spike, they decided to do make-up spike and create two stories for the upcoming sprint. They also decided that last week’s Friday activity event was so epic that they would canonize it on the wiki. They made an action item for that, too.

Summary

On the outside, a values-driven development environment might not look incredibly different than a typical agile environment. However, what happens on the inside, if you had a lens to see it, would be much different. People have a clearer understanding of the culture and the things that the team values. During the week, as the work gets done, through the process of building the software, team culture is generated. In an agile with values environment, it’s the work itself that builds team cohesion and meaning, not treats and mandates. And the best part is it’s free as long as the team tasks some time up-front to do the workshops and then sticks to the working agreement as a follow through. The changes slowly build up over time and before the team knows it, they have created something special.

Until next time,
Ian Felton - The Psychologist Coder

P.S. If you’d like me to come in and help you with agile with values with one of your teams, contact me.

In my previous posts, I talked about both values and goals. Both are useful, but goals without underlying values leave people feeling hollow. This feeling is regularly felt by development teams where the only focus is task completion with no concern, or only lip-service to quality, mentoring, honesty, and so on. My last post detailed a workshop to get in touch with your personal values. In this post, I’m going to continue the workshop by helping development teams weave values into the process.

On a recent contract, I remembered having the distinct feeling that the team was operating in an organic way. Not the meaningless kind of “organic” thrown on snacks by commercial farms these days–but a truly natural and mostly harmonious manner of working. The contract ended and I had time to reflect on what key elements led to our team creating the culture it did. I concluded that our reliance upon and commitment to working according to our team’s working agreement led to much of the success in our dynamic. The essential components of a team working agreement are the team’s values.

Our working agreement had several sections that included general agreements, meeting agreements, software development agreements and more. Each section focused on the important contracts we needed to make with each other so that we could function at a high level. Everyone contributed to the bullet-points that made up each section and we decided as a group to adopt or reject them. When new team members came in we would review the working agreement. Not only did this give the new team member an orientation to our way of working and allow them to alter it, but it also refreshed our minds as to what we found important to our team. Each person on the team largely internalized the exercise and brought that to work each day since everyone had input and therefore had an incentive for the working agreement to live in our interactions and efforts.

For the most part, management didn’t interfere in our working agreement process or try to influence it. Their hands-off approach was critical. Any seeming corruption of the working agreement by those in-charge would diminish the desire of the team to truly adopt it because it would no longer be “our” working agreement; it would be slightly more “their” working agreement.

How to build the team working agreement

The team working agreement workshop begins by everyone taking sticky notes and writing down the values they would like the team to operate under. When everyone is finished, each person takes their stickies and puts them on the wall. If someone sees their value, or a very similar value on the wall, they place their sticky next to it. For example, if I have a sticky that says “truthfulness,” and “honesty” is already on the wall, I place my sticky next to it.

When everyone is finished there will be clusters of values on the wall. The biggest clusters are the values that the team cares about the most. These are the values that will be focused on in the next part of the workshop. The values that only came up once or twice shouldn’t be completely neglected or thought of as unimportant. Just like in the individual workshop, people can come up with a long list of helpful values, but only a few can realistically be focused on, otherwise the entire exercise gets watered down with too many concepts.

In the next part of the workshop, everyone gets to participate in another round of team agreement creation. Keeping the team’s biggest values in mind, everyone will write down values-driven behaviors they would like the team to engage in. Once everyone has written down three to five things (or one if you have a team bigger than six or seven developers), each person will again place their stickies on the wall next to the value cluster that they feel most represents that particular sticky. For example, if a team value is “quality” and my sticky says “fix broken build/bugs/tests before adding features,” I will place it next the “quality” stickies.

Once everyone has placed their stickies on the wall, the entire team can see a set of actions and behaviors that team members care about and align with the team’s values. Take it all in–your team has come a long way toward deciding what kind of values will drive the team and defining behaviors required to fulfill those values.

The final part of the workshop involved someone projecting their screen and putting all of the team agreements into a document, wiki page, web page, or whatever format your team will find most useful. Be creative and do what works. There’s no right way. Once all of the team member’s ideas have been captured there is a final vetting process. By default, everyone’s ideas get included. Now have someone read out each idea one at a time. Only if there is team consensus that an idea isn’t a good fit for the team should it be taken out of the team working agreement. Once the process is complete, your team should have twenty or so items in your team agreement that spell out very specific ways that team agrees it will work. Your team has now made a working agreement according to its unique philosophy and values.

Once the agreement is in place, your team will need to identify any missing resources required to let your team function according to your values. If you don’t have a CI server, for example, and your working agreement requires one, efforts will need to be made to make that happen. Once the team has made a punch-list of required resources, the team will need to negotiate with whoever is responsible for obtaining them.

The most important actions come after creating the team agreement

What goes in the working agreement is far less important that how the working agreement is maintained. My team fostered the working agreement and referenced it regularly in our interactions, especially in retros. Our retros were, in fact, reviews of how well we worked according to our agreement. This can’t be emphasized enough. A working agreement isn’t a new concept, but fostering it and developing it like a child is the part that is often overlooked. It must be brought to life and that requires effort. Usually one person will light the torch and take it seriously enough to keeping blowing air on the embers. But unless a second person, and a third, and eventually all team members take turns helping it to become real, the team working agreement will be just another stupid page on the wiki.

A team working agreement has another benefit–it’s far easier to give criticism in a way that doesn’t come across as personal. If someone leaves without fixing a broken build, if “don’t leave without making certain your check-in doesn’t break the build,” is part of the team agreement, it’s very easy to say, “Hey, our working agreement says not to leave without making certain your check-in passes.” People receiving criticism around the working agreement being broken are less likely to feel singled out or picked-on. They helped create the shared culture of the team and so criticism isn’t just someone’s personal taste.

A team working agreement doesn’t solve all problems. People can still be assholes. Managers can still ask for things that violate the working agreement. Many interactions and individual actions will occur that aren’t in-line with the team working agreement. However, it’s far better to strive for the ideal, knowing it will never be reached, than to have no ideal at all. The team working agreement is an anchor in some circumstances and at other times a beacon that points the way forward. Use your working agreement often and without hesitation.

In the final post in this series, I will tie together all of these workshops and concepts and attempt to paint a picture of what agile with values looks like in real life.

Ian Felton – The Psychologist Coder

P.S. Here are examples from my team that your team can borrow from if you’re having a tough time coming up with things

General Agreements

No hit-and-run sprint planning: All team members should be confident in story requirements and acceptance criteria if they may be expected to work on the story.

Have a good understanding of what we are solving and who the audience is. Don’t leave backlog meetings confused about this.

This is a safe-to-fail environment.

Tell the truth. Accurately assess task status. Bad news doesn’t get better with age. Accurately estimate tasks even if it means displeasing people. Don’t feed people the answer they/you want to hear.

We succeed or fail as a team. Pay attention to the entire body of work for the sprint and not just the stories assigned to you. If you notice somebody struggling with a story or heading down the wrong path, ask if they need help rather than just watching them fail. Completing the whole sprint is a team responsibility.

Get explicit, non-coerced agreement on decisions. Voice dissent rather than silently disagreeing.

Developer Agreements

Commits and pushes to the origin feature branch should be small and frequent. If you wouldn’t give up CTRL+Z, you shouldn’t be committing only when you’re finished with a task.

Fix failing tests. Do not comment out or delete. Do not reduce code coverage thresholds.

To do comments should always reference a JIRA story code that explains the work to be done.

Technical stability over strong opinions (introducing new tools and frameworks are a last resort).

If the sprint is finishing early, pull any critical or blocker items from the backlog first, otherwise pull from the tech debt epic.

Maximize our existing tools before creating one-off processes or adding additional tools.

Merge or decline any outstanding pull requests before creating any new ones of your own.

Plan ahead and leave everything in a good state before stopping work or moving off-site. This includes making certain that all pull requests are merged or declined and builds succeed as well as closing the loop on any outstanding communication.

P.P.S. If you’d like me to come in and help you with agile with values with one of your teams, contact me.

This intro to philosophical discussion takes on several basic philosophical questions. Nagel walks the reader through several common avenues of philosophical analysis until leaving the reader with several questions to answer for themselves. In this review, I will take on some of Nagel’s questions.

How do we know anything?

Solipsism posits that the only thing that exists is our minds. But we don’t know that. We know that it is all we can experience, but not all that is. Skepticism doubts that any external world exists. But again, there is no way to know that. Is it meaningful to believe that only one’s own mind exists? No. Is it meaningful to assume that the world outside is something completely different than what it seems to be? Possibly.

We know that our sense organs are quite different than many other animals. However, we all seem to be measuring the aspects of the environment that we need to in order to survive in our bodies. Each type of body is adapted to survive in a niche of the environment. We can make a conjecture that the external world is the sum of all the senses of all the organisms that exist. But as a human, we can still only experience a sliver.

If it’s possible that my mind is all that exists or that the external world is something drastically different than what I perceive, I have no way of proving it to myself or others, so it’s a waste of time and energy to hold that position. I also can’t prove that anything DOES exist outside my mind, so is it alright to go on believing in the external world anyway? The definition of “alright” is up to each one of us and I say it’s alright. Regardless, I can understand that as a human, society and culture are constructed by tacit agreements or other agreements among humans. I don’t have to believe in an external world, but I can believe in the consequences of actions that come from my own mind as I perceive it. The consequences of not believing in an external world can have severe consequences. If I jump off a cliff I will find out quickly whether the external world exists or not. It’s not a wager most people will take. It’s likely not just alright to keep believing in an external world, but necessary to continue to experience my mind. In fact, if my mind is all that exists, then my mind tells me quite often about dangers and things I should do to avoid my mind ending. Indeed, if the external world doesn’t exist, since my mind seems to want me to believe quite strongly that an external world full of dangers exists, then it’s quite all right to continue to believe in it.

Other Minds

How do you know that all the beings around you aren’t just elaborate robots? Instinct isn’t knowledge. There isn’t any way for one to know that any other being has any inner experiences at all.

What can you really know about the conscious life in this world beyond the fact that you have a conscious mind? You can’t really know at all. There is no way to know what people, organisms, and inanimate objects experience. However, from reading books and listening to people, one encounters thoughts which very much appear to be the result of self-reflection and inner reflection, which takes place as a result of consciousness. While the existence of books and speeches that seem to be encoded with inner reflection enter my sensory world quite often, this is still no evidence. Nevertheless, that these thoughts appear from others’ mouths and hands compels one to lean more on the side of other humans having consciousness and an inner world.

Is it possible that there might be much less conscious life than you assume, or much more? Just as some stars shine more brightly than others, it does seem that some lifeforms have much more consciousness than others, and as a result, some creatures and objects have much less consciousness. This isn’t evidence, but merely a statement based upon the distribution of characteristics within the universe concerning, height, weight, intelligence, life span, size, and so on. Within species, there appears to be a wide-range of possible manifestations of characteristics. Consciousness is likely similar.

The Mind-Body Problem

Is the mind purely physical or is there some spiritual component? Nagel talks about the taste of chocolate and how it is distinct from the chemical and electrical signals in the brain. A symphony orchestra plays music, but is the experience of music something non-physical? If the experiences we have as humans require a spirit separate from the physical aspects, why are there physical aspects at all? If the spirit requires the physical components of neurons and eyeballs, then the spirit is dependent upon the physical and thus physical itself. We can reduce this problem by taking various disabilities into account. Are blind people lacking in spirit? Are deaf people lacking in spirit? If not, then the physical experiences we have, have nothing to do with spirit at all and this includes our thoughts which are also just neurons firing with moods modulated by chemicals such as dopamine and serotonin.

The other way of saying that everything is physical, is also to say that everything is spiritual. Why can’t physicalism be turned around and stated as if there is no dualism, then everything is spiritual even if it has a physical aspect to it. This seems to be a stretch though, since there is quite a lot of pain, suffering, disease, abuse, neglect, boredom, forgetfulness, and so on. How can spirit be forgetful? If everything is spiritual, what is the purpose of acquiring decades of experience and wisdom only for dementia to erase it all? A physical explanation makes far more sense where our bodies are here for the purpose of sexual reproduction (a physical process) to pass on physical genes and then be done with it. Everything about our nature as humans, points toward our bodies needing to be useful long enough to have and raise a few children and then the world no longer needs us around. Regardless of how each person experiences our inner world, we can objectively see how the environment treats other organisms and that physical processes wear down and destroy everything about each being, including the parts that some ascribe to being spiritual.

Free Will

Is everything, including our thoughts, and every action we take in every circumstance inevitable, or determined before it happens? Existentialists believe that we aren’t determined. It is up to each of us to discover meaning in our lives and work to become the people that we want to be. Even if everything is determined, it seems clear that it is determined that most people will not believe that everything is determined simply because of the psychological jail that is created as a result. If everyone believed that everything is determined people would not feel guilt, remorse, hope, responsibility, and so on. The fact that almost everyone feels all of those things is proof enough that if the entire universe unfolds in a determined way, that unfolding includes humans believing that their actions, thoughts, and feelings are not determined. It seems as if most of life is determined though: who we are born to, the times we are born into, the environment around us, geopolitics, and the economy. However, in each moment, we have several options, even if they are very small. Even the existence if a minuscule percentage of choices still constitutes choice. So while we are not absolutely determined, it appears our free will is considerably small.

Death and the Meaning of Life

Thomas Nagel ends the book by taking on two topics: death and the meaning of life. He mainly contrasts religious belief which accepts an afterlife and the worship of a god at face value without question. Of course, these conclusions aren’t acceptable for a philosopher as there is no evidence of, but plenty of evidence against this position being tenable. Here is where Nagel introduces humor, and suggests that if one is able to take oneself not very seriously, then death and the meaning of life aren’t such bitter pills to swallow. It’s only when we cling to these concepts with such seriousness that we feel we must have a purpose, that we must live on forever, that these problems become too hard to handle. I have to agree that if there is an antidote for existential angst, humor must be an ingredient.

An eastern take

After asking all of these questions and spending all this time thinking about what is and what isn’t, there is still another valid philosophical angle. This one comes from Buddhism. In Buddhism, spending time on questions like this is considered a waste. Since we know that we cannot know, Buddhists say that time should only be spent on working on the present moment. Buddhism isn’t interested in metaphysical speculation, only in the pursuit of conquering his own mind without wasting time on unimportant and unnecessary philosophical puzzles. Zen Buddhism is concerned with what is going on around us and the simple, practical matters about life. This is summed up in this tale:

---

A monk told Joshu, “I have just entered the monastery. Please teach me.”
Joshu asked, “Have you eaten your rice porridge?”
The monk replied, “I have eaten.””
Joshu said, “Then you had better wash your bowl.”
At that moment the monk was enlightened.

---

From the perspective of Zen, all of these questions are a waste of time and only get in the way of our development.

But we can ask many questions about the Buddhist perspective as well. Does Buddhism have any motivation to encourage its followers not to ask questions? Just because someone who was called “enlightened” said some things, does that mean they should be listened to without question?

All religions draw lines in the sand and encourage followers to stay within the boundaries of dogma. Buddhism is no different. Not only does Buddhism encourage followers to deny their desires and urges, but also to deny themselves the pondering of metaphilosophical questions. Where’s the fun in that?

Thomas Nagel, What Does It All Mean on Amazon

In my previous post, I talked about both values and goals. Both are useful, but the pursuit of achieving goals without manifesting underlying values leave people feeling hollow. This feeling is regularly felt by agile development teams where the only focus is task completion with no concern, or only lip-service to quality, mentoring, honesty, and so on. In this post and the next, I’m going to present workshops to aid in weaving values into the agile development process. I call this “agile with values.”

The first agile with values workshop relates to the individual. Our goal (see what I did there) will be to identify a set of values that we want to exhibit at work (and maybe in our lives in general). On the flip-side, we will identify our values’ opposites as a way to warn us when we have strayed away from them.

Concentrating on our values and carrying them with us throughout the development process gives us a sense a purpose, even when we consider the goals and tasks of the sprint to be pointless, going in the wrong direction, or against MVP. While our work-values might be the same as the values we care about in other contexts, this may not always be true. In this workshop, we’ll focus on our individual work-values.

How to identify values

Each one of us has to answer to the question “what are my values”; no one knows better that us. But that isn’t very helpful guidance. Here are two questions to ask yourself that will help you to identify the values you want to carry with you at work.

1. How do you want to experience your time at work? (Feeling constantly challenged? Feeling ahead of the pack? Stay at the fringes?)
2. What kind of person do you want to be in the workplace? (A leader? A skeptic? An innovator?)

There are no wrong answers, but how you answer will mean that some values will bubble up to the top more than others. For example, if you want to innovate at work, “easy-going” probably isn’t a great value to keep in the front of your mind. However, if you want to get along with everyone, then “easy-going” is a great value to exhibit.

Right now, answer the two questions. I’m going to do the same thing.

Here are the answers to my questions:

1. I want to experience work feeling disciplined, respectful, contributing, attentive, and equanimous.
2. I want to be a contributor at work, but not the guy everyone comes to for every question. I want to be laid-back and for people to feel like they can be honest with me because I will listen and not judge them.

It doesn’t matter if your answers are anything like mine in essence or format. Maybe some of your answers for number one sound more like my answer for number two and vice versa. It doesn’t matter. Answering these questions hopefully helped you identify some thoughts around your important values and that is what matters in this part of the workshop.

List 10 values

Now that you’ve thought about those two questions, write down ten values that you believe will help you in being who you want to be at work and how you want to experience work. If you aren’t certain what can be values, think about them as standards, principles, or even character best practices. They can be one word or a short phrase. Some examples are: respectful, being creative, not taking crap, and so on.

Make your list now. I’m going to do this as well.

Here are mine:

1. Disciplined
2. Equanimous
3. Balanced
4. Focused
5. Attentive
6. Open
7. Assertive
8. Creative
9. Engaged
10. Humble

Keep all of these values written down somewhere, but pick the top three that you feel are most important. We’re going to narrow our list down because it will be impossible to keep all of these in mind as we start our practice of working according to our values. Our ultimate goal is to internalize our values so that we don’t have to remind ourselves of them constantly. Until then though, we need to remember them, so come up with a simple way to remember your top three values at work.

My top three are: balanced, creative, and disciplined.

I’m going to remember mine with these three letters: B-C-D, which obviously stand for: balanced, creative, and disciplined. Remember yours whatever way works for you. Try acronyms, a memorable phrase, or imagery, for example.

You may also find it works better for you to winnow your list down to only one value. Imagine the power of fully embodying your most important value. This is incredibly difficult to do, but practicing your signature value to its core can yield amazing results. Consider, for example, how Gandhi aimed to live his value of non-violence to its core. Imagine the outcome of spending even a fraction of your focus developing your signature value.

Identify opposing values

Each of our values has opposing values. For example, using my top three, I can identify that the opposing value of balanced is unbalanced. The opposite value of creative is uninspired, or unimaginative. Finally, the opposite of disciplined is undisciplined, or disorganized. When you sense your opposing values creeping into you, it’s a warning sign that you have strayed away from what you’re trying to personify. If, like Gandhi, you want to exhibit non-violence, if you sense that you are being angry toward someone, being sarcastic to them, or feeling hostile toward them, it is a sign that you need to find a way to start living your value of non-violence again.

Now it’s time for action.

You have a list of values, and a way to remember your three most important ones, exercise these values as much as you can the next day at work, and the next day, and the day after that. But how do you exercise them?

Committed Action

Come up with a few actions you can do throughout the week that are the manifestation of the values you’ve decided on. If being creative is a value, commit to applying a new pattern to solving a problem each week. If being disciplined is a value, commit to using a timer each day and working until the timer goes off. If being engaged is a value, commit to making at least one suggestion in each meeting. Keep track of how you are doing and commit to new actions as you grow.

While you work, pay attention to your internal feelings and thoughts and be on the lookout for the opposites of your values. By working according to your values, you are no longer at the mercy of external goals and circumstances that have been decided for you and are out of your control. Working according to your values doesn’t mean that stress will go away, or disappointments, and other negative experiences, but you will likely suffer less from those events. At the end of the week, if you worked according to your values you will likely feel a sense of pride and meaning, which is something that can’t be taken away from you even if a manager is ranting about velocity, bugs, or any number of other gripes.

In the next agile with values workshop we will work on finding your team values with a team working agreement.

Until next time,
Ian Felton - The Psychologist Coder

P.S. If you’d like me to come in and help you with agile with values with one of your teams, contact me.

In just over 150 pages, Alan Watts attempts to replace traditional explanations about religion and the meaning of life with something that he hopes that once read will be discarded. I believe he accomplishes that. “The Book” is entertaining and makes an impact, yet once read, quickly seeps into the background like a good cup of tea.

Watts emphasizes that we are all a manifestation of something spiritual. We aren’t just egos in sacs of skin and bones. Watt’s Hindu-inspired philosophy says that we are the embodiment of the divine even when we are at our worst. This is the hardest pill for me to swallow in “The Book.” I don’t find any solace in the belief that when god takes the shape of a sadist, it’s just so it can help play a part in balancing out a cosmic drama that nevertheless is more positive than negative.

The second chapter of the book felt very disjointed, although it makes a few salient points. Watts peeks into the future where technology makes us more connected but worse off. This incredible insight into how society would change as technology advanced can’t be overstated. Unfortunately, it feels like the entire second chapter belonged in a different book.

The middle part of the book takes on the illusion of the ego, the falseness of societal constructs, and other falsehoods we create as we plod along through life. Watts writing style involves a lot of tangents and most of the time they prick the mind to elicit an insight easily taken for granted. We have indeed scrubbed the world of all its magic and this is what Watts wants us to rediscover. He wants us to drop our clinging to human supremacy and logical positivism and let ourselves have some space for something unknown to find its way back into our lives.

That organisms only exist as part of an environment, that society is constructed, that nothing is solid–Watts 1960’s exposition is a kind of puerile introduction to advances in quantum physics and postmodern philosophy. That isn’t to say “The Book” is without merit. Although the content of “The Book” is a mish-mash of philosophy, eastern religion, and science, many in our society today are still in the dark about the ideas presented by Watts. If one still has yet to step out of the certain, the known, and the definite, and has an urge to wade out into the ocean where all that we’ve been taught as accepted truth breaks down, pick up “The Book.” It’s full of it.

The Book on Amazon

Chase after money and security
and your heart will never unclench.
Care about people’s approval
and you will be their prisoner.
Do your work, then step back.
The only path to serenity.

– 老子, Lao Zi (hundreds of years before our common era)

We live in a goal-oriented culture. Therefore, it’s no mystery that many people feel that the pursuit of luxury cars, expensive degrees, high status positions, and culturally valued physical appearances are the paths to life satisfaction. However, many studies, including one done by Kasser & Ryan (1996), concluded that when people focus on externally validated goals rather than internally validated values, they have a significantly lower amount of well-being.

A study conducted by Chase, et. al (2013) on undergraduate student GPA found that when values are included along with goal-setting, there is a significant increase in student GPA. With goal-setting alone, there was no significant improvement in GPA. One of the biggest problems they found was a lack of distinction between goals and values. Values are much different than goals. According to one psychological model known as ACT, “values are freely chosen, verbally constructed consequences of ongoing, dynamic, evolving patterns of activity, which establish pre-dominant reinforcers for that activity that are intrinsic in engagement in the valued behavioral pattern itself,”(Wilson & Dufrene, 2009, p. 66). As such, values require a deeper cognition. Appreciating the connections between things, or giving help freely are examples of values, where goals are merely outcomes such as losing five pounds or saving $100.

How does this relate to IT?

Goal-oriented work makes up almost the entirety of tasks in IT. Take agile sprints, for example, the predominant way in which software teams work. (I’m not implying that goal orientation only applies to agile teams, but rather the specifics I’m going to use come from the agile lexicon because it’s the most popular approach.) Even though the Agile manifesto states the intent of Agile is “people over process,” I don’t really ever encounter this in my contract work. I encounter “business owner satisfaction over everything else.” Point velocity, deployments without bugs, and reactions of the business determine satisfaction most often. These characteristics all fall into the goal-oriented, externally validated bucket. When the sprint burndown looks great, but the CI server is a mess and tests are failing, managers might feel great, but the team usually feels unhappy, if not demoralized.

Agile with values?

Point me to the team that derives success from asking whether or not the most recent chunk of software was created according to a set of internally validated values. Now there would be a true unicorn startup. Imagine a team that decides that following a set of values would determine the success or failure of an agile sprint. Some of these values might be: not taking shortcuts, communicating honestly and expediently with team members when my work affects others, seeking constant learning, seeking mentorship, staying focused.

On a team that does agile with values, during a sprint retro, for describing something that went well, team members would likely say things like, “Jenny and I communicated regularly on task 123.” For something that didn’t go well, team members might say something like, “We took shortcuts to get the comment feature finished.”

Things like this do get said in agile retros and quite often–because most developers have strong internal value systems. The problem is that these internal value systems don’t receive upward support. The project manager typically doesn’t absorb the fact that making space for the developer team to work according to its internal values will allow the team members to generate a lot of satisfaction and well-being on their own.

Instead, something like, “We had this many points completed this sprint, which was 20 points lower than last sprint” gets reflected back to developer teams. The message to the team is clear: All we care about is points, and that is all you should care about, too. Developers shake their heads knowing that while most other developers around them share similar values, no one else in the organization likely does. What they care about is the output–were the goals met? And so catered food and video games are introduced as a replacement for what teams actually want–which is for management to empower and truly encourage dev teams to work accoring to values that inspire and provide meaning and a sense of pride.

Why aren’t we working according to our values?

The irony is that if team cohesion, satisfaction, and well-being are all high because the team culture is one of working according to values, productivity will also increase. Why? I’ll give you the short answer. When people and teams are stressed out, they don’t think as clearly, they don’t problem solve as effectively, and all forms of cognition decrease, say Pfaff & Pfaff (2012). Fixating on story points and burndown (or burnup), leads the team to be stressed out, and/or feel like the team’s values don’t matter. Research indicates that living by values increases satisfaction, which implies that if teams focus more on values, morale and also cognition will likely increase as a result.

However, this approach involves trust and a willingness for managers to let go of their reports and spreadsheets that are 100 percent quantitative and move toward qualitative assessments of sprints. This typically doesn’t make those analyzing the reports happy, which of course is their primary concern, not the well-being of the team. They want 10s, 30s and 100s, not qualitative data like “mentored,” “openly communicated,” and so on. This weakness knows no bounds. There is a huge reluctance or gap in knowledge when it comes to approaches that use qualitative data. Much of the work in psychology relies upon qualitative data, and many great research endeavors have seen successful results from using it. But it’s harder, and most people in the field want easier.

Another reason why we’re not working according to our values is that management feels the need to tell teams what’s important and what should give them a feeling of satisfaction and well-being. But developers already know; they just need people to leave them to it. But this approach requires giving up control and allowing teams to live according to their values, which many managers aren’t comfortable with. Most organizations fear self-empowered teams. Managers often want to be able to use external motivators to encourage teams to hit their marks.

So round and round we go chasing goals with an absence of values, wanting more well-being and satisfaction within our teams but ignoring all the research that informs us about how people work because it conflicts with our short-term, selfish desires.

Imagining a different way

But is it really any surprise that IT operates this way when our American culture operates in a similar fashion? What do we care more about, how much we are impressing our Facebook friends and Twitter followers, or how curious we are about the world we live in? Do we care more about the number of likes on our Instagram posts, or how connected we are with those we encounter in our daily life? We crave a values-driven life but substitute external goals for that. (By the way, people will spend a lot more money on stuff when they aren’t values-driven, which works out great for those selling stuff.)

But a values-driven economy could work just as well in an IT agile economy. Let’s explore this, starting with an examination of points. Right now, stories are broken up into tasks, or whatever unit a particular team uses, and sizes or points are assigned to it based upon how much work it is, or some close approximation. At the end of the sprint, the project manager, or report generator person, clicks the button and either looks down their nose and says, “Velocity was down,” or smiles and says, “Good job, team.” This is a caricature of a PM, but you get my point.

In a values-driven, agile economy, teams still work with stories and tasks, but instead of only points being assigned an estimate based on how much time it will take to complete a story, points can also be assigned based upon the types of values that we want to be applied to that particular task. For example, if the team has a junior member who needs mentorship, they can decide that to do this task according to their values, the junior developer needs to receive some quality tutelage. She must be mentored for that story to receive points. If not, no points. The team decides the criteria for determining partial points depending upon how much of the value a developer gives the task. Teams still need to estimate how much work can be done in a sprint, but the generated reports also track values-driven work rather than just how much work was done. The same number of hours are exerted by the developer, deadlines must still be met, but the experience of agile with values affects the developer psychologically in that the work creates meaning, well-being, and long-term satisfaction.

Same-same?

One may argue that contrasting a values-driven approach with a goal-oriented approach yields no difference since now we are just complementing the amount of work with how the work was done. However, how the work was done is the exact qualitative difference that results in well-being and the factor that IT currently doesn’t give two shits about. You can argue that living by values is just another form of goal-oriented living, just not one that can be measured by wealth, likes, friend requests, or story points. But that’s not true. The key difference is that one method uses external orientation while the other uses internal orientation. One looks out, one looks in.

With traditional point systems, progress is tracked by looking only at task goals. An entire world of more important and meaningful data is being lost, which is data about how the work is being done. When progress-tracking is treated this way, developers learn to hit targets each sprint, but beyond that, no one cares what values were exercised or how developers felt about the job. In other words, it couldn’t be any more hollow. Is it any surprise that there is little satisfaction and well-being in this way of working versus one where meaning is baked into the process?

Compare a team who thinks thoughts like, “I need to get mentored in this area so that we get full points for this story,” or, “I need to communicate to the team each time I change a contract in the API for this story” to a team that instead thinks thoughts like, “This is a six-point story. I could stand to learn a little more about this tool, but I’m worried about my point velocity this sprint.” Most developers have values-driven thoughts regularly but specifically ignore them because they don’t directly contribute to getting the task done and earning the points for the sprint. Why is IT so clueless about this? These thoughts are resources to be mined and exploited (if I have to use a business term to get people’s attention). If teams’ values were given an avenue to emerge, not only would quality go up, but so would retention and recruitment since the dev environment will be one that people actually want to work in.

Let’s try something different

Empty points systems based on time estimates disincentivize developers from constantly learning, mentoring others, spending extra time to document and communicate, not taking shortcuts, and so on because our goal-oriented culture only cares about how quickly something is done and cares little to nothing about working according to values. I don’t care what the lip service is: If we’re being honest, this is the truth about working in almost all IT environments. We track the wrong things for the wrong reasons and then wonder why disappointment and low satisfaction abound. Let’s try something different.

Ian Felton - The Psychologist Coder

P.S. In my next posts, I will follow-up with workshops to use with your team to move toward an agile with values culture.

P.P.S. If you’d like me to come in and help you with agile with values with one of your teams, contact me.

References

Chase, J. A., Houmanfar, R., Hayes, S. C., Ward, T. A., Vilardaga, J. P., & Follette, V. (2013). Values are not just goals: Online ACT-based values training adds to goal setting in improving undergraduate college student performance. Journal Of Contextual Behavioral Science, 2(3/4), 79. doi:10.1016/j.jcbs.2013.08.002

Kasser, T., Ryan, R.M. (1996) Further examining the American dream: differential correlates of intrinsic and extrinsic goals. Personality and Social Psychology Bulletin, 22, pp. 280-287

Pfaff, M., & Pfaff, M. S. (2012). Negative affect reduces team awareness: the effects of mood and stress on computer-mediated team communication. Human Factors, 54(4), 560-571.

Wilson, K.G., Dufrene, T. Mindfulness for two: An Acceptance and Commitment Therapy approach to mindfulness in psychotherapy New Harbinger, Oakland, CA (2009)

What the hell is a psychologist coder?

Good question. The short answer is, it’s me, Ian Felton. (Nice to meet you.)

As a human, the psychological realm holds all: relationships, interests, career choice, cognition, values, desires, aesthetics, and so forth. Even all of our scientific discoveries happen within the context of human brains that process these revelations and build technologies using the hands of homo sapiens. As a seeker, this realization set me on this path to explore the deepest reflections and research on what it is to be human and how to ease human suffering - the preeminent concern of a humanitarian.

I’ve worked in IT since 1993, mainly as a coder, but I began graduate school, working toward a masters in psychology and counseling, in early 2016. I wanted more than to gain knowledge in an interesting field of study. I aspired to completely change my worldview and also prepare myself to eventually transition into counseling as a second career. I decided that as the summer of my life waned, once I ceded the programming tasks of business web applications to the younger generations of coders, that I would find satisfaction in helping others live a more satisfying life with more meaning and less suffering. And there’s more to it than that–but that’s for other stories.

How does this relate to coding? Perhaps it doesn’t relate directly, but it does relate to how we exist in IT as coders, QA specialists, program managers, and business analysts, as well as why we’re there and what we can make of our time. In just over a year, I can say that my worldview has changed significantly several times over, and I’m looking forward to it happening on a regular basis as I continue digging deeper into a field that I find far more fascinating than anything else I’ve studied. I can never experience the workplace now without also seeing through the lens of my training in psychology and counseling.

I will share those perspectives with this blog.

I see a trend toward bringing more humanity into the tech world. This is a great thing. I see a lot of talks these days about fear, imposter syndrome, social justice, etc., and this inspires me. I see Wisdom 2.0 and Ted Talks. In today’s technologists, I also see the curiosity to understand something far more interesting than Boolean logic and business requirements. What I see is a curiosity for what it means to be human and how to integrate this into our workplaces. We don’t want it to be what we experience after work; we want it to be the fabric of our work. I see that many technologists are also humanists.

When I began my own journey at age 18, exploring not just computer science but Eastern and world religions, I wanted to find my humanity, but I quickly found myself in the world of IT I never quit searching, though, and now life has led me here. I’m going to explore situations in my IT life by looking through the prism of my training in psychology and counseling. Oh, what intrigue we might find! I also want to introduce concepts to those in IT who are fascinated with the areas of life that appear so infrequently in corporate America or the workplace in general. What are these areas? I believe they relate to meaning, authentic communication, strengths and weaknesses, team dynamics, power structures, conscious and subconscious desires, behavior, rewards, emotions, connection, stress-reduction, and many more. Maybe, through storytelling, psychoeducation, and exploration, technology can ironically be the field that drastically transforms the work culture into something much more human than what it is. If you are a seeker (mainly meaning you don’t have all of the answers or maybe even none of the answers), a humanitarian, and a technologist, I believe you’ll enjoy taking this journey with me.

May you find connectedness and meaning in this life.

Ian Felton - The Psychologist Coder

When I was in college, all I wanted to do was tinker with my computer. My friends made fun of me because instead of going out to a bar or hanging out with them, I would sit in my dorm room making Wolfenstein mods or upgrading hardware. After I was into my career, they apologized for teasing me about all the time I spent on my computer because they saw that my passion had led me to a successful path. However, they did have a point.

It’s important to have a broader perspective on life than the bounds of technology. Video games, programming, hardware, networking, gadgets - the areas of study within technology know no bound. It’s very easy to spend our free time concentrating only on technology. But we are humans, and humans are messy. Technology can make us feel that there is a sense of concreteness, or definiteness about our lives. We many times want to be correct and logical. This is mostly an illusion. I encourage those passionate about technology to also pursue something that isn’t so definite, something a little messier that deals with the ambiguity of emotions, the subjectivity of art, or the selflessness of volunteering.

If you haven’t read the first post, I recommend reading it first. Otherwise, continue reading the excerpt from “The Coding Samurai” on cultural refinement.

Cultural Refinement

“What are you writing, Father?” asked Tama, watching her father write calligraphy as she stood in the entrance to the tearoom.

“Matsuo Bashō—a great poet. I’m writing one of his haiku,” said Mitsuhide, moving the brush over the paper.

“Will you read it to me?” she asked.

“Summer grasses,

All that remain

Of soldiers’ dreams,” he said.

“So beautiful,” said Tama.

“Samurai are fierce warriors, hard and strong. But inside we must cultivate a place of softness and peace.”

“Why?” she asked, moving closer to him.

“As samurai grow strong, they can become arrogant. Hardness must be balanced with softness. To do this, I study the great poets. Moving the calligraphy brush is like a sword in my hand. I find pleasure in the movements.”

“You missed a stroke,” said Tama, kneeling down beside her father and taking the brush in his hand to complete the character.

“So I did,” said Mitsuhide.

Lao’s commentary

The Coding Samurai are skilled professionals. They love technology and immerse themselves in it so they can know as much as they can about their craft and how to apply it to create wonderful things. But living life absorbed in technology can be a detriment to personal development. Being a one-dimensional person who only can relate to computers is one who is lost.

Be highly skilled, but also be an interesting person. Throughout your career, you’ll meet many people from many backgrounds. Being able to connect with them is a must. Having a depth of character and culture will help your career, as much or more than just being a skilled craftsman.

As skills grow, a tendency toward conceit and arrogance oftentimes emerges. To temper this tendency, channel passion for craft into passion about humanity and then express it somehow. Once I realized I had become a highly sought programmer, I started walking around with an air of superiority. I couldn’t see that I’d conflated my programming skills with the quality of my character. I’d become a jerk. The jerk started fading after I became a Big Brother to a boy who was really into programming but was living in a troubled home. The time I spent with Dominick knocked me down a few pegs and made me realize there’s so much more to life than my ego.

If you liked this, please consider sharing this post with your network. Thanks.

BUY THE BOOK ON AMAZON

Other links in this series

• Man or machine?
• On Relating to Co-workers
• Maintaining a Balanced Mindset While Working
• On the Perils of Fame and Infamy
• Do You Know Your Company’s History?
• Be Entertained and Thrive With This IT Survival Guide

Ian Felton has more than twenty years of professional experience writing software for organizations such as NASA, Mayo Clinic, Thomson Reuters, and many more. He is the author of, “The Coding Samurai - The Way of the Computer Warrior.” His blog, The Psychologist Coder, explores IT through the lens of psychology. Ian is also a published author of haibun, a prosemetric Japanese form of writing, mainly centered around travel and journies to far-off places. In addition to writing and wildlife photography, his interests include running his nonprofit organization, which puts musical instruments into the hands of children who need them, and practicing meditation, Chinese, and several Chinese martial arts. He’s also a graduate student pursuing a Master of Arts in Psychology and Counseling Services.

“Patience means waiting to act or speak until you can do so without causing harm.” This reminder is on my phone and set to repeat daily. When stress hormones are released during interactions at work, being patient can be an epic achievement. That’s why I can’t be reminded enough that it’s up to me to manage the nature of interactions with people at work.

There’s so many things that we do that annoy others–things we are completely unaware of–that exercising patience with others is more than good diplomacy, it’s just. That isn’t to say that some people’s personality traits aren’t an order of magnitude more annoying than others, but if we are reactionary, we are only doing damage to ourselves. In “The Coding Samurai,” Professor Lao writes a bit about how not to interact with co-workers in ways that damage yourself.

If you haven’t read the first post, I recommend reading it first. Otherwise, continue reading the excerpt on relating.

Relating

“Who was that, Father?” asked Tama about the man who Mitsuhide had just firmly turned away from their home.

“Ishida Mitsunari,” said Mitsuhide.

“What did he want?” asked Tama.

“He wanted to straighten out a situation that doesn’t concern him,” he said.

“You sounded angry with him,” said Tama, setting the dinner table.

“He brings it on himself. He’s a busybody, going through the village acting like he’s the town supervisor. The villagers hide when they see him coming. He makes everyone uncomfortable,” said Mitsuhide. “Unfortunately, in his eagerness to help, he doesn’t take the time to carefully think through requests when they are actually made of him. As a result, he fails too often, which only adds to his tarnished reputation as a samurai.”

“Father, dinner is ready. Please come and eat,” said Tama to her father, who was still looking out the window watching Mitsunari walk down the road.

Lao’s commentary

In the workplace, someone who is always inserting himself uninvited into the work of others will alienate those he thinks he needs to help. The Coding Samurai should aim to be dependable but not interfere unless invited. Some people walk around the workplace as if they’re enlightened and everyone else is in the dark. Those on The Way of the Computer Warrior don’t act this way. They understand that their concerns are for doing their work the best they can and not worrying about others. If someone genuinely asks for help, help him. If someone comes to you in the spirit of discussing a matter, give her your full attention.

Something else to avoid is engaging in arguments with fools. Let them spin their yarns. The Coding Samurai has nothing to gain and a lot to lose. Most people who argue are only arguing with themselves. Many times they don’t understand the problem that has them worked into a frenzy. Don’t waste your energy by latching onto the words of someone who just wants to argue.

Sometimes coworkers may ambush others in meetings, trying to grow power or reputation. If this happens to you, keep your cool. Deflect the person’s attacks and maintain professionalism. Make statements calmly and clearly without letting the other person antagonize you or make you react in anger, for this may be their actual objective—to make you upset and appear out of control in front of the team so that you lose face.

Sometimes you have to work with someone with whom you have a tense personal past. One time I had to work with someone whose wife I’d dated. She and I were on good terms, but this guy hated me. I approached him and said, “Even though the two of us have a history, I’m not going to let that get in the way of accomplishing our work or let personal feelings get in the way.” We never had a problem at work. The Coding Samurai understands that he must protect his career and take the high ground.

If you liked this, please consider sharing this post with your network. Thanks.

BUY THE BOOK ON AMAZON

Other links in this series

• Man or machine?
• On Relating to Co-workers
• Maintaining a Balanced Mindset While Working
• On the Perils of Fame and Infamy
• Do You Know Your Company’s History?
• Be Entertained and Thrive With This IT Survival Guide

Ian Felton has more than twenty years of professional experience writing software for organizations such as NASA, Mayo Clinic, Thomson Reuters, and many more. He is the author of, “The Coding Samurai - The Way of the Computer Warrior.” His blog, The Psychologist Coder, explores IT through the lens of psychology. Ian is also a published author of haibun, a prosemetric Japanese form of writing, mainly centered around travel and journies to far-off places. In addition to writing and wildlife photography, his interests include running his nonprofit organization, which puts musical instruments into the hands of children who need them, and practicing meditation, Chinese, and several Chinese martial arts. He’s also a graduate student pursuing a Master of Arts in Psychology and Counseling Services.

As I’m about to make another espresso drink, I’m reminded about my early career when I would drink coffee nonstop. It wasn’t good for me since I’m already fairly neurotic. Caffeine made my mind hyper-alert which helped with coding, but it was counterproductive when it came to dealing with many other problems that arose during the day.

Through my martial arts practice, I learned some simple concepts that I adapted so that they can apply to any situation. Relaxed and adaptable. Balanced and focused. While simple concepts, without keeping them at the front of my mind, it was easy to slip off the rails and find myself fuming in situations where requirements changed or in meetings where no one seemed to get it. In The Coding Samurai, the protagonist, Artemis learns these concepts the hard way, just like I did.

If you haven’t read the first post, I recommend reading it first. Otherwise, continue reading the excerpt on the spirit of combat.

The Spirit of Combat

“You’re too tense,” said Mitsuhide while teaching his daughter sword-work in the courtyard. “That’s why I was able to disarm you so easily. And you aren’t balanced. That’s why you’re sitting in the dirt.”

“How am I supposed to relax when you are attacking me?” said Tama, pleading with her father to help her.

“That’s why you must train every day. It takes a lot of effort and practice to train your mind to naturally maintain a spirit of combat,” he said.

“What’s the ‘spirit of combat?’” asked Tama.

“The spirit of combat comprises four qualities. Two qualities, relaxed and adaptable, complement each other. A tense warrior will overreact and become overwhelmed easily. By letting go of expectations and going with the flow, a warrior can stay in the moment and not be preoccupied with distracting thoughts. Does that make sense?” asked Mitsuhide.

“I think so. Basically, the more relaxed I am, the easier it is for me to adapt. The better able I am to adapt, the more I can relax,” said Tama, picking up her sword from the ground.

“Exactly. Balance and focus also complement each other. The warrior in battle must be aware not only of the enemy in front of him but of the overall battlefield and things in his peripheral vision. He must be aware of both the sword and shield of his enemy. By seeing all that is going on around him, when it’s time to strike, he is able to focus completely and confidently,” said Mitsuhide.

“When do I use the spirit of combat?” asked Tama, swiping her sword in the air.

“Always!” said her father, looking at her sternly. “Whether going to the market or walking home after school, keep your mind ready for battle. If it lapses, you could be ambushed and defeated by something or someone far below your ability.”

Lao’s commentary

Developers can be ambushed by changes in requirements, production bugs, rude coworkers, and a slew of other day-ruining surprises. A mindset that is relaxed, balanced, focused, and adaptable leads you to being prepared for the daily “battles” in the workplace. Life’s not a computer; it doesn’t work logically and do exactly what you tell it to do. Letting go but staying balanced can be tough for some people to do, but practicing can help anyone.

Some ways to balance the mind include thinking through other teammates’ tasks and considering how one’s work fits in with theirs. Getting to know the stakeholders also helps. Do they change their minds often? What are their tastes? How hands-off do they like to be? By understanding as much as you can about the environment you’re working in, staying balanced becomes that much easier. Only once balanced can you focus like a laser on one task.

Staying relaxed is not only a sign of confidence; it allows your mind to function at a higher level. Panic leads to poor decision-making and a restriction of creativity which is necessary to perform at a high level. You must be adaptable as well. Managers regularly shift priorities. The Coding Samurai understands this and remains fluid to goals that are constantly in flux. Don’t let this reality of work weigh down the spirit, as that will result in more problems.

Oh yeah—it’s tough to maintain the spirit of combat if you’re freaking out on too much caffeine. There were times in my career when I was so high on espresso all day that I became easily distracted and too uptight; my work suffered. Be careful how you use that stuff.

If you liked this, please consider sharing this post with your network. Thanks.

BUY THE BOOK ON AMAZON

Other links in this series

• Man or machine?
• On Relating to Co-workers
• Maintaining a Balanced Mindset While Working
• On the Perils of Fame and Infamy
• Do You Know Your Company’s History?
• Be Entertained and Thrive With This IT Survival Guide

Ian Felton has more than twenty years of professional experience writing software for organizations such as NASA, Mayo Clinic, Thomson Reuters, and many more. He is the author of, “The Coding Samurai - The Way of the Computer Warrior.” His blog, The Psychologist Coder, explores IT through the lens of psychology. Ian is also a published author of haibun, a prosemetric Japanese form of writing, mainly centered around travel and journies to far-off places. In addition to writing and wildlife photography, his interests include running his nonprofit organization, which puts musical instruments into the hands of children who need them, and practicing meditation, Chinese, and several Chinese martial arts. He’s also a graduate student pursuing a Master of Arts in Psychology and Counseling Services.

I attended a software conference once where a speaker talked about “dark matter developers.” To the speaker, these were the 99% of developers who write software but aren’t active in online communities, conferences, or other venues where they have visibility. They simply don’t appear to exist as developers to anyone other than their co-workers.

Skill is the ability to do something well. The times when I have loved writing software the most, I’ve been a dark matter developer immersed in a project. That is where I developed skill as a coder, not posting in forums, working on a presentation, or writing blog posts. Like most, I like being appreciated for my efforts, but I’ve learned that what people notice positively mostly comes from devotion to craft, not devotion to attention-seeking. In The Coding Samurai, the protagonist, Artemis, learns this the hard way.

If you haven’t read the first post, I recommend reading it first. Otherwise, continue reading the excerpt on fame and infamy.

Fame and Infamy

Tama sat on the ground letting cherry blossoms fall onto her head as she read from the book her father had given her. Tama’s heart jumped when she heard heavy horse hooves. Her pulse quickened when she realized that after being gone for many days, Mitsuhide had returned from battle.

“Father, you’re home!” shouted Tama, running up to her father’s horse.

“Pink flowers are growing in my daughter’s black hair,” he said, pulling a tiny blossom from her hair and letting his hand slide gently across her cheek.

“Everyone in town is talking about the battle, how brave you were and how many enemies you defeated,” said Tama, her hand on her father’s boot, resting in the stirrup.

“Don’t be too concerned with stories, Tama. We were victorious, but it was my men who fought bravely and saved me many times. If you want to hear stories, someday I will tell you about truly legendary samurai—ones who didn’t seek fame, but ones who put themselves last and fought courageously on the battlefield for their lord and brothers,” said Mitsuhide.

Lao’s commentary

On The Way of the Computer Warrior, the Coding Samurai avoids acting in a way just to stand out. He works diligently on his craft and lets his daily efforts build a reputation. In order to become legendary, one with enough skill must take on seemingly overwhelming problems with great enthusiasm. By succeeding in the face of huge difficulty, one can earn a reputation as a fearless coder. Nevertheless, the Coding Samurai doesn’t take on tasks for the purpose of self-aggrandizement. He takes on imposing tasks in the spirit of service because no one else wants to or knows how to do the work.

This is counter to trendy, fame-worshipping, pop culture where people are famous for being famous. Seemingly there is no greater glory than having everyone talking about you. The saying ‘there’s no such thing as bad publicity’ is a common response to reading about ridiculous celebrity behavior being exhibited. But the Coding Samurai doesn’t seek this type of negative attention. A deep sense of security can only come from inside, and this is where the Coding Samurai goes to bring forth the best part of himself.

Those who seek fame often find it’s never enough. Recently, I witnessed a famous programmer on Stack Overflow with an unfathomable number of golden ponies, or whatever the rewards on that particular site are called, become so wounded at someone disagreeing with him that he flew into a defensive rage and badgered the person with a difference of opinion until he forced the other man to retract his comments. Is this any way to live? Is this success?

Doing ridiculous things and exhibiting poor craftsmanship will make one infamous in one’s circles. Someone who doesn’t keep up with skills, doesn’t complete tasks or completes tasks poorly, leans too much on others, lies about the work he’s doing, or wastes too much time will eventually gain a negative reputation.

Some other things I’ve seen in my career that led to infamy: someone who left a Watchtower magazine on the lunchroom table every day, a woman who wore a onesie with heels to work, a guy who left his computer on with a furry-porn website loaded, and a drunk woman at the Christmas party who simulated giving the CEO a hand job in front of his wife. Sure, it was only two or three quick strokes, but it was enough for her to earn the nickname “The Hammer.”

If you liked this, please consider sharing this post with your network. Thanks.

BUY THE BOOK ON AMAZON

Other links in this series

• Man or machine?
• On Relating to Co-workers
• Maintaining a Balanced Mindset While Working
• On the Perils of Fame and Infamy
• Do You Know Your Company’s History?
• Be Entertained and Thrive With This IT Survival Guide

Ian Felton has more than twenty years of professional experience writing software for organizations such as NASA, Mayo Clinic, Thomson Reuters, and many more. His poetry has been published in Contemporary Haibun, Volume 12 (Red Moon Press) as well as in Contemporary Haibun Online. He lives in Minneapolis, Minnesota with his beautiful partner, Jen, and their cats. In addition to writing and wildlife photography, his interests include running his nonprofit organization, which puts musical instruments into the hands of children who need them, and practicing meditation and several Chinese martial arts. He’s also a graduate student pursuing a Master of Arts in Psychology and Counseling Services.