4 ms·

The tasks are not the hard part. Alignment is a lot easier when you’re all close. I went from a distributed team (4 offices spread between EU and US) to a team

by jib 7y ago

The tasks are not the hard part. Alignment is a lot easier when you’re all close. I went from a distributed team (4 offices spread between EU and US) to a team that’s all co-located. The speed and quality of alignment is miles different. There’s stuff we outsource (easy to describe tasks), but the stuff that needs tight iteration loops is so much easier when you can just get up, walk a few meters, and talk about it.

14 7y ago
I really think that in the future people will use something like holoportation[0] to work at home or remotely across the world. Because like you say sometimes it makes sense to be present with a person to accomplish a task. It is very hard if they are trying to describe something when it would only take half a moment to visually look yourself and understand the direction the person is coming from. Holoportation looks very neat I really hope I get to try it one day. [0]:https://www.youtube.com/watch?v=7d59O6cfaM0 https://www.youtube.com/watch?v=7d59O6cfaM0
- newqer 7y ago
  When I'm retiring, +/- 30 years from now, I'm going to put on my Virtual Reality glasses and never leave the house again.
  - runawaybottle 7y ago
    Don’t underestimate humanity’s ability to adapt to staring at screens as the norm (on a societal level).
pnako 7y ago
The Linux kernel is developed remotely. I'm tiring of hearing cat food delivery startups pretend it won't work for them.
- JoshTriplett 7y ago
  The Linux kernel is willing to sacrifice the time of individual developers on the altar of project efficiency. That works for the Linux kernel because there are a huge number of prospective developers, and on balance the project doesn't generally care if any specific developer wastes some time or duplicates some effort. That, by itself, isn't an argument that remote work for a given company will work.
  - pts_ 7y ago
    Yacking wastes times of a developer any time of the day. Having to explain the manual to people who cannot read, doubly so.
- xxpor 7y ago
  A significant part of it isn't though. For example, engineers writing a device driver for a piece of hardware are most likely sitting with each other and near the HW guys.
- baddox 7y ago
  What is your argument? Those sound like two very different types of product development that I would expect to work very differently in nearly every conceivable way.
  - pnako 7y ago
    My argument is: if a complex project like the Linux kernel, or MySQL, or CMake, or pretty much any large piece of open source software, can be written by remote teams, I don't see what's specific about typical corporate or start-up technology that would prevent that.
    - rusticpenn 7y ago
      The difference is that, the developers are unpaid for the Linux Kernel.
eecc 7y ago
I’m sorry if I sound harsh. The problem is not a matter of better or worse “alignment”. It’s just poor quality planning and execution. Your team is just improvising, figuring out as you go, what is exactly that you need to build. It’s not even Agile. Agile is about tight loop upfront planning, and avoiding last-minute distruttive changes and meetings...
- solveit 7y ago
  > It’s just poor quality planning and execution. Potato potato. If you can get away with "poor quality planning" in person but not in remote, it doesn't matter what you call it.
- scarejunba 7y ago
  You get 11 weeks until Demo Day. If you spend it learning how to plan better you've already lost.
  - eecc 7y ago
    Well, that's assuming you still don't already know how to plan or even put your thoughts on paper. If that's the case, you shouldn't be in the business unless you're in a junior/apprentice position (which is fine, one has to start somewhere.)
