7 telecommuting tips for developers

Working from home or a private office is probably the future of knowledge age companies. It allows you to do away with commuting completely and to work in a quiet  and non (over) interrupted environment (if you decide to).  It’s the opposite of the open space office. The gain in productivity can be huge.  Both you and your (smart) boss are potential winners in the deal, not to mention the potential real estate saving for the latter.

Unfortunately, telecommuting is not for everyone though and this may be why it is not generalized yet despite the positive conclusions of the studies on the subject.  Procrastinators may find it very difficult stay as productive as they are at the office. You will also need lot of independence and self confidence.  Some employees may also suffer from isolation.

Procrastination and isolation are the two problems I will address in this post. Other problems related to telecommuting won’t be debated here such as:

  • security concerns,
  • the fact that telecommuters are less likely to be promoted (Kreitner & Kinicki, 2009),
  • potential loss of thrust by managers
  • communication problems with your team

Here are the 7 things I strongly suggest you to try.  I have experimented with this myself during the past 10 years. They provide some tips to help avoid both procrastination and isolation. Disclaimer: you may adapt them to your particular case and not take those empirical & personal observations as a generalization of what to do. I really encourage you to share your own experiences on the subject in the comments.

Procrastination

1. Use a schedule – as if you were in a formal office.

If you don’t do so, you will be tempted to work too much or too little, depending on your personality. Both are problematic long term. Having a fixed schedule will not only create some sort of rule to manage your time, but also help you beat procrastination.

One of the keys to beat procrastination is to have “starters” and avoid “retarders”.  If you like to do non work related stuff such as reading news or browse internet, reserve 30 minutes before and after your fixed work time for it.  When you feel the need to do it while you are into your work time, remember you will be able to do it after.  It usually calms down the need for it and after some some time, the addiction will disapear.  When you arrive at your work time schedule, close everything and start working. This can be hard the  first few (ten) times, then after a while the habit will kick in.

In order to avoid the frustration of having to leave off work in a middle of something, I try not to start debugging or another task that has unpredictable time duration at the end of the afternoon.

2. Replace commuting by physical excercises and meditation/relaxation.

Telecommuting will free up a lot of time, and you should take it as an opportunity to take care of yourself, and certainly not work more for the same salary. Consider taking up physical excercies and relaxation or meditation. It will improve your overall productivity and will contribute to reducing procrastination (Davis & Jones, 2007).

3. Take regular breaks

Since you don’t have your environment anymore to remind you it’s time to take a pause, use the pomodoro technique. I personnaly taking a break of 10 minutes every 45 minutes, but you may setup your own schedule. I use a special software for that called Workrave that I warmly recommend to you.

The pause can be either doing nothing (it’s what I do every other break) and free your mind or do stuff off your computer such as class papers or call a colleague.  In any case, this should occur in another room, and certainly not in front of a computer.  I personally do three minutes of mindfulness or simple observation of what is happening outside (simply being in the present moment).  Feel free to adapt this to what works best for you.

At noon, take a full break and don’t eat in front of your computer.  Some of you may enjoy some cooking time while others may be very relaxed by some time listening to music.

4. Put clear limits between work and your normal life.

This means you have a dedicated office/room you don’t use for your pleasure but only work.  This is very important especially if you have kids.  Your office should not be used to anything else than working. This also means:

  • don’t work on your laptop when you are watching a movie with your family
  • avoid any professional activities during the weekend
  • remove all work thinking and be 100% mentally available for your well beloved
Isolation

5. Go to lunch outside.

< Isolation is the other major inconvenience to combat if you are affected by it. To avoid isolation a great solution is to integrate a social lunch with others. Try to do this at least once a week.  Even if not with someone else, try to go outside at noon somewhere there are other people.  Why not with other telecommuters?

6. Do co-working.

Co-working is the new trend that involves a shared working environment for people even if they have independent activity. It feels like your office, but it’s not. To make this work, the co-work area must be close to your home.

7. Don’t telecommute every work day.

If you telecommute every work day, you will progressively become more and more disconnected from your company’s culture and people.  It’s inevitable and it will happen.  Be sure to dedicate one or two days on site.  When on site, go to lunch with your colleagues.

 

I love software development, but I hate doing it for a boss

Unless your boss is really a bad guy, you should reconsider the feeling. If it’s just that you don’t want to work for someone, don’t work at all. Because when you have your business you work for a boss much worse than your existing one: yourself. You will eventually work for many other bosses that really don’t care much about your feelings: your customers.

If you really love software development, if it’s what you are made for in life, creating your own company may be very disappointing. Today you do what you love (developing software) for most of your time. When you are an entrepreneur, you handle many other unpleasant tasks. You have no choice but to increase your work hours to be able to produce valuable lines of code. You will have to do lot of administrative tasks, handle customers (requests, complaints, questions, …), learn legal & accounting stuff, call people, sell your stuff, handle employees (requests, complaints, questions, …), think about tons of things at the same time … all of this increasing your overall anxiety and fatigue.

Here is a quick test to see if you, as a developer, are likely to succeed as an entrepreneur. Answer each question by true or false.

1. I dislike the sales part of the process and prefer to make the product

2. I’m a perfectionist

3. I won’t accept to be paid less than my market value for an extended period of time

4. I really like to take care of the details

5. I really dislike being criticized by other people

6. I don’t have any savings or personal investments

7. I have never been fired

8. I don’t have friends or family that run their own businesses

