Book Review: The Five Dysfunctions of a Team

I was recently given a copy of this book (The Five Dysfunctions of a Team by Patric Lencioni) by a co-worker. It is a pretty easy read. The majority of the book is a narrative/story about “Kathryn” taking over as CEO of a company with a very dysfunctional senior leadership team. She walks her new team through their dysfunctions and points out ways to deal with them.

The 5 dysfunctions talked about in the book are: Absence of Trust, Fear of Conflict, Lack of Commitment, Avoidance of Accountability and Inattention to Results.
Reading through the examples displayed by the team described in the book, I could certainly see some of them in the teams I work with and have worked with in the past. “Kathryn” gives clear guidance on how to deal with these dysfunctions.

The last chapter or so steps out of the story and gives clear definitions, examples and suggestions for solutions to the various issues. It does not make the assumption that all teams are the same, but gives several different techniques to help overcome each of the dysfunctions, and points out that they are all inter-related. You rarely have only 1 of the dysfunctions, but instead have many or all but at different levels of dysfunction.

Given the relatively easy read and the quality of the information, I would recommend this to anyone who leads a team. It’s equally good if you are just part of a team and not leading it, so you can work toward avoiding the dysfunctions at least as 1 member of the team.

Should we store generated files?

Unfortunately, the answer isn’t as simple as yes or no.

I suggest asking yourselves a few questions to help you determine whether it makes sense to store the generated files/resources.

Does storing these files/resources hurt you or your team in any way?

Are you running low on storage space because of these files?  Often the sheer number of these resources can become unmanageable, especially when you start looking at the space they are consuming in source control.

Does it take extra effort to actually store these resources?  If your team needs to go through extra steps to ensure that these items are being stored, they may be a candidate for dropping.

Does the existence of these files confuse people?  When I first started working with React.js, we stored both the source and the generated files.  I didn’t know what the difference was, or where I should be making changes.

Does it take longer to store or retrieve files because of the number/size of these extra files?  This may be hard to discern.  One way to get a feel for this is to simply look at the amount of storage dedicated to these temporary/generated files compared to the rest of the files.  If it seems a large portion is generated files, perhaps you could try removing them from the storage (maybe in a test location).

Are they easily reproduced?

Do you have an automated way to regenerate these files for individual developers? Ideally, the answer is yes (or at least nearly automated).  This could include a step in the build process (that you execute locally when you make changes, or is kicked off auto-magically), or a process that is waiting in the background for someone to make

Does reproducing them happen quickly? If the answer is no, then it might make sense to store these files.  If the files need to be regenerated often, though, even though the process takes time, it might make sense to not store them, as the stored files will be of little to no value.  If this is the case, then I would invest some time in ways to speed up the generation process, or remove the need for the files all together.

Can an individual reproduce them on his/her machine?  Sometimes files need to be generated on a machine with a certain setup (OS, applications, etc) and there are only a few of those places available.  If this is the case, then it might make sense to store the files, especially if they don’t need to be reproduced often.

Do the files need to be reproduced often?

If you need to reproduce the files often, because you are changing inputs, or changing environments, then you probably don’t want to store them.  Storing them is buying you very little in this case, since you will likely reproduce them and overwrite what was previously there.


How to convert a String to an Enum

The other day I was asked how to take an input string and convert it into an enum.  The individual in question searched the nets to no avail…so, this seemed like a good opportunity to impart some knowledge that is apparently hard to find.

public enum Fruit {
  APPLE("apple"), BANANA("banana"), PEAR("pear");

  private String fruitName;