- ascar 7y ago
  > It’s not even Agile. Agile is about tight loop upfront planning, and avoiding last-minute distruttive changes and meetings... That's an abomination definition of agile, probably influenced by scrum. In the agile manifesto it says nothing about "tight loop upfront planing", however it does explicitly say[1]: > Individuals and interactions over processes and tools > [...] > Responding to change over following a plan While that doesn't mean all planning is bad (it isn't and the manifesto acknowledges that), the planning is not the agile part, it's the leftover of the original traditional management, because it is necessary to a certain degree (e.g. for alignment but also for a lot of other business related tasks). If you're running a pure kanban approach, you don't even plan in tight loops and I had much better experience with that (and a single team lead with a good strategic vision) than I had with Scrum. Scrum is just easier to handle for big (old) organizations and gives developers some protection from bad management. [1] https://agilemanifesto.org/ https://agilemanifesto.org/

by jib 7y ago

14 7y ago

I really think that in the future people will use something like holoportation[0] to work at home or remotely across the world. Because like you say sometimes it makes sense to be present with a person to accomplish a task. It is very hard if they are trying to describe something when it would only take half a moment to visually look yourself and understand the direction the person is coming from. Holoportation looks very neat I really hope I get to try it one day. [0]:https://www.youtube.com/watch?v=7d59O6cfaM0 https://www.youtube.com/watch?v=7d59O6cfaM0

newqer 7y ago
When I'm retiring, +/- 30 years from now, I'm going to put on my Virtual Reality glasses and never leave the house again.
- runawaybottle 7y ago
  Don’t underestimate humanity’s ability to adapt to staring at screens as the norm (on a societal level).

pnako 7y ago

The Linux kernel is developed remotely. I'm tiring of hearing cat food delivery startups pretend it won't work for them.

JoshTriplett 7y ago
The Linux kernel is willing to sacrifice the time of individual developers on the altar of project efficiency. That works for the Linux kernel because there are a huge number of prospective developers, and on balance the project doesn't generally care if any specific developer wastes some time or duplicates some effort. That, by itself, isn't an argument that remote work for a given company will work.
- pts_ 7y ago
  Yacking wastes times of a developer any time of the day. Having to explain the manual to people who cannot read, doubly so.
xxpor 7y ago
A significant part of it isn't though. For example, engineers writing a device driver for a piece of hardware are most likely sitting with each other and near the HW guys.
baddox 7y ago
What is your argument? Those sound like two very different types of product development that I would expect to work very differently in nearly every conceivable way.
- pnako 7y ago
  My argument is: if a complex project like the Linux kernel, or MySQL, or CMake, or pretty much any large piece of open source software, can be written by remote teams, I don't see what's specific about typical corporate or start-up technology that would prevent that.
  - rusticpenn 7y ago
    The difference is that, the developers are unpaid for the Linux Kernel.

eecc 7y ago

I’m sorry if I sound harsh. The problem is not a matter of better or worse “alignment”. It’s just poor quality planning and execution. Your team is just improvising, figuring out as you go, what is exactly that you need to build. It’s not even Agile. Agile is about tight loop upfront planning, and avoiding last-minute distruttive changes and meetings...

solveit 7y ago
> It’s just poor quality planning and execution. Potato potato. If you can get away with "poor quality planning" in person but not in remote, it doesn't matter what you call it.
scarejunba 7y ago
You get 11 weeks until Demo Day. If you spend it learning how to plan better you've already lost.
- eecc 7y ago
  Well, that's assuming you still don't already know how to plan or even put your thoughts on paper. If that's the case, you shouldn't be in the business unless you're in a junior/apprentice position (which is fine, one has to start somewhere.)
ascar 7y ago
> It’s not even Agile. Agile is about tight loop upfront planning, and avoiding last-minute distruttive changes and meetings... That's an abomination definition of agile, probably influenced by scrum. In the agile manifesto it says nothing about "tight loop upfront planing", however it does explicitly say[1]: > Individuals and interactions over processes and tools > [...] > Responding to change over following a plan While that doesn't mean all planning is bad (it isn't and the manifesto acknowledges that), the planning is not the agile part, it's the leftover of the original traditional management, because it is necessary to a certain degree (e.g. for alignment but also for a lot of other business related tasks). If you're running a pure kanban approach, you don't even plan in tight loops and I had much better experience with that (and a single team lead with a good strategic vision) than I had with Scrum. Scrum is just easier to handle for big (old) organizations and gives developers some protection from bad management. [1] https://agilemanifesto.org/ https://agilemanifesto.org/