9. I am afraid of losing all my assets

10. I’m an anxious person

If you answered “True” at least three times you should seriously reconsider creating your company.

If you really want to start your own business, consider creating a consultancy company first, then create your products later. Many successful software companies started like this. It works because the services (much more easy to get money from) pay the bills while you develop your products. If the product fails, it is no big deal.

WHO broke the build?

Breaking the build is highly prejudicial to the productivity of a development team. Since it’s pretty easy to avoid it by ensuring that the code compiles locally against the latest version and doing continuous integration, it is often taken as an act of rudeness.  The person responsible for the act must therefore be punished.


Photo courtesy of seeb’s Photo Stream

The punishment often consists of making the guilty party wear a specific hat (we use a Sombrero) or any other very visible humiliating clothes, until they solve the problem themself.  In addition to this, some teams may want to signal breaking builds with a specific sound played on speaker (we used a darth vader or homer simpson voice).  Some teams get even more creative as you can see in this video.

I found the whole thing very funny and I always promoted it in every team I worked in to reinforce team spirit.  That is until I met a couple of people who were really reluctant to join in and did not want to publicise their actions.  Even when I broke the build on purpose to wear the hat, it did not change how they felt about it.  One of them was from a different country where such humiliation could not be taken to this degree (as we can, I hope).

I think this kind of game is one of the many things we see online and we want to replicate without thinking, but it is not always a good idea. While it can be a very good team building feature, it can also contribute to making some team members very uncomfortable.

If you really want to do it as the manager/team leader, ask every one in the team individually. Asking in front of others will prevent you from getting honest feedback.  In fact, it’s usually better not to implement such a rule in your team unless it’s really something everybody wants.

 

 

 

How to successfully enter a new company or domain

As a consultant, I worked in various domains such as utility, telecom, aeronautics, finances, insurance, etc and I’ve faced the problem of not knowing very much about the domain I was entering.  With time, I discovered a very simple method that works: being actively curious.

  • Request a one to one introductory meeting with your supervisor with the purpose of getting them to explain the business domain (the big picture). It should not last more than 4 hours (or you will get bored and your supervisor exhausted).  Prepare your questions in advance.  Take notes.
  • Ask the supervisor for a field visit. When I worked in the telecom industry, I asked to visit the router and transmission rooms as well as the NOC (Network Operations Center). It helped the team building the software to understand the purpose instead of blindly writing code. We knew why our stuff was useful and more importantly, who will be using it, and how.
  • Have frequent lunches with suits.  More frequently, I would say, than with fellow programmers. They love to talk about their stuff and if you listen carefully, you will learn lots of amazing things.  Be prepared to share some amazing stuff with them too or they will soon find you very boring.
  • When you have the chance, visit the departments. Ex: when I had to work with a marketing manager of a big finance institution, I asked how our applications helped them and what was her routine.  By actively listening to her, I was able to find out new stuff to automate and make her work life easier. I suggest you make a physical visit rather than a phone call.  This means you can see her doing the thing and more importantly, using your application!  What is obvious for you may not be so obvious to the rest of the world.
  • Buy books on the domain and watch youtube videos. Read your domain’s information websites as well. Give priority to higher level literature. Books that are too technical could be boring or impossible to understand in the beginning. What you need is general concepts to fuel conversations and learn more.
  • Talk about it to your friends & family often. Talking about your stuff will help you integrate the huge amount of information you must learn. Prepare an elevator pitch and be prepared to give details. Don’t hesitate to write it down so it is easy to remember.
  • Read all the news your company publishes. Including annual reports. In fact, the first thing to do when you are hired by a new company, is consult their website and publications.
  • When you don’t understand something, don’t hesitate to ask the guy in the company (email preferred) that can answer your question. The worse thing that could happen is being told that (s)he has no time for that.

Remember this: the developer that knows the domain very well is no longer just a simple developer.  You are a little more than that.  And so is your market value.

The Agile Essentials Checklist

Here a “light” Agile Software Development checklist that I have used for many years to introduce Agile in organization. I usually introduce few items per week.

Product Management
  • A product Backlog, estimated and prioritized by a “Product Owner” is used
  • A “Release Plan” exists and is known by the team
  • A “Company Strategy” exists and is known by the team
  • Features are divided into “User Stories”
  • The “User Stories” are estimated by the whole team using “Planning Poker”
Workflow
  • The development work is divided into iterations or timeboxed “Sprints” or “Iterations”
  • A “kanban” or “Information Radiator” is used
  • The tasks are not assigned, the team organizes itself
  • The “Velocity” of the team is known
  • No outsider can interfere directly with the team during an iteration
  • “Daily Meetings” take place and do not last more than 10 minutes
  • A “Sprint Review” is organized and the output recorded
  • A demonstration is held at the end of each iteration
  • The problems are tracked and by the “Scrum Master” and/or management
  • A proper Retrospective is held
  • A “Burndown” graph is updated daily
  • The “Code Reviews” are systematically organized
Development Tools & Rules
  • A source controller is in place
  • A continuous integration build server is used and testing (unit & guidelines) takes place at each commit
  • The packaging of the product is fully automated
  • A (simple) bug management tool is used
  • Each bug is reproduced in a single test and then corrected
  • 80% of the code is covered by automated testing
  • A “Solution Log” in WIKI form is used
  • The “Coding Guidelines” are defined and understood by all
  • A maximum of 40 work hours per week!

Please note that any numbers above can be adjusted to your reality.