Hacker News new | past | comments | ask | show | jobs | submit login

I've been working remotely more often than not over the last four years (a brief 1-year interlude when I was back in an office full-time broke up the streak). I definitely prefer it.

The advantages are too awesome! I get to spend more time with my daughter (I'm a first-time father and she is just turning a year old today). There is hardly anything in this world that makes me happier than spending time with her. If I had to commute to work every day I'd basically see her on weekends and miss out on her every-day life. My parents did that. It sucked for them I'm sure and it would suck for me too.

I am a software developer and so my work is primarily categorized as, "knowledge work." This is a very post-industrial job. Working more hours does not directly produce more "product." Working remotely allows me to take a walk and do some groceries while I mull over the dilemma that has been bothering me. Often I will come back refreshed and with a clear solution. Or I can read a book to my daughter while I think about it. My job requires thinking and generating good ideas (which is a process that requires idleness and spontaneous connections through hunches). A 9-to-5 policy of being in a seat and typing away is not very conducive to developing software (unless you're applying the Shakespeare Monkey Method).

The OP mentioned the disadvantage of spontaneous social engagement. That is a problem I can attest to. However it is one I am willing to give up. I'm not as young as I used to be and it's not terribly important for me to play ping-pong with my co-workers and talk shop over beers. We make up for it by talking shop online during office hours and there are tools such as Sqwiggle which make those spontaneous chats possible.

At first this problem seemed big. I went out less and suffered a lapse in my social graces as a result. However I learned that I was just doing it wrong. Now I find I socialize more than I used to because I'm out in my community working out of coffee shops with other people in the same situation as I am. I meet see local people and we do local things and I've learned to develop a village mentality.

The real challenge for companies engaging remote workers is letting the reigns off. The fear of idleness is a rapacious concept amongst managers and entrepreneurs. You can hear it manifest in expressions such as, "always be hustling," "fail fast, iterate," and the like. However if history and open source have taught us nothing else it is that the condition of the human spirit is towards accomplishment. The goal in finding good people to work with is finding people whose sense of accomplishment shares the same spirit as yours. Even in idleness we unconsciously reach towards that which inspires us.

Remote work is great. Being around people in person is great. We live in a world where this is possible and easy to manage. There's no reason to force people to adopt your standards of living and geographic preferences to work with you.

(We just may be limited to certain national boundaries for the most part due to taxes and the inconvenience of international banking, but hey... walk before you run)


The biggest challenge for remote workers is working with a centrally-located team. The styles of communication need to be more rigorously defined and a part of everyone's habits or else it tends to fall apart. The central team tends to isolate the remote worker because they're so used to just having a hallway chat and forget to share that with the rest of the team. To avoid this everyone needs to agree to share all information and to make it a habit to strike up email threads, create issues and log chats in IRC/Campfire/whatever. Important issues cannot be decided face-to-face over lunch and not documented somewhere. It just doesn't work that way when you have remote workers.

The tools to make communication between remote teams have been evolving at a rapid pace in the last few years. WebRTC, shared documents and better issue trackers... there's almost no excuse anymore not to adopt these habits even if you are a centrally-located team. And if you do adopt these habits there's nothing getting in your way from incorporating remote workers anyway.

>> Working more hours does not directly produce more "product."

Exactly! I've always wondered why people are pushing the American death march way of work - long hours in an office and no work/life balance. I really hope we'll be able to change that and make remote work and other unusual work schedules more common in Europe. There is nothing better than going out for a walk in the middle of the day if you are stuck on a problem or starting your work day at 12. Lack of pressure and stress == higher productivity and better health.

The biggest challenge for remote workers is working with a centrally-located team. The styles of communication need to be more rigorously defined and a part of everyone's habits or else it tends to fall apart.

An excellent way to address this problem is to have a co-founder, preferably a technical one, be remote.

Given that this person is important, they will notice if they are being left out and have the weight that their complaints are heard. If no important person is remote, then these things slip far more easily.

There are several minor reasons why I'd prefer to see a senior technical person be remote. The first is that quiet time without interruptions is more likely to benefit the technical person. The second is that a non-technical co-founder has more interactions where they are likely to have legitimate reasons to be in the office.

But if it works better for you to have a technical co-founder in the office, and a non-technical co-founder who is basically a roving salesman, then go for it.

As another remote worker who primarily chose remote work to spend more time with his own daughter, I just wanted to offer you a big kudos for making the same choice.

Also, spot on with the biggest problem, working with an otherwise centrally located team.

My biggest issue is that, and also the fact that while my office is technically in Mountain View, my home (and hence, primary work location) is in the Annapolis, MD area, a few hours removed from theirs. As a result, while much of my time is respectful of the time difference, every time I work with someone new, or less considerate, I invariably get calls when I'm just sitting down for dinner, or 10 minutes after I've arrived at a bar, etc.

I don't generally mind, but I always worry about the perception every time I'm actually unavailable and that if it happens enough, I'll be seen as problematic. I'm told I'm overthinking it, and despite the fact that I'm generally more productive than the dev team sharing an open office plan, a lot of that advantage is mitigated by having to wait on meetings, etc.

How do you personally measure "a good day's work?" Is it based on gut feelings or do you have specific hours that you work? Also, do you follow a strict schedule, or leave your day open for "sporadic" opportunities?

As to your first question I don't have a good answer. I cannot think of a way to quantify something that I can only intuit about. You can think of any metric by which to measure the progress of a programmer and you will find an endless debates about its usefulness. It's inherently a qualitative value in my experience.

In general though I am motivated by accomplishment. I feel good about doing a good job. It is its own reward. I feel that I've had a good day's work when I've contributed something worthwhile that has improved the code, the company or my team in some way, even if it's small.

I keep my work days structured around the traditional 9-5. At first it was out of habit but I've since embraced it as a discipline. The difference for me, I believe, is that without a long commute and being stuck in an office far from home there is very little cost associated with following "sporadic" opportunities. I don't leave time out for them because the benefits tend to out-weight the cost of being away from my desk. I can get up and take a walk down to my local café, chat with the barista about local events and pick up some flowers for my wife on the way home. This relieves stress, breaks up monotony and gives me time and space to connect the hunches together in my mind. I may come back from that outing with the solution to my problem or I may not; but at the very least I will be reinvigorated to take on the next set of tasks ahead of me and it cost the team almost nothing and gained quite a bit.

The way I see it my employer was looking for someone who was smart, experienced, creative and responsible. I do everything I can to cultivate that in myself. They're not paying me to trade hours for lines of code. They need someone with my experience, knowledge and intuition to help them solve problems and build a solid product.

If the solution to our problems as programmers could be solved by rote then I'd be out of work and in a different profession.

Thanks so much for your thoughts - this is extremely helpful as I'm trying to find balance with remote work.

Well if you ever want to chat don't hesitate to look me up.

This applies to traditional work too, doesn't it? Sure, a brick layer can measure based upon how many bricks but I don't think it makes sense for programmers to measure a "good day's work" in terms of just time spent coding ... I think it is more about progress. Even if you didn't write any code, did you make some conceptual breakthroughs that will lead to better coding tomorrow?

I understand what you are saying, however, I'm wondering how OP personally measures overall progress as a remote worker.

For me, it's not based on the work, it's based on the mood/mind. A "good day" is one where I was thinking clearly and solving problems and choosing good paths with ease.

The amount of code written doesn't mean as much.

In fact, the amount of code written can often be inversely proportional to the quality of your work in that day.

There simply is no meaningful correlation. It usually takes the talent of another skilled professional to measure the quality of your work, which is one of many reasons why management exists.

+1 on Swiggle. I had my team using that for a while until a reorg broke up the team. It's awesome to be able to see when someone is at their desk, click their picture, ask a quick question, and hang up. It really helps feel like you're more connected to the team while avoid the noise problems on being in the office.

I've also had some exposure to Sqwiggle. It works very well for quick interactions with other developers; the call quality is good, latency is low, etc. I just wish there was a "knocking" feature for someone starting a chat, and/or additional states between offline, busy, and normal. Introverts may not like the constant camera exposure, and developers "in the zone" may not like the sudden presence of a voice and watching eye without any sort of ringing or pre-chat announcement (in real life, interruptions are at least preceded by footsteps and visible reflections of the approaching person). If they could address those concerns, I could see myself using Sqwiggle extensively.

Hey nitrogen! Thanks for the thoughts. We actually do have all of these options. Just log into Sqwiggle and click your own video which will put you into "Busy Mode". From there, users will have to ping you to chat.

Thanks! -Matt (Co-founder)

Hey Matt, thanks for your reply. I guess busy mode's UI looks too much like I'm not being a "team player" to me, at least in the Chrome web UI. My ideal, and I recognize this may not align with your target market, would be snapping a single image to use as my avatar for the hour/day/week/month, with knocking before chatting, but no indication that I don't want to be disturbed. I do like the UI overall and think you've got a good thing going.

This highlights some of the reasons I feel so blessed to be interested in, and involved with, web development at this time in history. I really am glad that what I enjoy creates value for others (of course, it's never perfect though).

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact