The programming field has a stereotype of severely lacking inter-personal skills whether it’s being extremely introverted or an extroverted arrogant jerk. I don’t feel as though I have worked with either extreme, but every one of us (yes myself included) can use some time working on soft skills. These skills include, but are not limited to personalities, communication, personal habits, communication friendliness, communication, etc. that define relationships with their teammates. With the exception of the people making money off mobile apps and games and the occasional single developer team for a company, if you are going to write software more than likely you are going to work with a team and communication if you didn’t notice the triple mention above is one of the most important part of being a good teammate.

At my first programming job straight out of college. There were 4 men in the office 5 years out from retirement and then there was me. During a design discussion things got heated and two of the men were frustrated and were yelling at each other. Then at the same time they looked at their clocks and said, “oh it’s lunch time, want to go to Mexican?” The tension gone and all of us left to get lunch. I was a bystander of that conversation, waiting for the result to go back to my desk and code, but it shocked me that they compartmentalized the work discussion without attacking the person. This was a great lesson for me to learn early on. If they don’t like your idea, it’s not a personal attack. Things got heated, voices were raised, but as soon as the discussion was over it was as if nothing happened. At the time I felt that men had an easier time separating the personal from work, but as the years went by, I think that seasoned developers can be told the idea is not good and move on from there. Sometimes, if no idea has been suggested I’ll throw out a bad idea (stating that it is a bad idea), just to get the conversation moving.

Early on in a project I was pair programming and my teammate said the strangest thing to me, “I would rather hit the database than write an if statement”. He was frustrated with the direction of the code and we decided it was a great time for a tea/soda break. I couldn’t believe what I had heard and started to worry about the direction the project was going to take if EVERYTHING was going to come from the database. It turns out that this was not his intention at all. We were working on a RESTful Spring MVC business application and this was the first time “business-y” logic was being added and I had started adding it into a controller that was before this session a CRUD controller. For those of you new to programming acronyms, CRUD stands for Create Retrieve Update Delete. Our very nice and easy to follow controller was becoming more and more complex and after some discussion we moved the code into a new layer of our application. There were two takeaways: be deliberate and thoughtful in how you communicate and when you are programming, the first iteration is not usually what you will end up using. An inspiring book that covers communication is The Four Agreements by Don Miguel Ruiz. The first agreement he wants you to follow is to be impeccable with your word. To use the cliché saying, “say what you mean and mean what you say”. When pair programming sometimes the driver may need to get out a thought before the two of you can work out if that is what you want and where you want it. I find that it is a whole lot easier to see design patterns after code has been written.

These two situations I found myself thinking, “I can’t believe what is going on here!” The first I thought my male coworkers were attacking each other during the design of a feature. The second I thought my coworker was upset about the wrong thing. You never know what the person(s) are going through. Maybe that day was an off day, maybe they are in a fight with a spouse, worried about something personal, frustrated about a project they spent all night working on without success, etc. Keep positive, the anger or frustration displayed is rarely because of you, most things are all about them. Take breaks, ask questions, and try yourself to be impeccable with your word.

The task for this week is to make a hypothesis as to how you react when an idea is rejected. Then suggest an idea and write down how you react to other reactions. Do you become defensive? Do you ask for alternatives? Do you ask for modifications to build upon your idea? How can you respond better?