I spent the first year of my first programming job afraid to ask for help. I was the new guy on a team full of older, more experienced engineers and they didn’t know if I was in the right place. I didn’t know if I was in the right place. I made little lists of all my teammates, careful not to ask any one of them too much and certain to never ask the same question twice.

There was a hierarchy on the team and I was on the bottom. The rules were simple Book of Dead Slot Machine. Help was our currency; the people above you gave it and the people below you needed it. Every time someone helped you they went up a little and you went down a little more.

At the end of that first year I climbed to the next rung on the ladder and someone finally asked me for help. Nobody asked again for another six months. And so it went. I slowly climbed a little higher, careful to never ask for help from anyone below me.

Hierarchical teams are common everywhere. Giving help is seen as strength and asking for help as weakness. The catch-22 is that asking for help is the best way to get better at your job and move up the ladder. Open source software turns this pattern on its head.

Open source projects can’t afford the overhead of making their members climb the ladder, but they also don’t have much to offer those who do. Raises, promotions, and corner offices don’t mean much to a group of volunteer hackers working remotely. Open source projects (at least some of them) rebuild the ladder and trade help in a different way.

Open source projects also change the way they exchange help because they fear forks. Like a fork in a the road an open source project can split in two. Forking in open source happens when one or more project members decide to copy the code and start their own project. If the project community doesn’t encourage new members well enough the project will either fork or fail.

It was Jim Blandy from Mozilla and the Subversion project that first introduced me to the social currency of open source. Jim’s a hacker who leads with teamwork as well as technology. Instead of rewarding the people who give help, open source projects reward the people who take it.

The infectious enthusiasm of Jim Blandy

Jim is an open source zealot and one of the first people I interviewed for The One Minute Commute. I spoke with Jim for about 20 minutes before I was ready to quit my job and work wherever he was. Common sense and restraint stopped me from asking him to take my resume, but I couldn’t stop wondering how he did it.

I felt refreshed and excited about my new book project after talking with him, but Jim was no cheerleader. He asked hard questions and really wanted me to figure out the answers. He made it clear I was asking for his help when I interviewed him, but he did it without even a hint of any negative connotation.

It makes sense in his view of the world. Open source teams need contributors who can accept help and be part of the team. All the rewards of open source are in your ability to contribute usefully to the project.

The social currency of open source creates an open team structure completely different from the ladder I started climbing when I was a young engineer. You can stand up and ask for help. You’re required to. It creates an openness on the team and open teams make you smarter much faster than closed ones.

Open teams also feel better to work in. Instead of being afraid to ask for help the entire team can work together. The less experienced team members get smarter, and so do the more senior ones. It doesn’t matter how much you know, there is always someone who knows something you don’t.

Open teams are also much nicer places to telecommute since climbing that ladder is tough when you aren’t in the office.

How to ask for help

So far we’ve seen the good sides of open teams, but if everyone asked for help with everything the team would grind to a halt. Open source projects solve this problem by telling you how to ask for help. They usually call it a hacking document.

With this document the project makes it very clear how to ask questions. Each project is a little different, but most open source projects want you to take the following steps before asking a question:

Read the manual. Don’t ask a question you could easily look up.

Read everything else. Don’t forget about mailing lists, wikis, and FAQs.

Ask the right group. Most projects separate questions about how to use the project from questions about how to develop new features.

Try to figure out the answer yourself. Get informed about the question by trying to find your own solution.

The last point is the most important. Help works best when it isn’t one way. If you bring something to the table and start a discussion then people will join in. Show them that you’re making good progress and they can help you help the team. Never ask passive questions.

Pry your team open

If your team is closed you can pry them open. The open team environments are so much better than the closed ones that they sell themselves. You just have to show your team the way.

Lead by example. The first person your your team who should be open is you. Show your teammates what an advantage being open can be.

Look for excuses to ask for help. Any excuse will do. Ask for help from someone more junior than you. Make sure it is in an area they know well.

Show the results. After you ask for help don’t hide it. Let your entire team know how it went. You don’t need a status report, a simple email about the cool new thing you learned from Bob will do.

Open teams help everyone, not just teleworkers. They encourage communication and make everyone smarter. However, teleworkers are in a better position to pry their teams open. As a telecommuter you do more of your work in public and have more of a chance to show your team the positives of collaboration.

Ask for help today

I don’t normally assign homework, but this one is worth it. Ask someone for help today. You can start with something small, but do it publicly. Make sure everyone on your team knows the results even if it went badly. Then try again.

Openness is a habit your team needs time to cultivate. It takes a little work, but it makes a much better working environment. So how will you ask for help today?

http://credit-n.ru/zaymi-online-blog-single.html http://credit-n.ru/offers-zaim/dozarplati-srochnye-zaimi-online.html

The One Minute Commute is a free eBook written by Zack Grossbart. It shows you how to get and keep a job as a successful remote software developer. You’ll learn how to interview for a remote software development position, how to convince your boss that distributed teams can work on any software project, and the tools you need to work away from the office. You’ll see step-by-step instructions on how to effectively communicate with your team when you aren’t physically present for day-to-day meetings. You’ll find out how to avoid the pitfalls and drawbacks common to being a remote engineer and become successful working remotely.

Still not convinced? Need a few more details? Here’s a pretty good argument why you want to read The One Minute Commute.

You want to stop commuting, have less stress, and put more of your time and effort into excelling at your job. A one minute commute sounds like a dream come true, but it isn’t easy to overcome the challenges of geography, not to mention resistance from your manager about remote work. Many telecommuters feel left out of key decisions, passed over for promotions, and not integral to their team. You can overcome these obstacles and succeed as a remote worker. This book shows you how.

The One Minute Commute presents an easy-to-understand framework for demonstrating your value as a remote worker and part of a team. It gives you concrete advice for making you as integral to the team as your coworkers in the office. You’ll ensure your management and team members recognize your contributions and include you in important project decisions. You’ll get a comprehensive framework to help you transition your current job into a remote job or find a new remote job. You’ll be inspired by examples of people marketing themselves well and hear from top recruiters and social media experts about how you can find the remote job of your dreams.

You’ll also learn how to improve your usage of common communication technologies to build strong remote connections with your team. You’ll see step-by-step instructions for communicating effectively through conference calls, instant messages, and email. You’ll find out how to share knowledge with your team using wikis, blogs, newsgroups, and more. You’ll learn strategies for working effectively from your home office, and how to set up an efficient home office environment.

The One Minute Commute also gives you a chance to learn from remote presentation experts like Nancy Duarte and Garr Reynolds. You’ll see profiles of successful teams from companies like Mozilla and Sun Microsystems and learn secrets for making remote connections from facial expression expert Paul Ekman the inspiration for the television show Lie To Me.

Finally, this book shows you how to find and fix problems when working remotely isn’t working. It teaches you how to spot the first signs of trouble and offers solutions to the most common problems associated with working virtually.

I received a crazy amount of help and support while writing this book. Over 60 experts in various fields donated their time for interviews. Friends and family helped me review and edit and refine The One Minute Commute book. There were photographers, graphic designers, and lawyers. And they all deserve thanks.

37signals: Jason Fried and David Heinmeier Hansson

Code Sourcery: Ricardo Anguiano, Mark Mitchell, Catherine Moore, Stephan Seefeld, and Nathan Sidwell

Microsoft: Ade Miller and Scott Hanselman

Mozilla: Alexandra Cuccias, Jono Dicarlo, Blair McBride, Daniel Einspanjer, Jason Orendorff, Abimanyu Raja, Aza Raskin, John Resig, Ben Smedberg, and Atul Varma

Viewpoints Research Institute: Bert Freudenberg, Luke Gorrie, Dan Ingalls, Alan Kay, and Kim Rose

Subversion: Jim Blandy, Brian Fitzpatrick, Karl Fogel, Bert Huijben, Michael Pilato, Ben Collins Sussman

Sun Microsystems: Martin Balin, Janet Keeley, Martin Matula, and Heidi Pate

WikiMedia: Rob Church, Tim Starling, and Brion Vibber

Fatima Aydin, Jurgen Appelo, Sierra Black,Online casino v ČR Prague Shelly Boose, Chris Brogan, Anita Bruzzese, Julia Cort, Esther Derby, Nancy Duarte, James Duncan Davidson , Paul Ekman, Justin Evans, Eric Fillion, Jesse Glick, Aaron Goodisman, Ted Grossbart, Helen Herold, Maggie Hessel, Mark Horstman, Jim Idleson, MaryFran Johnson, Steve Kasmouski, Karin Lundberg, Michael Meeks, Robin Murphy, Robb Perry, Joe Pusateri, Garr Reynolds, Alex Rosen, Johanna Rothman, Shimon Rura, Shev Rush, Rajesh Setty, David Shopper, Kerr Timbers, Rosely Traube, Shannon Vargo, Chuck Wilsker, Sarah Whedon, Sue Veitch, Mary Vogt