  private Fruit(String fruitName) {
    this.fruitName = fruitName;

  public convertToEnum(String stringToConvert) {
    for(Fruit fruit: Fruit.values()) {
      if(fruit.fruitName.equalsIgnoreCase(stringToConvert)) {
        return fruit;
      return null;

In words, we construct our Enum with strings that represent the particular enum (you could probably get away with just using the name of the enum, rather than adding the string representation).  Then you simply create a convert method that can loop through the values of the enum (which is all of the enumerated values defined, in this case APPLE, BANANA and PEAR), and compare the string sent in to the string representation ignoring case and return the matching enum.

By accessing the enum.values(), you can easily add additional enumerated values without changing any of the rest of the Enum.


This is a rather heavy article I just read, but I thought it was extremely important that people read and share.  It talks about our behaviors online.  It talks about the abuse that some people get (especially women and minorities) just for doing their jobs.  There is a video part of the way through the post which is really hard to watch, but is emotionally impactful.

Please read and share.  We need more empathy in this world.


Egoless programming == Jerkless Programming

As an agile enthusiast, I am a big proponent of the concept of egoless programming.  Jeff Atwood’s post The Ten Commandments of Egoless Programming sum up the concept quite nicely.

I got to thinking about this idea of egoless programming, and I have a problem with the name.  I really think we should call it something like “Jerkless Programming” or “Considerate Programming”.

The problem I have with the name “egoless” is that it ignores that the ego is not in and of itself bad:

From, definitions 3&4:

egotism; conceit; self-importance:

Her ego becomes more unbearable each day.

self-esteem or self-image; feelings:

Your criticism wounded his ego.
As we can see, the ego is how you see yourself.  The word “ego” is often used when we mean that a person has an inflated ego (or they think more highly of themselves than others do).  These are the people I want to avoid working with.
The ego allows us to feel good about ourselves when we write good code, clean up technical debt, etc.  I want to work with people who have a healthy ego, and are working to nurture their self-esteem by caring for the code and the team.  If we tried to remove ourselves from our emotions, we would become drones and would have little drive to improve the structure of the code if it were working.
So, please, bring your ego’s to work!  Care for them, nurture them, but be realistic.  Look very closely at yourself in the mirror, listen to feedback and be a considerate teammate.

There are three ways to do things…

Homer: …the right way, the wrong way and the Max Power way
Bart: Isn’t that the wrong way?
Homer: Yeah, but faster!

Is there such a thing as “the right way” in software engineering?

Earlier in my career, I was an idealist.  I wanted to do things “the right way”, always.  I hated when the business would push for things to get done sooner, which usually meant taking shortcuts.  I pushed back, and sometimes I got my way, and sometimes I didn’t.  I complained that by going faster, we were just digging ourselves into a hole and I just knew that we wouldn’t ever go back to fix some of the shortcuts we made.

Now I am in charge of a product which I am also the lead developer and architect on (small company).  I find myself wanting to use a phrase that I really dislike: “Perfect is the enemy of good enough.”  (I never liked that phrase, because I had seen it used to push teams to cut way too many corners both in development, as well as product design.)

I find myself telling my colleague things like “ideally we would do x this way, but we are on a tight deadline, so we will have to do it this other way”.  (I typically put in a card to go back and fix the shortcut later.)  I really enjoy that he pushes me to do things the right way rather than taking shortcuts, because I know I shouldn’t, but I am feeling a lot of pressure.

But, we don’t live in a black and white world.  We live in a world with lots of (fifty)shades of gray (and lots of other colors to boot).

One of my nieces just started college, and she is taking a course in programming.  I was talking to her about it last week, and she said she didn’t really like it because there were so many ways to accomplish the same thing.  I didn’t say it to her, but I thought to myself that what she said was true, but there are pros and cons to each of the ways you could do it, and with some experience you can figure those out.

And I think that is what this choice of “the right way” comes down to…using your experience to weigh the pros and cons of doing something one way vs another and making an informed decision.  Sometimes “the right way” in one situation is very much the wrong way in another, and I think we only figure that out with experience.

With experience we can figure out when to break the rules.  And that is ok.

School + technology = awesome

My son recently moved to a new school in the district.  I was really impressed with some of their use of technology (and less than impressed with other technology they use).  I wanted to share the things I thought were pretty awesome.


The 7th grade goes on a week long trip to a YMCA camp at the beginning of the year.  It is an overnight camp and many of the kids have never been away from family for that long.  My son was worried about it, and I was worried about how he would do.

The school did not allow the kids to take any technology with them.  That meant no phones, so there was no way for him to call and talk to us (this is because often kids get more homesick when they talk to parents).

The principal knew that this was hard on the kids and the parents, and used twitter to help keep the parent’s connected.  She tweeted out pictures of the kids almost every hour.  It was great to follow the feed and get pictures of my son having a great time.


In past years, the kids were encouraged to keep a planner and record what homework they had in the planner.  This never worked well for my son as he would either forget to write it down, wouldn’t have enough time to write it down or would forget to look in his planner to find out what he needed to do.

This year the teachers set up groups for the parent’s and students to subscribe to on Remind.  The service can send texts and it also has it’s own app where you can see the messages from the teachers.  It has been awesome so far.  I know what homework he has and can ask him specifically whether he has x done or not.  He also has an easy place to look to see when homework is due, and what is due.

Embrace Technology

I hope to see more awesome services/apps and use of existing services in the future in the schools.  If you have an app/service that you think the schools could utilize, talk to your school…maybe they will just adopt it.