Hacker News Reader

Comment by edw519 | Hacker News Reader

The single biggest problem with working remotely is that you have to be excellent at a lot of things that don't matter when you're on site. And since your energy is a zero sum game, being excellent at these things steals energy from building.

You need to expend time and energy on:

- preparing precise specs instead of explaining and interacting

- interpretting imprecise specs instead of questioning and interacting

- writing precise emails

- interpretting imprecise emails

- guessing body language and tonality from written communication

- dealing with conference calls and web-based meetings

- building relationships without benefit of breaks and meals

- understanding the human terrain without benefit of gossip and the water cooler

- being noticed and recognized for who you really are by new people

- being included when you're "out of sight, out of mind"

You kinda get the idea. If you can be excellent at these things, great. Otherwise, be prepared to see your work suffer.

View on HN

Having been 100% remote for the last 5 years, I feel I can comment here.

I'm a little puzzled by the first few items in your list... I work at a pretty big company, so maybe that is why. Specs are a way of life where I work. I would hope that everyone would be good or learn to become good at writing useful precise specs.

Accurate and concise emails goes without saying.

I would agree with the body language from written communication if you never spoke with anyone on the phone, but that would be pretty unusual I think.

Web-based meetings, virtual whiteboards, are fantastic. I'd much rather do web based than sit in a conference room.

I don't really have work relationships anymore, but it's not a loss. More of an exchange for relationships outside of work.

The water cooler comment I agree with. I don't have the "pulse" of the human terrain anymore. It bothered me when I was losing it, but I don't mind anymore.

I used to worry about the "being included" part, due to the out-of-sight, out-of-mind effect. I have to be more of an advocate for myself than perhaps I otherwise would. However, my work speaks for itself, and people want me on their projects. I keep in touch with various project leads and let them know what my availability looks like. I don't feel like I'm missing out.

All that said, I worked at my company for close to 10 years before going remote. That was a big help. I personally knew everyone I was working with for the first couple years. Turnover has changed that.

Working remotely requires discipline, perhaps more-so than working in an office. For many people, the commute to work and being in a different environment helps them shift state of mind into a "work" mode. That is harder to manufacture working remotely.

You need to be more available when you work remotely. When someone calls you in an office and you don't answer, they think "oh, maybe they were taking a break or in the restroom". When someone calls you and you work remotely and don't answer, you worry that they will think, "Is this guy really working?"

For the first couple years I worked remotely, I made sure to answer the phone whether I was on lunch or break or whatever. Now that my reputation as an effective remote worker have been established, I don't worry about it so much, but I do still think about it.

Great insight! Think you nailed everything head-on. The precise specs, I envy you on that though. I've unfortunately never worked somewhere where precise specs we're handed over. I've either had to build my own specs to the problem, or am given partially written specs and had to fill in the gaps. Which ends up in a lot of back and forth, so the point being made in the initial comment about the specs is accurate everywhere I've worked.

Professional services and agency world, for all its faults, tends to be pretty good about specifications.

I have worked 100% remote in the past six months, worked onsite for 2 years before that, and 100% remote doing contract work for 10+ years before that. Most of my adult working life has been in remote contract work.

Remote contract work doesn't quite count, but because of it, I have never been attached to working onsite.

Working remotely in a non-contract situation, though, does need some connection with the rest of the employees. It helps if the rest of the team is also remote. The whole team had to figure out how to work with each other.

> Specs are a way of life where I work. I would hope that everyone would be good or learn to become good at writing useful precise specs.

I was honestly hoping this was a joke, but I don't think it was. By the time someone writes an accurate spec, the business need has already changed. Spec's don't work.

By the time someone writes the software, the business need has already changed. Software doesn't work.

What?

Since when did specs become immutable? Needs have changed? Patch the spec. It's faster than patching the software.

From http://joelonsoftware.com/articles/fog0000000036.html:

"The most important function of a spec is to design the program. Even if you are working on code all by yourself, and you write a spec solely for your own benefit, the act of writing the spec -- describing how the program works in minute detail -- will force you to actually design the program."