And a special thanks to my editors and reviwers Howard Melman, Susannah Pfalzer, Jonathan Simon, Daniel, Steinberg, Lyndon Washington, Ian Welsh, and Mary Vogt

Thanks to everyone else who helped with this book and isn’t mentioned on this page.

This book was made possible by the many people who contributed with interviews and quotes. A simple acknowledgement didn’t seem like enough so I wanted to give each person a little space of their own. Thank you very much to everyone for all of your help and support.

Ricardo Anguiano

Ricardo Anguiano joined CodeSourcery in 2001 and is the Director of Information Technology. He holds degrees in Computer Science from the University of California at Davis. In addition to creating software for his team he is also responsible for systems administration.

Jim Blandy

Jim Blandy is a founding member of the Subversion project and the creator of the initial design of the Subversion repository. He has also worked for CodeSourcery and Red Hat focusing on the GNU compiler and debugger. Jim currently works on Mozilla’s ActionMonkey project where he is integrating a new JavaScript engine to help FireFox run faster.

Jim was one of the first people I interviewed for this book and he has more connections to the teams in this book than anyone else. Jim helped introduce me to CodeSourcery, Mozilla, and the rest of the Subversion team. He was also the first person to introduce me to the idea of the social currency of open source.

Jim was a strong influence on the Open Teams. He lives with his wife, children, and dogs in Portland, Oregon. Find out more about Jim on his website: http://www.red-bean.com/~jimb.

Chris Brogan

Chris Brogan is a ten-year veteran of using social media and technology to build digital relationships for businesses, organizations, and individuals. Chris speaks, blogs, writes articles, and makes media of all kinds at http://www.chrisbrogan.com, a blog in the top 20 of the Advertising Age Power150, and in the top 100 on Technorati. Chris’s contributions strongly influenced the Market Yourself Into a Remote Job chapter.

Ben Collins-Sussman

Ben Collins-Sussman is a founding member of the Subversion project and is currently a technical lead for Google’s Open Source Project Hosting. He is a programmer and a musician. He lives with his family in Chicago.

Find out more about Ben at his website: http://www.red-bean.com/sussman

Julia Cort

Julia Cort runs Julia Cort Recruiting, a firm that specializes in hiring remote compiler and tools developers. Find out more about Julia at http://www.juliacortrecruiting.com

Jono DiCarlo

Jono DiCarlo is the co-founder of a small Chicago company called Humanized and currently a member of the Mozilla Labs team where he is focusing on the Ubiquity and Weave projects. Jono graduated college at 17 with a degree in physics. He then earned an MS in Computer Science from the University of Chicago in 2005. He blogs about his current work and the need for better user interfaces in open source projects at http://jonoscript.wordpress.com.

Nancy Duarte

Nancy Duarte is the CEO of Duarte Design and author of Slide:ology: The Art And Science Of Creating Great Presentations She has worked with some of the greatest brands and thought leaders in the world such as Adobe, Apple, Al Gore, Cisco, Google, Hewlett Packard, Symantec and TiVO. Her firm is the largest design firm and a top woman-owned firm in the Silicon Valley.

You can learn more about Nancy’s company at http://www.duarte.com and read her blog at http://www.slideology.com.

Paul Ekman

Paul Ekman is a psychologist and pioneer of the study of emotions and their relation to facial expression. He has been named one of the 100 most eminent psychologists of the 20th century by the Review of General Psychology. Dr. Ekman is the author of 10 popular and academic books. His latest book, Emotional Awareness, was cowritten with the Dalai Lama.

Dr. Ekman is the director of the Paul Ekman Group, LLC (PEG), a small company that produces training devices relevant to emotional skills, and is initiating new research relevant to national security and law enforcement. http://www.paulekman.com

Dr. Ekman has appeared on 48 Hours, Dateline, Good Morning America, 20/20, Larry King, Oprah, Johnny Carson and many other TV programs. He has also been featured on various public television programs such as News Hour with Jim Lehrer, and Bill Moyers’ The Truth About Lying.

Daniel Einspanjer

Daniel Einspanjer is a metrics software engineer for Mozilla. He works remotely from Salem, NH. He blogs at http://blog.mozilla.com/data.

Brian Fitzpatrick

