The body language is important in situations where there is confrontation, opposition and reaction. It is also very important even for simple and relaxed chats. When two people try to discuss a difficult subject, it is very easy to get the wrong signals reading plain text. It would be a whole better if people were chatting face to face or even using voice.

What plays a key role is whether a person is generally pleasant when you are around them in the same room. When people smile a lot and generally approach things in a positive way, they are likely to transmit the same feelings even when someone is chatting with them using plain text. What helps, is the image of that person in the mind of the other chatting party. It’s the memories of the mood that person is in when interacting closely with the other party.

For example, when I chat with a person that is very distant and negative when I am around them, I get the same feeling when chatting with them using IM. It takes some effort to perceive what they type in a positive way even if they don’t say something in a negative way.

Being pleasant, smiling and open to your colleagues is a key factor towards a better communication even using text messaging.

The Daily Scrum is:

Daily Scrum
Each day during the sprint, a project status meeting occurs. This is called a “daily scrum”, or “the daily standup”. This meeting has specific guidelines:

• The meeting starts precisely on time.
• All are welcome, but only “pigs” may speak
• The meeting is timeboxed to 15 minutes
• The meeting should happen at the same location and same time every day

During the meeting, each team member answers three questions:

• What have you done since yesterday?
• What are you planning to do today?
• Do you have any problems preventing you from accomplishing your goal? (It is the role of the Scrum Master to facilitate resolution of these impediments. Typically this should occur outside the context of the Daily Scrum so that it may stay under 15 minutes.)

We are a remote team and we had to tweak it a little to fit our needs:

• Every morning at 10:00am we go to a Skype group chat that is only used for our Daily Scrum Meetings
• Each one of us says what they did yesterday, what they plan to accomplish today and mention any problems they have.
• Problems are then discussed after the meeting.
• The meeting never lasts more than 20 minutes.

Results are positive so far. First of all, we feel that someone hears what we do everyday. If we have any problems or questions we can ask our fellow team members for help. We are committed because we promise a daily plan and we want to deliver it. We stay focused. All that, by spending 20-30 everyday to plan our day and present that plan to our colleagues.

References:

1. Scrum (development)

We are 4 and we work 4 days per week remotely.

We do roughly 32.000 kilometers to go to work and get back home, so that’s 32.000 less per year.

Assuming our cars emit 160g of CO2 per kilometer on average.

We emit 5.120.000g less CO2 per year!!!

That’s 5.12 tonnes less CO2 per year!!!

And this is our action for the environment.

What I really like about this tool is the ease of use and the lack of unneeded options and clicks to get your job done.

I use Jing whenever I want to create a new case using FogBugz. For example whenever I want to report a bug or ask for an enhancement, I may capture the part of the screen of the application, annotate and save it to attach it then to a new case in FogBugz or send it directly using Skype to the remote programmer.

Sometimes, I even capture a video showing how to reproduce a bug. Capturing a video with Jing is very easy because it does exactly what you need, nothing more and nothing less.

Here is an example FogBugz case with a Jing screen capture with annotations for one of our internal projects. We develop this application using DevExpress XAF which is a very good framework for developing intranet applications.

FogBugz Case

This way, I can write fewer words than if I hadn’t prepared the screen capture. I will also try to post a video capture example in the future.

One of the problems working remotely can bring is the feeling of separation from the rest of the company. Although this is not obvious at the beginning, I am sure it can happen and it can lead to unwanted results. When you start working remotely, you appreciate the fact that you can be isolated. This is true because you are already frustrated by the working conditions in the office and being isolated is a gift. As time passes, people in the office may start bothering you less and less. Face to face communication is almost non-existent. Quiet working environment is nice, but some noisy breaks are essential to appreciate the quiet. After a while, you start feeling unneeded, isolated, separated and not included in the office day to day happenings. This can lead to sadness and even melancholy or depression if the separation continues to a great extend.

I decided to deal with this from day one. Our work week goes like this: 4 days remote, 1 day in the office. This helps eliminate most of the problems I mentioned above. We chose Friday as the day we come into the office. Friday is usually a slower day because most of us have already burned a lot of gray cells during the week. This means that most of the people prefer face to face communication for a change. I also hope that this will make everyone wait to use Friday as the “communication” day. We also want to start using Friday as the day to present the results of our weekly iterations, and other technical findings we would like to share with the rest of the team.

We also have two rules: 1) We come into the office whenever we realize that being remote may slow us down when dealing with urgent situations. 2) We come into the office whenever there is a major release that is going to be deployed to the customer. These rules increase our “office time” and help us keep in touch with the rest of the company.

I have to say, however, that all the programmers — including me — have already been working closely in the office a long time before we started working remotely. This means that we already know each other pretty well and we have a very good relationship. The fact that we are all 30-40 minutes away from the office helps maintain this relationship. It is not a problem for us to visit the office whenever we need to.

Our visits to the office at least once a week, help to keep us connected to the rest of the company, but what happens during the rest of the week? How does my team communicate?

We use Skype as the main tool for communicating, either by using IM or voice/video calls. I will come back to this with more details in a future post. What I want to tell you though is that we work “closely” during the week, using technology. So far, we don’t feel disconnected at all. Time will tell if we keep on feeling this way.

