Remote vs. in-office software teams: Which is better?
-
Yes, but you're very much focussed on the education element, which is a completely different thing from working with people, perhaps on a project that's a few years "mature". If you need to learn something from a teacher, 99% of the time you'd do as well reading a book, because the huge majority of teachers know little more than is in the books -- like if you need to learn the latest weird way of typing in a FOR loop, in the langue du jour, no problem! Get the guy on-line or google it. but if you need to pick specialist knowledge from an expert, because you are now working on a product that he's been working on for years, and knows inside-out (but he is by no means a teacher), then you don't want to sit and listen to a lecture, because that's not what he's good at, and he won't waste his time preparing one. You need to pick his brains for a starting point, then keep going back with little questions about little details -- and you have to pay attention to how he says what he says, and the doodles and squiggles and gesticulations that clarify and reinforce what he's saying. If we're talking about someone preparing for months to do a Ted talk, fine; that can be done "over the air", and so can basic meetings (where little would be achieved, no matter how the meetings were held), but to extract hands-on experience and knowledge from a colleague: sitting on the corner of his desk and chatting will get you an order of magnitude more Useful information per minute spent than an on-line chat will, no matter how cool or cute the tech is. And you really don't want to know how many comparatively useless hours I've spent in discussions held with the three corners of the Earth via various high-tech and ridiculously expensive comms tools.
I wanna be a eunuchs developer! Pass me a bread knife!
You misunderstood what I mean by educating, as I previously mentioned I'm referring to a worker. This is probably my fault because I mentioned online courses, with that I just wanted to emphasize that remote learning is rather common. True, it's not a same learning process but regardless I think it was a valid point.
Mark_Wallace wrote:
You need to pick his brains for a starting point, then keep going back with little questions about little details -- and you have to pay attention to how he says what he says, and the doodles and squiggles and gesticulations that clarify and reinforce what he's saying.
This can all be done remotely, even doodles and squiggles (which are essential to me, I always draw stuff out with my tablet). Regarding the gestures, ok this cannot be done, but if your teaching depends on your gestures then there is something wrong with it. In short, you can get the required experience and knowledge from your colleague without him needing to prepare some lecture or anything. He would just explain everything in the exact same manner as if he is sitting there right beside you.
Mark_Wallace wrote:
sitting on the corner of his desk and chatting will get you an order of magnitude more Useful information per minute spent than an on-line chat will, no matter how cool or cute the tech is.
Can you provide some concrete example of that, something you found that is easily explainable live, but requires long time remotely? I work in a company that switched to fully remote for years now and we're somewhat associated with two other fully remote companies. We all never had an issue with inexperience workers (at least to my knowledge and observation). FYI we have quite a few mature projects (one of our products is 10 years old, and it's not a legacy product ;)). Mark if you honestly have an experience in working remotely and those conclusion of yours are not based on some subjective feelings, but rather facts, then my conclusion is that if there really are some things that are hard to explain remotely then for that particular job inexperience workers will have problems and for other jobs they will not. So in short that generalized statement, people who lack experience should only work in office, is not true.