Sure, you'll still find out the design was wrong in some areas, and you'll have to change it. But at least you'll have a design to start from, as opposed to a hodgepodge of features carelessly tossed into the interface wherever the programmers found it most convenient to stick them, implemented in whatever way made the most sense to the programmers at the time.

> Since when did specs become immutable? Needs have changed? Patch the spec. It's faster than patching the software.

I don't understand how this can be faster. You patch the spec, then patch the software to match. I can't see how the spec could be patched faster. That is unless you patch the spec in isolation, prior to writing any code, which is a bigger mess. I've never, ever seen any group that can write a spec in isolation prior to writing code to demonstrate it, and have it come out well, its usually a disaster.

Did you read the link I posted?

The idea is by having a spec, you're more likely to see where it needs to be patched upfront, before delivering poorly designed software to angry customers, so you spend less time re-working it later on.

> I've never, ever seen any group that can write a spec in isolation prior to writing code to demonstrate it, and have it come out well, its usually a disaster.

Can you elaborate? I'd be interested in hearing what they were building, who (in general terms) they were building it for, how they went about writing the specs, and what went wrong.

My experience has been completely different, and I'm curious as to why that is.

Edit: Of course you can't expect the customer to write the spec. Designing the software is your job. But that doesn't mean specs are broken; it just means asking your customers to write your specs for you is broken.

> My experience has been completely different, and I'm curious as to why that is.

The majority of people who request 'software' haven't a clue what they want, they can't possibly describe it, you can't possibly write a spec for it. See years of research regarding waterfall vs agile development as a reference.

Interestingly, the waterfall model, as described by its inventor was iterative.

See _Leprechauns of Software Development_

Seriously?

Business software isn't about "what they want", it's about coming up with a solution to meet a business need. If the customer can't define what their business need is (the why of specs), then they have no reason to be in business.

It's not the job of the spec writer to define the business need, it's to take an existing need (after clearly defining it through consultation with the customer) and then defining the parameters of the software - inputs, outputs, business rules.

And it has absolutely nothing to do with agile vs. waterfall development. A well-written spec is crucial to ANY business software project.

We do agile development at my company (a 25 year old enterprise software company) and will not begin work until we have a well-defined spec. I continually reject spec docs if they don't have enough info or if I have questions about an aspect of it. It's your job as a developer to help the spec writer see what problems may crop up and define a solution for them.

I think you need to read Code Complete. It's absolutely mind-blowing the respect for specs you get after reading that book, even just chapter 3.

Big design up front!

In my experience you never really understand a problem until you've implemented it. You can describe a problem and a solution in excruciating detail, but you'll never find every corner case. Sometimes (often?) those corner cases are really big deals.

Better to prototype and iterate. Software should be the spec.

> Better to prototype and iterate.

Agreed. Version 1.0 is a glorified prototype anyway. Nothing about writing a spec prevents you from prototyping and iterating, though. These are not competing ideas.

Of course you won't get everything right in the first draft of the spec. You won't get everything right in the first release of your software either. That's not an excuse to stop trying.

Let's suppose you write a spec, then go on to write some code. For each design problem that makes you break from your original plans, one of two things is true:

(1) Someone noticed a problem while writing or reviewing the spec, and changed the design. You've saved a ton of time over implementing the wrong thing and then changing it later.

(2) You didn't notice the problem until implementation. It still takes just as long to fix as it would have if you hadn't bothered writing a spec first.

If #1 is common enough, writing the spec saves you time. At worst, #1 never happens and you're out the time it took to write the spec. But how long does that take? In my experience, it takes a lot less time to write a spec than to actually implement it.

There's a lot of potential upside and little potential downside.

I don't advocate Epic Design Up Front—at some point, it's time to stop planning and start doing. But I do advocate Some Design Up Front, as opposed to Let's Wing It And Hope For The Best.

> Software should be the spec.

Software is not a spec. It's written in computerspeak so only the programmers can read it, and sometimes they're not even completely sure what's going on. Without a spec, QA has nothing to test against, so you get into arguments about how things should work because there's no record of any decision on the matter. There's nothing to write documentation against, so the documentation ends up worthless. Sales and marketing make up all sorts of neat features you get to implement whether they make sense or not because they've already been sold, and you can't really say they should've known better because you never bothered to write down what they should know in the first place.

If all you have is code, you don't have a spec. Code is not a spec.

I find it interesting that I've gotten downvoted for this comment. Building an MVP and then iterating seems to be the modus operandi of the HN community. Building a detailed spec is the anti-thesis of this movement. How does this correlate?

The world of software development is a lot bigger than HN.

I didn't down vote you, but my experience with writing specs has been positive.

Maybe you are talking about running your own start-up where it might not be successful yet? And you're trying to find your market fit? Then sure, maybe just writing new code and changing the product on a whim is what is best without writing up a spec.

Now consider a software consultancy with enterprise customers. The enterprise usually wants time and cost estimates, which usually means agreeing on precisely what you will be delivering in advance. You WANT to write a spec, to prevent scope creep and limit your liability, and they want you to tell them how long and how much (and a spec helps estimate those things). It's win-win.

Most enterprise customers can't wrap their CFO's head around true agile with iterations and open-ended times and costs. They want as much of a guarantee as you can give them for what/how long/how much.

Not saying one way is better or worse - but maybe it's a case of the right tool for the job?

Because the fact one model is working for the HN community doesn't mean that other models don't work but you made a very definite and sweeping statement.

We use specs because our customers tend to be somewhat staid and want certainty and predictability. By keeping chunks of functionality relatively compact (say 3 person months typically, then developed over a period of maybe 6 weeks) writing an accurate and useful spec is absolutely doable.

Doing that we'll usually be 95% (or more) right and any adjustments can be made in a small release a couple of weeks later.

The approach has elements of agile and iteration in it (small releases, the UAT and fix process is basically a short agile sprint) but specs are absolutely a working part of it. Could we do it another way if our clients would accept it? Sure? But do the specs work in the current process? Yes they do.

"Building an MVP and then iterating..."

If you get your feedback on iterations in writing, you will probably get fewer self-contradictory or illegal, immoral, unethical, or unimplementable demands.

Having spent 5 years working with a remote team of 30 developers (mostly west coast based, but almost never in the office), there is definitely a different side to the story.

The situation you are describing arises when you try to introduce telecommuting into an organization, without making it part of the culture. When it is an exception and not the norm. As with any exceptions, it has to be properly managed, and results in extra effort being required form both sides of the fence in order to make it work. However, making it the exception is the main reason telecommuting doesn't work out for organizations.

At the company where I worked, the norm was that all member of the development staff were telecommuting. Most other departments were on-site, with the exception of about 50% of sales. Pretty much everyone that came into the office did so by choice. I did about 50/50, as my job included a lot of meetings with executives.

The main aspects that made this successful, were the same as in the office - there was a very specific expectation of behavior: - When the day starts (at you preferred/agreed upon time), you send an email stating you are working to the dev distro list. - When you are working, you are expected to be on IM (statuses are meaningful, if you are set to "do not disturb", you are not disturbed, unless an emergency arises). - When you leave, take a long break, etc, you let the team know by email. - A daily "stand-up" call was held at specific time. - Everyone had a published contact list. Especially, leads, managers and PMs were expected to answer the calls from devs.

Essentially, when someone would IM you, it would be like dropping by someone's cube to talk. White-boarding sessions were done over gotomeetings or webex.

For people not used to this, it might sound like a chatty, annoying type of environment, but in reality, being aware of the need to communicate, it made for a much more hospitable place to work. When you needed to concentrate, you could shut everything out. When you needed to collaborate, people were an IM or phone call away.

I think a lot of it comes down to the corporate culture. I worked at one company remotely for eighteen months (at the end of which I was laid off). When I started my team had two people working remotely (and we were among the only remote workers at the company). Eventually the other remote guy quit, and then I got laid off (in large part because I was the only person remaining needing special handling, such as out-of-state health cover).