I also have some ideas that we haven’t tried out yet:

• Team going out for coffee once a week or once every two weeks
• Same as above, but instead of going out for coffee change that to tavern
• Extend the weekly presentation or bi-weekly ones to the whole company or other departments we cooperate closely
• Engage to sports with the participation of the whole company (although we tried that in the past and it doesn’t seem to be able to get established permanently)

What do you think? What else could help us stay connected? Do you have similar experience you can share?

I identified the following factors:

1. A lot of noise outside our office
2. A lot of interruptions either by fellow employees, by the management or even by members of our team.
3. Not enough facilities to relax or make small breaks without thinking about the job
4. Lost time for commuting
5. Not a viable way to exercise before, during or immediately after work.

I presented my proposal to the management. Although, the initial reaction was positive some skepticism creeped in later and we spent about 6 months thinking it over, until two weeks ago when we finally started working remotely.

Although we discussed a lot of issues with management, I identified three major concerns they had:

What if anyone in the company wants to communicate with us directly?

When I say directly, I mean someone opening our door barging in, and start “communicating” regardless of what the other person is doing or if they want to be interrupted.

I said that this should not be a concern. In fact, not being able to communicate directly would be a benefit. That led to the next concern.

What if people start spending more time preparing feedback for the development team?

In the company I work, there are three methods for giving feedback to the programmers: 1) Using FogBugz, 2) “Communicating” directly, and 3) A combination of the aforementioned methods.

Direct and informal communication is the least work for someone. It can be also viewed as a tool that helps us organize our thoughts. We think out loud, throw our thoughts to our listener and they help us polish our thoughts by occasionally expressing their opinion.

This is all good and fine, if it happens with the consent of the listener. Unfortunately most of the times this is not the case. Furthermore, the majority of people are kind and try to be polite by not making it clear to the interrupter that they didn’t want to be interrupted in the first place. However, the ultimate truth is that programmers don’t like being interrupted.

Consider for a minute a car production line. No one in their right mind would ever think interrupting the production flow, even if restarting it might take a few seconds. Why, then, is it natural for most people to interrupt a programmer? Their “restart” takes about 15 minutes and after a couple of these, the whole work day might go down the drain.

You can either be polite and ruin your flow, be harsh and ruin your relationship with your fellow coworkers or maybe choose an alternative that may eventually make people come to you as a last resort.

Nevertheless, interrupters complain that all other forms of communication make them lose time. Writing, taking screen shots, making videos, talking using Skype or similar IMs, or making mock-ups takes more time and needs more effort than barging in and talking directly.

I say that taking more time to create descent feedback brings better results, because the effort and the thinking one must do forces them to do a better job.

However, what happens when something urgent comes up and trying to communicate without direct contact is inefficient? Which brings us to the next concern.

What if something urgent happens that demands direct communication and cooperation?

Usually after a fresh software release (but not only) problems arise at the customer. These are the problems that couldn’t be caught by the programmers and the testers. Sometimes, these problems might be show stoppers and that is when the issue is marked as urgent. The pressure by the customer and the management is big and people that try to solve the problem are anxious and in a hurry.

This is a situation when direct communication is better. We chose to deal with such situations in a proactive way. Each time we know the chances are high for such urgent situations, the programmers involved should be in the office. For example, the day of release, the programmer in charge of the project comes in and is available to solve any urgent problems.

Of course, problems don’t always appear at the same day of the release. They might even appear months later. We created another rule for that. The programmers come at the office, if they feel they can’t solve a problem quickly because of the fact they are away. This is possible because every programmer is 20 to 40 minutes away from HQ.

The team works remotely two weeks now. The first feelings are positive. I get reports from my fellow team members about how wonderful it is to work without being directly interrupted. Also, how less they get tired during the day and how peaceful it is to be at home. They also say they feel their productivity improved, but I think we need more time to reach a safe conclusion.

Our fellow consultants and testers, look at this positively and I want to take the opportunity and thank them for their patience. Of course, they spend more time trying to prepare their feedback, but it is very early to say if the time they spend will remain at the same levels or whether it will drop. Also, we don’t know yet if the time they spend is compensated by the potential increase in the programmers’ productivity.

Finally, ITS S.A., the company I am cooperating very closely with, is I think among very few companies in Greece that would allow such an experiment. If I am wrong, please feel free to post a comment.

In my next posts I will try to describe how we try to avoid alienating the team and generally disconnecting them from the workplace. Also, I am going to write about more practical things we do and tools we use to help us work remotely.

I would be very pleased if you posted some comments with questions I could answer or with your experience in similar situations.

Related articles:

• How to avoid alienation while working remotely
• Using Jing while working remotely

If I was a candidate for that position, reading that word would make me wanna stay away from that company. Of course this is just a personal opinion. You can always try to fail multitask if you want.

I don’t believe in either/or mentality. I believe we should always find what works for us by trying different things and experimenting. I did that a lot of times in my career. Having said that, here are some thoughts about this question.

