4 ms·

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 co

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.

mstefanko 14y ago
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.
- jarek 14y ago
  Professional services and agency world, for all its faults, tends to be pretty good about specifications.
hosh 14y ago
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.
mbell 14y ago
> 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.
- LnxPrgr3 14y ago
  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 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.
  - mbell 14y ago
    > 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.
    - LnxPrgr3 14y ago
      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.

mstefanko 14y ago

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.

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

hosh 14y ago

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.

mbell 14y ago

> 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.

LnxPrgr3 14y ago
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 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.
- mbell 14y ago
  > 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.
  - LnxPrgr3 14y ago
    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.