On the other hand, I worked for a company which employed large numbers of remote workers and it wasn't really an issue. One of our clients integrated two of our people into a team which was spread all across north america.

That said, I think if you don't capture the water cooler, lunches, etc., you're not getting the full value from the person. Having worked solo/remote for five years, I'm now working in a conventional office setup, going to lunch with colleagues, shooting shit with people at the coffee machine, and so forth -- and the value that these informal encounters have for the project and organization is simply phenomenal.

Serendipitous encounters with other smart, passionate people can be amazingly powerful -- I seem to recall an article citing examples such as "Building 20" at MIT where researchers constantly bumped into people working in random different fields, and Pixar's campus where all the bathrooms and snacks are in the central hub. I think that if you're working with the right people on the right project, you want to be together (until the technology for being together -- e.g. electronic "wormholes" -- when you're apart gets a whole lot better).

I found the article I was thinking of:

http://www.newyorker.com/reporting/2012/01/30/120130fa_fact_...

So you frequently experience imprecise emails that require a face to face meeting to clarify what was just written? That doesn't seem like an advantage for working in closer proximity. As far as interpreting imprecise emails, a phone call is possible whether you are in the office or not. And if you are having to do this frequently, I think there is a staffing problem.

Body language in technical specs and design documents should be irrelevant.

Conference calls...yes...they happen in either case. Not sure what there is to "deal with" differently when working remotely.

Being noticed by new people: I think you are suggesting something specific here that I can't relate to.

"Human terrain", gossip, water cooler chats....yes, clearly you are suggesting some kind of requirement for something that is not actually required to do work.

It seems you are suggesting a very heavy personal interaction with people as a general requirement but I think that in a number of positions this is not the case. If you are in an organization where shared personal time, water cooler chats, and face to face email followups are important, then obiviously remote work is not going to be effective. You've essentially built the perfect anti remote work scenario and suggested that it is going to be that way in every job so if you can't combat those things then forget it. What you have to do instead of trying to fight such a culture is to find a position where those things don't matter.

You can't relate to new people in the company? It is hard to read you here. You sound from this that you have a very specific idea of your job role where your adaption is to leave.

I can't relate to a requirement for being "noticed and recognized for who you really are by new people" as a reason to work in the office. I'd be surprised if most employees really know each other anyway. I'd be even more surprised if that was somehow important to job function for most jobs.

For most jobs maybe that's true, but many startups strive to be better than that and more than just job function and day-to-day.

Personally I find a business where people know each other fairly well and understand how each other operates is preferable over one where I am only considered for my "job function;" so I can relate. But perhaps I am just idealistic.

" many startups strive to be better than that" Better than what? Are you implying that an environment where forming close personal relationships with coworkers is a requirement is distincly "better"?

Perhaps in your case, as described in your last paragraph, you would find that to be better for you. But I don't think it is undeniably better in all cases, for all people.

Many startups are actually remote only and I don't think they would accept that they are somehow inferior for it.

So in other words, it's harder to play corporate politics when working remotely. That I would agree with. Whether or not that's a bad thing, I'm not sure.

And honestly, if you're not spending time on preparing precise specs or writing and interpreting clear and precise emails while working on location then you're doing something wrong. Most of the communication and project management still happens on computers whether or not there are remote workers involved.

If you're going to say, "in other words", it's an interesting exercise to wonder if the person you're paraphrasing would agree with you that you're accurately paraphrasing them. I'd say that's not remotely the case here... Though it certainly is harder to play corporate politics remotely.

Written communication is lower bandwidth than oral communication. And phone conversations are lower bandwidth than face-to-face. Relationships/friendships are part of work (for most people) and can help you be more effective on a team. And work ideas often get discussed during "non-work work time" (lunches/watercoolers) -- often leaving the remote team member out of the loop.

> Written communication is lower bandwidth than oral communication

This is not necessarily true, especially if you have fast typers on your team. And typing out conversations means you have a written record of everything that was said. Important points are no longer lost to the ether.

> And work ideas often get discussed during "non-work work time" (lunches/watercoolers) -- often leaving the remote team member out of the loop.

It's true, you do miss out on some of these types of conversations. But if your team makes heavy use of online communication tools, you often have conversations springing up during non-work hours. Also, missing out on 30 minutes of semi-casual discussion during lunch isn't that compelling of a downside for me, especially when weighing it against the upsides of increasing your potential labor pool.

Glib dismissal of large swaths of human interaction as "playing corporate politics" isn't the most airtight of analyses of the human experience.

Well crafted. =)

