Working from Home: A StackExchange Story

Why we believe in letting people work full-time from home

#1: It lets you hire good people who can’t move. Hiring remotely opens you up to an enormous pool of people who can’t move. I can’t stress this enough: for every one person who is in your location or is happy to move there, there are 100 more who are not. They’re tied down by a spouse with a job, a kid in school, a visa they can’t get, or a mortgage they can’t get out of. If you’re hiring for technical positions, hiring remotely is the best-kept, blindingly obvious secret for finding people. By hiring remotely, we have been able to fill our team with awesome people with lots of experience, who were stuck in happily living in places like Corvallis, Oregon or Forest of Dean, UK (Seriously, look it up. It’s basically The Shire.)

#1a: You don’t lose people to silly things like their significant other going to medical school. Before I worked at Stack Exchange, I worked at Fog Creek. I watched at least five great people leave because their family situation made it necessary to move, and Fog Creek had (at the time) a strict no-remote-workers policy.This drove me crazy. These were amazing employees, in whom the company had already invested deeply, who were now walking out the door because they couldn’t live in New York any more. At Stack Exchange, we’ve already had two people move away from New York, who are still happily employed doing the same job they were always doing. If we didn’t allow working remotely, we’d be down at least two great developers.

#2: When done right, it makes people extremely productive. Private office? Check. Flexible hours? Check. Short commute? Check. I’ll let you in on a secret: most of our remote developers work longer hours than our in-office devs. It’s not required, and probably won’t always be the case, but when going to work is as simple as walking upstairs (pants optional, but recommended) people just tend to put in more hours and work more productively.

#3: It makes you focus on more than butts in chairs. As a manager, I can’t easily know how many hours each person on my team is working. This is actually good for me because it forces me to look at what they’ve done. It’s good for the remote person as well: they can’t fool themselves into thinking that just because they’re in an office, surfing Reddit for an hour is work. In a perfect world we’d both already have this perspective, but it’s amazing how easy it is to delude yourself into thinking that “going to the office” = work.

What we’ve learned

#1: Remote working isn’t for everyone. There’s a tendency to think that working from home is all sunshine and rainbows and working in your PJs. It’s not. You miss out on being around people (which wears even on introverts), doing fun stuff like playing ping-pong or having lunch together, and (sometimes hardest of all) you lose a clear distinction between work and the rest of your life. Some people thrive when working from home, while others wither or just… drift. We’ve had people move both ways: remote people deciding to come in to the office, and people in the office deciding to go remote. The key, for us, is offering both and helping people decide which is best for them.

#2: Working remotely is a skill you need to hire for. If remote working isn’t for everyone, you better be sure that the person you’re hiring to work remotely is going to be good at it. The most important thing that we look for is that they must be self-motivating and proactive: self-motivating in finding things to do, proactive in communicating with the rest of the team. Our remote developers are some of the most argumentative people in the whole company, because we hired them to be that way. We like opinionated people. Opinionated people find things they care about to work on and make sure you know what they think, which is essential if you’re not sharing an office together.

#3: You have to commit to it as a team (and a company). There’s no halfsies in a distributed team. If even one person on the team is remote, every single person has to start communicating online. The locus of control and decision making must be outside of the office: no more dropping in to someone’s office to chat, no more rounding people up to make a decision. All of that has to be done online even if the remote person isn’t around. Otherwise you’ll slowly choke off the remote person from any real input on decisions.

#4: Communication is hard (but it was always hard). I am far from the first to point it out, but the hardest problem in growing a company from 4 to 75 people (and, presumably, to 200) is communication. When there were 4 people, everyone knew everything. When there are 75 people that no longer scales. So you have to work out your channels of communication, and that’s doubly true with remote workers because you can’t rely on overheard conversations or gossip to spread the word. You have to force yourself to be explicit in communication.

How we do it

#1: Google Hangouts. Google hangouts are the lifeblood of our organization. If you haven’t tried them for video chat, you’re living in the Stone Age. We have persistent hangouts for every team available at URLs that everyone knows. We spin up one-off hangouts for quick video chats. We use them for meetings, for hanging out (no, seriously), for demos, for teaching… for everything. There really is no substitute for face-to-face conversations, and when you get to the point where people in the office are actually preferring hangouts to talking in-person because it’s easier, you know you’re on to something.

#2: Persistent Chat. Chat is good for shorter conversations, or quick pings to ask someone a question. It has two big benefits: (1) it’s asynchronous enough that people can get back to you when they have a second, and (2) it’s persistent, so other people can skim it and catch up on what they missed (vital when you’re in different time zones). Every company should have a chat system, whether they have a distributed team or not. It’s better than interrupting someone at their desk or dragging someone into a hangout for a quick question. Webuilt our own chat system, but there are good alternatives like Campfire and HipChat out there.

#3: Email. As flawed as email is, it’s still alive and kicking. Email is for fully asynchronous communication (don’t use email if you need a response today), and for communicating status updates and decisions. We have a standing rule that all decisions must be typed up and shared with the rest of the team via email, basically what Jeff described at the beginning. Each team sends out a weekly status update to the whole company giving a high-level overview of what’s going on, so teams don’t get isolated from one another.

#4: Trello + Google Docs. We use Trello for keeping track of who is working on what, and Google Docs for notes, specs, designs, etc. Both are excellent tools that you should use even if you’re not working remotely.

 

Source: http://blog.stackoverflow.com/2013/02/why-we-still-believe-in-working-remotely/

 

Como Instalar, Configurar y Administrar WINE en Ubuntu

Guia completa y extensa de como instalar, configurar y administrar WINE en Ubuntu, incluyendo debugging de problemas comunes, soluciones a tipicas dudas y acceso a numerosas fuentes de informacion que incluyen tips y trucos para asegurar una mejor experiencia al usar WINE

Deben ver el video en 1080p ya que fue hecho con 1920×1080. Por otro lado el Audio (O sea mi voz) esta algo rara. Al menos yo me escucho como si estuviese en el background a 10 metros. En el video original se escucha mejor, lo malo es que el original son 900MB O.o

The IT Pyramid

Ever wondered how IT positions are related. How much time you need to learn the basics of a particular job position or what you actually need to know for that position. The IT Pyramid helps you find what you need to know to either be able to achieve a better position or go up the ladder to a better knowledgeable one. It shows an estimate of how much time you need to achieve a certain position or goal and on what this position is based on. The final goal of the IT Pyramid is to teach non-IT users how the actual IT world works, relates and is based on. The fuel that powers this hierarchy is the knowledge the IT user has on many particular subjects and how well they can be applied in real life by saving time, costs and optimizing resources.

Ubuntu for End Users

I have written this book about how to install, configure and use Ubuntu… for end users. Right now I am working on a revision for it that will include about 150 more pages that talk about Bash and other sections of Ubuntu. You can download the book from the following link below:

The current book includes: