8th Light Blog

The other day, I was with my team at an interview for an internship. After we had asked the candidate some questions, he started to reciprocate, asking each one of us a little about our development past. Every one of the developers stories went something like, I was at the wrong job, and had to get out. The candidate listened carefully to each story, sat for a minute, then asked the obvious perfect question, “What makes the right job?”

I heard responses like “Waking up in the morning and being excited to work, rather than counting the days until the weekend.” The reason this struck me as interesting was only when I reflected back to why I loved computers and programming in the beginning. It was all about the problem. I went to college, so I could join the CIA or some think tank which wrote software which monitored and defeated the enemies entire world. About every developer I went to college with got into computer science with some similar grandiose notion. Most of them were gamers that wanted to work on the next big game. Yet today, I know no developer who works on games, and I don’t work for a think tank. I know lots of developers who are more than qualified to do it, but choose not to. So, how does this relate to the right job question?

The answers about the right job question had nothing to do with the problem set being solved either. Nothing to do with WHAT applications were being written, but the culture and with whom they are being written. I think this is because each problem set worth application development proposes unique and interesting problems for a developer to solve. I have never been on a project which didn’t constantly keep me on my toes as far as problems to be solved. Even if the business domain is a bit bland, the development domain isn’t. I have seen developers to do lists get bigger and bigger from day one on a project, and never shrink. This has nothing to do with laziness, quite the opposite, it has to do with an insatiable drive to make things better than they are.

As a developer, my problem set isn’t the business/science problems I am solving, even though that might be interesting in itself. My problem set is development itself, the different patterns/practices I use to solve the world’s [software] problems. It is like many art forms where the beauty and creativity exists in the process of creation rather than the results. I am sure you could have asked Pablo Picasso to paint something he didn’t have any interest in, and he would have been passionate about it and done a wonderful job. I suspect it is because the importance is in the painting process and the choices you make during each step. How he chooses to depict the subject is more interesting more than the nature of the subject itself. I find the same true in development. The thought that goes into the different development choices I make on a daily basis is the part that drives me to love development.

Having the right results is only part of the equation (an essential part though). When I started my path as a developer craftsman, I learned the WHAT in applications is not as important as all the other variables. I suspect some of the other members on my team would agree, based on their answers to the right job question. Being part of a company that values the software for its own ends and spends the time and attention to do it right is a privilege to me. To me, that is the definition of the right job. I enjoy knowing my software will be used. Everything I write is valuable to the company for its longevity and success. It takes people who are similar in values for it to work, but it makes the work fun. It makes me wake up before my alarm, rather than snoozing.

One of the famous studies on peer pressure was the Stanford prison experiment. A group of average people were selected to play either a prisoner or prisoner guard. As the participant became engrossed in the role, the peer pressure from other participants quickly degraded their moral compass. The small negative actions lead the groups to quickly fall into patterns of behavior which were unlike their own.

I see peer pressure work in the same manner for good all the time. Since software is written by teams, the software is often a reflection of how well the team works together more so than individual skills of the developers. When you have a group of developers who entice each other to do good work, the outcome can be great work.

Creating a culture of positive peer pressure is about doing lots of little things. Small positive actions will lead the team to create positive patterns of behavior.

Here are different techniques which have worked for different teams I have been a member.

1. Name your team, not just your project. This gives me as a developer some self-identity as part of a team.

2. Greet your team mates each day. We shake hands to show respect each day for each team member. We generally start and finish each day with a handshake. This can alleviate tense situations by itself, as personal contact often does. No chance to avoid a team member.

3. Do some activity everyone enjoys. Anything from eating lunch together to playing a competitive game as a team. We have played basketball together. Being competitive with my team gives me pride in the team, win or loose. Get to know your team members.

4. We keep a good supply of coffee, tea, snacks, and gum for each other as gifts. This act of giving to the team promotes the selflessness any team needs from its members top succeed. There are different levels of skill on a team, but each team member is important. It is difficult to write software for any project of magnitude without the full contribution of each member of the team.

5. Switch pairs pairs often. When you work with everyone on the team, you feel closer to everyone on the team.

6. Talk while you pair. Reading someone’s mind takes more effort than talking. Talking aloud also is a great way of brainstorming. Pair communication starts when words become sound waves.

These small things can improve the accountability and creativity to make a well functioning team. A happier team will become a creative and productive team. A team that has a strong sense of togetherness will lift each other up when needed. I find myself more willing to step up to daily challenges with the support of the team on my side. There is no place for apathy and complacency in a team which has pressure to succeed.

When the team succeeds, as positive teams often do, it becomes a group success and brings the entire team great pride. A team which pressures each other to do better can turn an average developer into a great developer.

The most widespread and common greeting in the American culture is the handshake. Handshakes are shared between anyone meeting for the first time, to finalize a business deal, and to end a conversation. I spend a good deal of time around 2nd and 3rd generation Korean-Americans. In Korean culture, like many Asian cultures, the handshake is replaced by bowing. In these transitional immigrant generations, the bow and the handshake have been merged into one awkward action. I was recently walking through the reception line at the wedding of 2 second generation Korean-Americans and I went to greet the 1st generation parents. I was going to try to be respectful and offer a bow instead of a handshake, but just as I began to bend, a large hand was thrust out in front of me. I felt myself lucky that I didn’t end up with the guys finger in my nose.

One of the things I immediately noticed as I began working with the craftsmen at 8th Light is that everyday I walked into the office, every member of the team shook my hand. As each team member left for the day, he shook the hand of everyone who was left. I expect this on the first day, as you always shake hands with everyone on your first day. On the second day, I thought maybe they had all forgotten that they met me yesterday. As I realized that this would continue, It really made me start thinking.

As I went to work with another team for a little while I came to really miss the handshakes. I’d walk in the morning and maybe get an eyebrow flash from my teammates. A “Hello” would come if I was really lucky. I decided enough was enough, so I just started shaking hands. At first, I got some really weird looks and was left hanging a few times. The looks seem to ask “Why are you shaking my hand, we see each other every day.” But slowly it started to catch on. My teammates began to expect a handshake from me at the start and end of each day.

Here’s what I think these bookend handshakes do for a team. First, believe it or not, a handshake becomes an intimate gesture. It communicates genuine care and concern for each other. To me it’s a physical expression of the XP value of Humanity.

Second, it communicates respect. Sometimes design and project discussion can get very heated, especially if you are working with a passionate group of people. If your days begin and end with a handshake, everyday is bookended by a statement of mutual respect. There is a proverb that exhorts people to “Not let the sun go down on your anger.” That handshake is a way to let go any residual anger from the day and commit the next to dealing with each other with respect.

Third, It’s an honest statement about the hours you are working and the time you are putting in on the project. In a handshake-free environment, if I’ve had to leave the office early, I’d usually try to sneak out without anyone noticing. At the time I was in an office culture that promoted flexible hours, but you always felt like people were watching you to make sure you were still putting in your hours. I always put my time in, but because I sometimes played with my schedule quite a bit, I was always afraid that someone would perceive my time poorly. When an handshake begins and ends your day, you are being direct and up front about your time. You are communicating at the start of the day “I’m here, I’m ready to work” and at the end of the day “I’m gone, my day is over.” There are no apologies, no sneaking in or out, and no elaborate time-tracking system. Your teammates trust that you are working as much as you should be and you are not likely to try and cheat you company or your team out of your time week-to-week.

Try it in your team. It’s a morale boosting behavior that will cost a team nothing to implement, but will be one baby step to improving the strength and productivity of the team.