If your customer is not going to come visit your retail premises to experience your product, you'd better be good at all those things on the list.

This dynamic is changing. For several of these: "guessing body language and tonality from written communication", "dealing with conference calls and web-based meetings", "building relationships without benefit of breaks and meals", "understanding the human terrain without benefit of gossip and the water cooler", "being noticed and recognized for who you really are by new people"

And especially: "being included when you're "out of sight, out of mind""

A remote presence device can make a tremendous difference. We know this because we use them ourselves, with our own distributed team. We have people on three continents, in the same office, every day.

One challenge we have (full disclosure, my company makes such a device) is how to explain the benefits, and how it changes life and work, without a live demo. Our research shows that it takes about 30 minutes of use before people start to see the differences. I'd be curious to know what the folks at Double Robotics, Anybots, VGo, and some of the other new companies have found as well.

What would stop remove worker from explaining, questioning and interacting remotely? There is Skype, there are good screen sharing tools.

Being included when you're "out of sight, out of mind" -- that's cultural issue. When you are one click away in Skype - you are more reachable than on-site co-worker 2 cubicles down the hall.

I agree about the advantage of breaks/meals/water cooler/gym /walks around the office etc. That could be simulated online though.

I think online gaming communities are ahead in online socialization, so we can learn some tricks from them.

My team does attempt to simulate this online, at least w/ one of our remote folks.

We occasionally have "game break" on Fridays, where the team gets together for an hour to play a board game or video game (popular favorites have been The Resistance and Mario Kart). When one of our teammates moved to Texas (we're in NY), we started Skyping him in for games of The Resistance (it's sort of like Mafia, but with cards). Since it's a card game, we had to find some interesting workarounds - we use http://www.adoodle.org/ for anonymous votes in the game (instead of cards), and hold up his role card to the screen w/out looking at it so he knows if he's a spy or not.

It's been a lot of fun, and a great way to stay connected w/ teammates outside the office. At some point, I'd like to write a Skype bot that handles all the vote-counting and card dealing, but our little hacky version of the game has worked pretty well so far.

I personally find the opposite to be true with a lot of these "precise" points. Written communication is, at worst, as hard as spoken when it comes to technical matters. Done well, it's better. There are so many times I've tried to explain an idea verbally only to give up and take thirty seconds to outline the shell of it in pseudocode or whatever and suddenly everybody understands.

A lot of this stuff depends on individual personality. Some people do better on site, and the stuff you write applies. But some people do better off-site, and all of those advantages you cite can turn into disadvantages. I would be extremely wary of painting remote work as something that's always a disadvantage, albeit one that can sometimes be dealt with, no matter who's doing it.

When I worked for BigCo, the vast majority of my comunication with customers was in writing. The vast majority of my training for interacting with customers was geared towards face to face interactions. I never once had a face to face meeting with a customer. I felt strongly that more internal communication in writing (like email) would have improved the company's ability to interact with the customer -- you know, the folks paying our bills.

Given how much you post on HN, it strikes me as somewhat hypocritical to talk about email as an inferior communication method. The internet and writing are increasingly critical to business success, even for local mom and pop shops. I am well aware that people routinely talk like there is something inherently superior about "IRL" interactions. It frequently makes me want to ask "So, then, why are you here?" Because, inevitably, it is someone getting enormous value from their virtual life who is dismissing remote/virtual something-or-other as "not real" or otherwise somehow inferior. Naturally, they do it a lot on the Internet, just to add to the irony.

Reply on news.ycombinator.com