Brian Fitzpatrick has been an active open source contributor for over ten years. After years of writing small open source programs and bugfixes, he became a core Subversion developer in 2000, and then the lead developer of the cvs2svn utility. He was nominated as a member of the Apache Software Foundation in 2002 and spent two years as the ASF’s VP of Public Relations. Brian has written numerous articles and given many presentations on a wide variety of subjects from version control to software development, including co-writing Version Control with Subversion and contributing chapters to Unix in a Nutshell and Linux in a Nutshell.

Find out more about Brian at his website: http://www.red-bean.com/fitz.

Karl Fogel

Karl Fogel is a founding member of the Subversion project and the author of Producing Open Source Software: How to Run a Successful Free Software Project. He is an expert in the social dynamics of open source projects and distributed teams. My interview with Karl greatly influenced the general philosophy of this book. Read more about Karl at his website: http://www.red-bean.com/kfogel

Bert Freudenberg

Bert Freudenberg is a freelance software engineer works for the Viewpoints Research Institute and ports Etoys to the One Laptop Per Child platform. He completed his Ph.D. thesis Real-Time Stroke-based Halftoning in 2004. He has won awards for his work on SIGGRAPH and Plopp. Bert lives in Magdeburg, Germany with his wife and four children.

Jason Fried

37signals doesn’t have titles, but Jason Fried describes himself as “President, I guess.” He is a founder of 37signals and a managing partner. Jason is also a contributor to the popular Signal vs. Noise blog http://www.37signals.com/svn.

Scott Hanselman

Scott is a Principal Program Manager at Microsoft, public speaker, and author of the popular blog Computer Zen. He manages a team of people working remotely around the United States and blogs often about working remotely.

David Heinmeier Hansson

David Heinmeier Hansson is a managing partner at 37signals, the creator of the Ruby on Rails framework, and a contributor to the popular Signal vs. Noise blog http://www.37signals.com/svn.

For his work on Rails, David won Best Hacker of the Year 2005 at OSCON from Google and O’Reilly. And in 2006, he accepted the Jolt award for product excellence for Rails 1.0. He has been featured on the cover of LinuxJournal and in the pages of Wired, Business 2.0, and Chicago Tribune as well as other publications.

Mark Horstman