Spending years only on one technology can harm you in some ways. Everything looks like a nail to you if your only tool is a hammer. You try to solve every problem with the tool you know how to use better. This is great if the problems you are trying to solve are the kind of problems your tool solves better. However, what about other problems, where your tool is not so great at solving?

Some times, knowing more than a couple of programming languages, comes handy when there is a crisis in the job market. There was one friend of mine who didn’t want to learn anything else except the language he used for over a decade. One day, he lost his job. Unfortunately, only then did he realize that the language he knew inside out was no longer in demand. He struggled a lot and had to change from being a programmer to being a member of IT in some company that used that language and needed maintenance work. This teaches me, that some times, when you have your job and feel “secure”, you are also unaware of what is going on in the technology world. Especially if you are not willing to learn different things. This has the danger of learning about it when it is too late.

Even if you never lose your job, or never change the language you are using, it is still better to learn other languages because you can expand your thinking and deepen your understanding of programming.

Let me give you an example from my experience: Many years ago I was using Pascal. At that time Pascal wasn’t object oriented. I was always on the look for new paradigms, and suddenly the world started talking about OOP. Every magazine was talking about it (we didn’t have Internet back then).

I wanted to start using a language that supported OOP, but I couldn’t because none could ran on my computer. I couldn’t wait to buy a new computer, so I started using the paradigm even though my language of choice didn’t supported it. Pascal supported records, pointers and procedures/functions. If you try to see what a class really is, you will realize how I simulated classes in a non OO language.

Having mentioned “paradigm”, I would like to say that it is better to learn different languages of different paradigms, than languages of the same paradigm. Languages of the same paradigm just change in syntax, but only if you learn about different paradigms you can really expand your mind. Examples of different paradigms are: procedural programming, object oriented programming and functional programming.

Some complain of not having enough time. When I was very little, I once complained about that to my father. He told me to sit down and explained to me his theory for time management and planning. I try never to complain again about not having enough time, but lets pretend you don’t have enough time:

You can focus on your “day language” (the one you use every day at work), but at least study one new language as a side project. When I say study, I suggest that even if you don’t build something useful, at least read the theory and try to do a couple of tutorials. Even at this rate it is still better than only sticking to your “day language”.

I don’t want to forget mentioning that of course the fundamentals are very important, but how can you really learn the fundamentals if that knowledge doesn’t come from applying the languages? I assume you have already read more than 10 theoretical books on programming fundamentals, but that is just the theory. You should also apply that through the use of many languages. Not only one language.

To answer the original question: I always like to have a main language and a side language. Nowadays my main language is C# and my side language is Ruby. Respectively, my main framework is .NET and my side framework is Rails. If I see that I am mastering Ruby, I will find time for another paradigm. Maybe Ruby can become my main language, in order to make time for the new one

Finally, I want to answer the concerns my friend expressed about what is better to write in his resume. If I had to decide hiring one programmer among two equally good programmers and  the only difference was their language focus, I would choose the one who knows more languages because I believe he would have a deeper understanding of programming.

Joe, tried to persuade everyone to use that tool for any form of communication between all and the software department, ditching email. Most did that, but there were two occasions when that wasn’t the case:

1. People who thought it was better to call Joe, describe a bunch of cases to him orally, and then hope Joe would remember everything and go and create the cases himself.
2. People, who although were willing to write the case, they first needed to ran it by Joe orally.

In both scenarios, both types of people just interrupted Joe. They seemingly didn’t respect Joe’s time or concentration. Was this the case though? Was it they didn’t really care or was it they were ignorant and uneducated. After all, can you blame the ignorant?

Joe was trying not to get angry, but he couldn’t always succeed. Joe had a hard time explaining why he didn’t want to be interrupted. He couldn’t even find the right words to make other people aware of his situation. He thought that others thought he was a selfish bastard for not wanting to be interrupted.

Joe, really believed that even one interruption, that would also cause his nerves to stretch, could easily ruin the productivity of a whole day. Imagine that: A whole day’s worth of productivity down the toilet.

Joe thinks of a future where co-workers are not bored to write in detail what they want from him while he is able to get things done in a calm environment. He smiles thinking that having a dream is better than nothing.

Today, after many years of reading, thinking, experimenting and concluding I realized what my 1st deed should be:

I am devoted to one cause. I always try to create the best working conditions for my fellow programmers and as a result enable them to wake up every morning and be anxious to start working having fun. I am also devoted to raise everyone’s awareness about this important subject.

The “working conditions” problem has always been on my mind, since I first started working as an employee for a company back in 1998. It was two years later in 2000, when I discovered Joel Spolsky and his blog Joel on Software. It was the first time I was reading about what was bothering me: The working conditions of programmers. Joel’s articles helped me realize that this is a real problem and that a company can be built having as a core competency the continuous efforts to create the best working conditions for its programmers.

All these years, I was in a position with no power until now. I am now the leader of the software development of a company that allows me to experiment and create the environment I think is best for the team members.

I have created the “1Deed Programming==Fun” category where I will put all my posts about this deed. In future posts I will describe what I am doing to have the best working conditions for me and my fellow teamates, and also what I am doing to help raise the awareness of everyone about this important subject.