Hacker News Reader

Comment by joshuamorton | Hacker News Reader

You're talking about two different things. I work almost entirely non-remote. If all I did was write code, I could do so remote. I collaborate with people in 3 continents, probably 10 timezones, maybe more, many of whom I've never met in person, when it comes to code.

But design is a different beast. Collaborative design of complex systems has a few stages. There's a rapid prototyping stage where 3 people in a room bouncing ideas off of each other and scribbling is better than anything else I've done. Then you circle back with a document that formalizes things (like an RFC). The second part can be done with a distributed group. But the first part is better when people are close to each other. You see this even in distributed groups like OSS projects. They have conferences and work sprints where the maintainers can be colocated for a bit and brainstorm about things in person.

View on HN

Sure, but you are not actually contradicting me as far as I can see.

I too collaborate with colleagues in different time zones but design and tons of brain-storming is not the main focus of our work. When we need to do that, we do long video calls with shared diagrams -- or we just scribble with the mouse. Works quite alright 99% of the time.

I agree that the rapid initial stages of a project are best done in person but failing that, there are replacements, and they are not as bad as many in this mega-thread claim.

My point is that that rapid prototyping stage is really important, has long lasting consequences, and so optimizing for it is a reasonable decision.

And that's just one reason to disfavor a remote-only environment.

Rapid prototyping happens only once per project and is likely less than 1% of the time spent so to me it does not make sense to optimise for it.

What other reasons do you see to disfavor a remote-only environment?

That 1% (and is often more like 5 or 10) can have big implications, but you can just have an on-site, it's a lot cheaper than having an office year round. Plus you can do it somewhere fun and it's a great perk and team building exercise.

Rapid prototyping should happen every time you need to add or change an abstraction. With the way many (most?) software projects work, with new feature requests and requirements appearing along the way, this happens all the time. With new requirements, the old abstraction often doesn't fit 100% anymore. Applying a few band-aids to the abstraction is probably fine, but at some point you will need to reconsider the design, or you will end up with a design that does not match the problem it's solving, making the code difficult to follow and therefore error prone.

In my experience, this need arises very frequently in complex systems with evolving requirements.

Oh, don't get me wrong. I fully agree! What I was saying is that the initial rapid prototyping of a project is happening only once.

Our company offered us to sometimes reconvene physically and discuss such things but since our team are all family men, it hasn't happened yet. But it is a really good idea and we should reconsider actually doing it sometime.

> that rapid prototyping stage is really important

This is an excellent argument for annual all-hands retreats for distributed companies.

So you're going to discuss all your designs in February? What if you need to make a major modification to a design, or like some priority changes or whatever.

The whole idea of agile is to design iteratively and reactively, but you're throwing that away.

I suppose if your process relies on that type of design happening regularly, remote work is not going to allow for that. But I don't think colocation is a requirement of iterative & reactive design.

I work on a remote office, and while I definitely agree that the rapid prototyping stage works better in-person, current tools help a lot - we have a pretty large app that was built 100% remotely (I did ask for in-person meetings but there was no budget).

Honestly, you can collaborate and do almost everything remotely. What does lose a bit is team building, you have to go a bit out of your way to build rapport (but it´s also doable).

I'm still learning how to be more personal while remote. An always-open casual video chat room is a fun idea (especially if you have a screen with it always open in the office!). Games (while on video chat) might also be fun.

Have you ever used a video conference or collaborative online whiteboard? If the actual scribbling is important, have you heard of these things called drawing tablets?

Yes, in fact the company I work for provides, bar none, the best experience for video conferencing and collaborative online whiteboarding I've ever used. We go to great lengths to reduce latency and make the discussion feel as natural as possible.

Its still, at least to me, markedly less productive, than an in-person meeting.

Like I said, conferences, summits, etc. These are done for a reason. Not to mention that there's some research I've seen that suggests that places like Bell were so successful because they cultivated happenstance interactions between smart people that don't happen in distributed environments.

I think that conferences, etc, build up on the human element and are important, but not for the reasons you mention.

My current belief is that a 95% remote team works, you do need in-person opportunities, the more the better, but at least once in a project can be enough.

Reply on news.ycombinator.com