Mark Horstman is co-founder of Manager Tools, a management consulting firm. Manager Tools has served firms such as Intel, Applied Materials, Cornell University, USAA, P&G, GE, the Federal government, and Microsoft. Manager Tools was recently the number one business podcast on Itunes in the world, has twice been named Best Business Podcast in the US, and was People’s Choice Podcast of the Year (#1 in all categories) in 2008. Its podcasts are downloaded over 80,000 times each week.

Dan Ingalls

Formerly a Distinguished Engineer at Sun Microsystems Laboratories, Dan Ingalls is interested in dynamic languages, graphics and kernel software. He is Principal Investigator of the Lively Kernel project, a project to rethink web programming and the web itself.

Dan Ingalls is the principal architect of five generations of Smalltalk environments. He designed the byte-coded virtual machine that made Smalltalk practical in 1976. More recently, he conceived a Smalltalk written in itself and made portable and efficient by a Smalltalk-to-C translator, now known as the Squeak open-source Smalltalk.

Dan Ingalls did his first well known research at Xerox PARC where he began a lifelong association with Alan Kay. He has been a member of the Viewpoints Research Institute team off and on since the creation of the company.

Alan Kay

Alan Kay, President of Viewpoints Research Institute, Inc., is one of the earliest pioneers of object-oriented programming, personal computing, and graphical user interfaces. His contributions have been recognized with the Charles Stark Draper Prize of the National Academy of Engineering “for the vision, conception, and development of the first practical networked personal computers”, the Alan. M. Turing Award from the Association of Computing Machinery “for pioneering many of the ideas at the root of contemporary object-oriented programming languages, leading the team that developed Smalltalk”, and “for fundamental contributions to personal computing”, and the Kyoto Prize from the Inamori Foundation “for creation of the concept of modern personal computing and contribution to its realization.”

He has been a Xerox Fellow, Chief Scientist of Atari, Apple Fellow, Disney Fellow, and HP Senior Fellow. He is currently an Adjunct Professor of Computer Science at UCLA. In 2001 he founded Viewpoints Research Institute, a non-profit organization dedicated to children and learning.

Mark Mitchell

Mark Mitchell is the founder and Chief Sourcerer of CodeSourcery, Inc. He has worked on C/C++ software development tools since 1994. Mr. Mitchell has been the Free Software Foundation’s GNU Compiler Collection (GCC) Release Manager and a member of the GCC Steering Committee since 2001. He holds degrees in computer science from Harvard and Stanford.

Mark, along with Alex Samuel and Jeffrey Oldham, is the author Advanced Linux Programming.

Catherine Moore

Catherine Moore is a Sourcerer in CodeSourcery’s GNU Toolchains Group. She has been working on open-source software, including Binutils and GCC, for 14 years. She holds a BS from Boston College.

Jason Orendorff

Jason Orendorff got his job working on the JavaScript engine of the Firefox web browser by writing some really bad code. He blogs about Mozilla hacking and the FireFox SpiderMonkey JavaScript engine at http://blog.mozilla.com/jorendorff.

C. Michael Pilato

C. Michael Pilato is a core Subversion developer, co-author of Version Control With Subversion, and the primary maintainer of ViewVC. He works remotely from his home state of North Carolina as a senior software engineer on CollabNet’s version control team, and has been an active open source developer for over seven years. Mike is a proud husband and father who loves traveling and spending quality time with his family. He also enjoys composing and performing music, and harbors not-so-secret fantasies of rock stardom. Until that all works out, though, he is content to spend his modicum of private time doing freelance web design, graphic design, audio and video production work. Mike has a degree in computer science and mathematics from the University of North Carolina at Charlotte. Read his blog at http://www.cmichaelpilato.com

Aza Raskin

Aza gave his first talk on user interface at age 10 at the local San Francisco chapter of SIGCHI and got hooked. At 17, he was talking and consulting internationally; at 19, he coauthored a physics textbook; at 21, he co-founded Humanized. Aza is currently the Head of User Experience at Mozilla Labs where he works on the Ubiquity project among others.

Aza enjoys playing the french horn and puttering in his lab when time permits. Read his blog at http://www.azarask.in.

John Resig

John Resig is a JavaScript Evangelist for the Mozilla Corporation and the author of the book Pro JavaScript Techniques. He’s also the creator and lead developer of the jQuery JavaScript library.

Currently, John is located in Boston, MA. His blog at http://www.ejohn.org is an effective example of personal branding.

Garr Reynolds

Garr Reynolds is the author of Presentation Zen and the very popular blog http://www.presentationzen.com. He is a sought-after speaker and an expert on presentation techniques and self-branding. His personal website http://www.garrreynolds.com is an effective personal branding tool. His latest book is Presentation Zen Design.

Kim Rose

Kim Rose is the co-founder and Executive Director of Viewpoints Research Institute. In addition to overseeing all administrative and financial aspects of the non-profit organization, Kim is a media developer, media critic and cognitive scientist. She has been affiliated with Alan Kay and his research team since 1986 when she joined the “Vivarium Project” at Apple Computer.

Her publications include: “Squeak – Open Personal Computing and Multimedia” with Mark Guzdial, Prentice-Hall/Pearson, 2001, and “Powerful Ideas in the Classroom Using Squeak to Enhance Math and Science Learning” with B.J. Allen-Conn, Viewpoints Research Institute, Inc., 2003. “Powerful Ideas” has been translated into 5 languages.

Alex Rosen

Alex Rosen has been a software engineer for 14 years and has a BS, Computer Science and Engineering from MIT. He currently works at Endeca, a privately held company focused on enterprise information access software. He once got a job by warping Bill Gates.

Stefan Seefeld

Stefan Seefeld is a Sourcerer in CodeSourcery’s High Performance Computing Group. He has contributed to a variety of open-source software projects over the past 12 years, including serving as a lead developer and maintainer for Fresco and Synopsis. He received his MS in Physics from Humboldt University in Berlin and has pursued graduate studies in Biophysics at Universite de Montreal.

Nathan Sidwell

Nathan Sidwell is the Director of the GNU Toolchains Group at CodeSourcery where he has worked since 2002. He has more than 10 years of experience on open-source projects, including GCC, GDB, and Binutils, and currently serves as a GCC C++ maintainer and VxWorks target maintainer for the FSF. He received his BSc and Ph.D. in Physics from the University of Bristol.

Benjamin Smedberg

Benjamin Smedberg works for the Mozilla Corporation as the coordinator and lead developer of the Mozilla XULRunner project since early 2005. He is the module owner of Mozilla’s toolkit, embedding, and build system modules. Before switching careers, Benjamin was a professional choir director and organist who worked on Mozilla as a volunteer. http://benjamin.smedbergs.us/blog

Atul Varma

Atul Varma is the co-founder of a small Chicago software company called Humanized. He currently resides in San Francisco and works for Mozilla Labs on the Ubiquity project as well as others.

Atul graduated from Kenyon College with a BA in mathematics in 2001, and received his MS in Computer Science from the University of Chicago in 2004. Atul’s career experiences are rather varied; in addition to a combined nine years worth of experience as a professional web developer, video game programmer, and usability consultant serving such high-profile clients as IBM Global Services and Samsung, Atul has also taught and tutored at public schools and literacy programs and worked for a variety of nonprofit organizations.

Atul blogs about Ubiquity, user experience design, and other topics on his blog http://www.toolness.com.

Chuck Wilsker

Chuck Wilsker is the President, CEO, and Co-founder of The Telework Coalition. TelCoa, is the nation’s leading nonprofit telework education and advocacy organization addressing all forms of telework and telecommuting including virtual, mobile, and distributed work. The economic, environmental, and energy benefits as well as business continuity and the needs of rural, older and disabled workers are focus areas. Chuck is frequently quoted in the National media as an expert in his field.

A way of gauging how much transmission of presence you are doing is by the kind of argument, and depth of the argument, that a communications system can handle.
– Alan Kay

When I started writing this book I made a list of all the communication technologies that someone might use in their office. It started with telephones and ended with carrier pigeons. A lot of technologies on the list didn’t exist 10 years ago. 10 years from now there will be even more.

When new communication options become available, how do you determine if you should use them? Will they help you communicate or will they just get in the way?

The Dinner Table Criteria

The ultimate measure of a communication technology is dinner conversation with three or four friends. Everyone sits around the table in a quiet corner of someone’s home. Wine is poured. Delicious smells waft from the kitchen. You relax in your chair, among friends, and just talk.

You could talk about anything around that table. The conversation could shift from a fine meal you had recently, to politics, to family, to relationships, to sex, to friends you’ve known in the past, to people you know today, to your hopes and dreams. With some good food and a little bit of time the discussion could go anywhere.

This is the power of a effective communication system. The bandwidth is enormous, but manageable. You can read the people at the table. You can tell how someone feels just by looking at them. You have the information you need to engage in complex communication.

We can use the dinner table to create three simple criteria with which to judge other communication systems.

Depth. There is no limit to the type of conversation you can have over a dinner table. Try discussing art on an IRC channel or aesthetics in an email and you will quickly see the limits of some communication technologies.

Ease of use. A dinner conversation is easy to use. There are no complex setup screens, configuration, or user interfaces to learn. Anyone can sit down and join in.

Bandwidth. The bandwidth of a dinner conversation is enormous. Not only can you hear everyone’s voice with perfect accuracy, but you can see them with perfect clarity. Is someone tired? Are they well dressed? Do they look excited or bored? You can see them well enough to know the answer.

The Perfect Remote Communication System

Much of the way computer interfaces look today is the result of work by Dan Ingalls, Alan Kay, and others at Xerox PARC. I spoke with Dan and Alan about the perfect technology for remote communication and they both agreed: a wormhole, with a curtain over it for privacy.

Picture it. You are sitting at your computer and just to the side of your monitor there is a curtain that hangs in mid air. You open it and reach into another office to tap your teammate on the shoulder. They might be in the next room or across the world. They turn around and look you in the eye, face-to-face; rendered perfectly.

If we judge the wormhole with the dinner table criteria it scores extremely well. Is it deep? Yes! You could have any type of conversation there. Is it easy to use? Absolutely! There is nothing to setup or configure and everyone can understand a curtain. Does it have high bandwidth? Definitely! You can see the person in front of you as if you were in the same room.

Creating wormholes for personal communication will be beyond our abilities for a long time, but it is a useful way to think about remote communication. When you are presented with a new communication system you can use the same dinner table criteria —deep, easy, and high bandwidth— to judge it.

Apply the dinner table criteria to a video conference using Apple’s iChat. You sit in front of your computer and see a two or three inch moving picture of the person on the other side. Is it deep? Absolutely not. The blocky facial representations and out of synch voices do not support complex conversations. Is it easy to use? Not at all. You need to understand complex setup instructions, firewall issues, and IP addresses. Does it have high bandwidth? No. You can’t really tell if someone has shaved that morning, forget about seeing facial expressions.

Video conferencing scores low on all of the criteria. This explains why it isn’t popular for important communication.

Some technologies do well by scoring high on two out of three of the criteria. Instant messenger is easy to use: just click someone’s name and start typing. It is also reasonably high bandwidth, assuming you can type fast. It isn’t very deep, but that doesn’t matter as much for more trivial conversations. IM isn’t very good for a deep conversation with a close friend, but it is fine for quickly catching up.

Not all high scoring technologies need to be visual. The telephone scores highly on all three criteria. You can have a deep conversation over the telephone. It responds quickly and does a good job of letting you communicate in real-time. Telephones are easy to use: just dial the right number. Telephones also have enormous bandwidth. You can’t see what someone looks like, but a good quality phone provides high enough fidelity to pick out additional emotional information. You can tell if someone is happy, sad, or angry by listening to them talk on the phone. This explains why the telephone has been such an enduring communication tool.

The dinner table criteria also explains why bad cell phone connections are so frustrating. When your cell phone isn’t working properly it has almost no depth because you have to repeat everything you say. If you have ever pressed your head against a glass window or stood outside to get better reception, you know that cell phones can be difficult to use. And the tinny voice quality of a bad cell phone connection makes the bandwidth low. All of your effort is spent just trying to understand what the other person is saying. You don’t get any extra information.

When you consider a new communication technology think about how well it does compared to the dinner table. Many companies could have saved the money they spent in expensive video conferencing installations by looking at the depth, ease of use, and bandwidth of the technology.

Communication is king.

If nobody knows what you did you might as well have not done it. The software you create is only useful when other people use it. Talk about what you are doing and why. Write about it too.

Everything is communication.

Communication doesn’t just happen over the phone or in email. It is part of everything you do. Everything you share with your team is communication. Take advantage of every opportunity to share your ideas. Don’t limit yourself to weekly status reports.

Present your own ideas.

Don’t let being remote prevent you from presenting your ideas. Never let someone in the office give your presentation just because of their location. Talk directly with your team, your managers, and your customers. Show them what you are doing and tell them why it is worthwhile. Be proud of your work and your ideas.

Emotional connections matter.

A team without trust will fail. Build that trust with emotional connections. Get to know the people you are working with. Know about their lives and their interests. Tell them about you. Create a bond with them. Let your coworkers know you as a real person instead of just a screen name.

Software is about people, not code.

Being a professional programmer is not all about programming. The way you solve a problem is not as important as choosing the right problem to solve. It doesn’t matter if you succeed only to see your team fail. Work cooperatively with your team. Ask questions. Learn from your team and teach them. Create an open environment where you can find the right problems before you find the right solutions.

Fix problems early.

Problems come up in any team. Fix them early. Help the small problems stay small by staying on top of them. Look out for signs of trouble in your team and talk about them. Most little problems come from poor communication. Solve them by connecting with your team before they become big problems.

Find balance.

Finding balance in your life makes you better at your job. Don’t let working from home mean you never stop working. Time away from work will help you stay focused and relaxed with your work.

Market yourself.

Market yourself before it is time to find a new job. Make connections and build your personal network. Work on projects other people can see. Give potential employers much more than your resume.

Use the lessons from this book. They’ll make you a better programmer and a better team member.

At the end of 2007 I was laid off. I fell victim to the dotted line problem. For the previous six months I had been assigned to one manager but working for another. This is always a precarious position when downsizing happens. Your old manager is still paying you but your new manager is getting all the benefits of your work.

The company gave me 60 days notice to finish my project; I was getting ready to release a new subsystem and they wanted me to finish it. I tried to focus on my work, but I was also thinking about ways to stay with the company. Could I get them to increase the budget somewhere? Was it possible to move to a different group? Could I just make them change their minds?

It was tough because the downsizing was across the entire division and nobody had the resources to hire new people. As my last 60 days turned into my last 30 I became convinced I would have to leave. I worked on my resume, started a new professional blog (which I should have had already), and began looking at my professional network to see who could help me find my next job.

I didn’t realize it, but during this time my dotted line teammates were fighting for me. They were talking to anyone and everyone they could think of; up to the highest levels of the company. They spent time, effort, and political capital trying to find a place for me to stay in the company.

With just two days to spare they succeeded. They convinced the company to make the dotted line solid and I joined their team. I was the only person from that round of layoffs to stay in the company. Those guys fought to make a place for me. They saved my job. And they had never met me.

My new team was located in a different part of the country and I had never met any of them face-to-face. We had established a bond while working together remotely. They knew I would be good for the team because of my interactions with them and not just the code I wrote.

I hadn’t been an official part of their team before that, but I reached out to them. I joined all of their team meetings and I called them one-on-one to share ideas make connections. I made sure they could see my work and did everything I could to make it easy for them to give me an A. It saved my job.

Working from home is a balancing act. You will be pulled in many directions. You need to stay in contact with your team, but you want to get your work done. You need to stay focused on work, but you have to find time to take a break. You want to spend more time with your family, but you need to shut them out in order to be productive.

This balancing act can be maddening at times and there is no one right answer. What works for you today may not work for you tomorrow. Make it a constant part of your life to reevaluate your working situation. Do you need to change your hours? Are you getting your work done and still spending time away from work?

After that, just relax and do your best. Working from home gives you a lot of flexibility and you will find a solution that works for you.

Summary

Keep your promises to your coworkers to get your work done and yourself to spend time away from work.

Make a schedule that works for you.

Getting away from work will help you stay focused. Plan some distractions and don’t forget to move.

Staying focused takes good communication. Let people know when you don’t want to be disturbed.

Don’t get isolated. Stay connected with your team about work, and stay connected outside of your team with activities where you can meet people face-to-face.

Give your home office some thought. A good space to work will help you stay productive.

Stay professional, even though you may be working in your pajamas.

Plan your work with your family. Make it clear when you will be working and how you will maintain separation.

At home, there is nobody to watch you work. This is one of the best parts about working remotely. The flexible working hours allow you to take breaks. They also let you distract yourself with other tasks that, while they may be important, prevent you from getting your work done.

The key to being productive when you work from home is separation. Set aside specific time to work and not work. Separate yourself physically by having a separate office space and closing the door. Separate yourself emotionally by setting specific times to work and using that time to get your work done.

Get Your Family On Board With Working At Home

If you live with your family, then you can’t work from home successfully without their support. Have a discussion with your family about exactly what you need and how you are all going to make it work. Ideally you would have this conversation before you start working remotely, but it can happen any time you are having trouble.

Working At Home With Small Children

If you have children who are too young for school then working from home can cause some very conflicting emotions. You probably started working from home because you wanted to spend more time with you family. Nobody wants to miss their kids growing up. However, you have to separate from your family enough to get your work done.

Physical separation Small children do not understand boundaries, schedules, or delayed gratification. The only way to coexist with a small child and get any work done is to physically separate yourself. Close the door. The door prevents your child from entering. It also prevents your child from seeing you. For most kids, once they see you it is all over.

Support You can’t care for your children and dependably get your work done at the same time. Get some support to help you with childcare. You will also want to make time to see your children. The steady stream of work can cause you to work longer hours than you expected. This results in no time with your children and frayed nerves for the primary caregiver.

Working from home as a single parent

Working from home and providing full-time childcare is just as impossible as working in the office and providing full-time childcare. If you are a single parent trying to work from home you need some support. Relatives, friends, or professionals; someone has to be helping you. Trying to watch a toddler while attending a meeting is untenable.

Working At Home With Older Children

When your children are a little older you can take advantage of their time in school to get your work done. Get your kids ready for school, work while they are in school, and then take a break when school ends. You can always finish up the work you have left over while they do their homework. As long as you have help this can be a fine arrangement.

Robin M. is an IT project manager at a Fortune 500 company. She has worked for the company for five years and has worked remotely for almost the entire time. She has a young daughter and is expecting a son. Robin says:

“The company I’m with really supports IT personnel working virtually. I have been working from home 1-2 days a week since I started there, but when I became pregnant with my daughter I went virtual full-time. Being able to work from home was a real blessing when I was pregnant and nursing. After I weaned my daughter, I was promoted and began working from the office most days of the week; however when I became pregnant with my son, I decided to work from home again. Now I’m expecting my son in a few months and plan to work from home until he is weaned. After that, I’ll reevaluate the situation. Having the option of working from home makes pregnancy and breastfeeding much easier in many ways – and allows me to have the ability to continue to focus on my work. I’m grateful to have the option.”

Robin says the most difficult part of working from home with her young daughter was getting the proper support from her spouse.

“Really, training her father is a harder thing – getting him to think about keeping her noise level down outside my office door and reminding her not to go in there has been the real key.”