4 ms·

And what would be those disadvantages? You listed things which you think are supporting the arguments to be present in the office. But one argument which is sup

And what would be those disadvantages? You listed things which you think are supporting the arguments to be present in the office. But one argument which is supporting on-site presence, doesn't make it automatically an argument against working remotely. And you are basically trying to put words in my mouth. I didn't say a word that I will do what I am told without concern. That's only your implication. Correct me if I am wrong, but you imply that because requirements are usually unclear: that means that clear goals are undesirable. Does that sound logical to you? Because to me that's a big no-no. I only saw people pushing this kind of mentality who like to fish in troubled waters and enjoy the mess to take advantage of it for their own sake (i.e. climbing corporate ladders). And let me highlight one thing: if I am supposed to clear things up and organize my work, than what is my manager supposed to do? In this world that you imagined there is no role for a manager IMO. And that would be pretty much fine with me. It's just far from reality. I won't subscribe to the idea that the office is a rainbow colored fairytale. I am coming from the exact opposite direction of thinking.

sidlls 9y ago
Just about anyone writing code in this industry can learn to implement, given a blueprint. Not everyone can learn to generate the blueprint. The former takes some marginal ability to memorize facts and to recognize patterns. The latter takes the ability to truly understand a problem and orchestrate the pieces of a solution together, some of which will be tasks ("clear goals") for a coder to implement. It's the (or at least one) difference between perpetually solving homework from CS and being an engineer. Can't speak for GP, but my view is the latter can't be accomplished without some direct, in person interaction today. The future, with more robust collaboration tools, may be different.
dalbasal 9y ago
Not that it is undesireable, just that it doesn't exist. The mess you are talking about is fact. Maybe this is because managment sucks, but it's still a fact. Goals & requirements are unclear. This is a fact almost everywhere. Very few people (definitely programmers) have very clear requirements and goals to work against. So, I agree with you that having clear goals and requirements is a path to virtual workplaces. But, I think this is a troublesome route. Clarity is elusive. If it wasn't elusive, all the outsourcing efforts of 10 years ago would have been more successful. Computers are against us on this. If something is very clearly defined, it is a candidate for automation, outsourcing and such. The stuff we're left with is the poorly defined mess. That's why we have so much of it.
lloeki 9y ago
"Clear goals" can have different levels of abstraction. Junior code monkeys may need finely grained detailed steps while climbing the technical, architectural or management ladder will make your goals more abstract as they encompass greater breadth and depth, yet them not being any less clear. "Steer team to deliver product A in 3 months with top quality" or "provide analysis of strange crash events P, Q, R that appear to be vaguely related and originate in lib K, and propose possible short-term mitigation tactics as well as systemwide refactoring strategies to reduce or remove dependency on regularly problematic but heavily used lib K within a mid-term timeframe, and we'll talk about your conclusions in two weeks" can be just as clear to some people as "implement method foo doing X according to spec point Y.Z by the end of the day" is to others.
- lliamander 9y ago
  This is true. However, I think at the highest levels of autonomy is when people actually get to define what their goals are[0]. That is not to say that it cannot be done remotely. In fact, in most large tech organizations, the highest autonomy positions will almost certainly entail a lot of remote collaboration (with customers, sales, suppliers, support, remote engineering teams, etc.). However, the more autonomy one is granted, the more context one needs to make the correct decisions. Context requires access to high-signal information sources (i.e. relationships with the right people). Being in the office is a good way to discover those information sources. You also have to make yourself highly visible. You can certainly do that while being remote, but there is more conscious effort involved. [0] https://rkoutnik.com/2016/04/21/implementers-solvers-and-finders.html https://rkoutnik.com/2016/04/21/implementers-solvers-and-fin...
bluGill 9y ago
On site vs remote is a very complex topic that I just scratched the surface of. I agree that my arguments are NOT the only ones. They are not the only ones for working onsite (but they are major ones programmers like to ignore), and your arguments for remote work are not the only ones for working remote. We can spend years debating this and not come to a clear answer: a clear one size fits all does not exist. My implication is not that you do what you are told without concern. My implication is that remote workers in general lack critical knowledge of that should shape what their concerns are. Knowledge that you only can get by keeping in touch with lots of different people. (example, last week I was talking to an engineer who had to stay late because a bunch of others subtly broke the build system - In 10 minutes I had a solution so nobody would have to touch that part again. As the build system maintainer I have the knowledge to do that, while most people don't really understand the big picture. If I was remote I never would have learned of this issue) Yes clear goals are undesirable because requirements are unclear. As others have pointed out, your value has a human is ability to make sense of unclear requirements. Once you make sense of the requirements you automate them. You are not a factory worker doing the same thing over an over again on an assembly line. The office is not all rainbows - far from it. However there are real advantages to them that cannot be ignored.
- wolco 9y ago
  Companies that rely on hallway conversation to make decisions are missing key processes. You should have been involved officially when the issue happened. What if you never had that conversation. Luck shouldn't play a part. Communication is the key piece and easy access to face to face can hide a lack of process. Remote or in person you should have gotten an alert.
  - bluGill 9y ago
    This is wrong on many different levels. First of all, the guy doing the manual process didn't even realize that it was easy to automate. So he never would have invoke the processes. Even ignoring the above, the official process is by nature too heavy. It would cost over hundred man-hours by the time the proposal is written, put before a committee, acted on, the proper story wrote, and someone assigned to the write the code. In the mean time 6 months have passed and the first guy thus spent another 2 hours doing it manually. That is 100 hours on a manual process that ultimately costs the company 4 hours a year over the expected 15 year life of this project - the math does not work out. Oh, and the committee includes marketing who don't really care about engineering tools (they should not!), so the end result would be the process remains manual because the final decision is this isn't worth doing - and it isn't worth the time it would take to make them understand why they should do it. There is a reason for official processes. There is a reason companies give trusted people authority to ignore them for trivial things.

sidlls 9y ago

Just about anyone writing code in this industry can learn to implement, given a blueprint. Not everyone can learn to generate the blueprint. The former takes some marginal ability to memorize facts and to recognize patterns. The latter takes the ability to truly understand a problem and orchestrate the pieces of a solution together, some of which will be tasks ("clear goals") for a coder to implement. It's the (or at least one) difference between perpetually solving homework from CS and being an engineer. Can't speak for GP, but my view is the latter can't be accomplished without some direct, in person interaction today. The future, with more robust collaboration tools, may be different.

dalbasal 9y ago

Not that it is undesireable, just that it doesn't exist. The mess you are talking about is fact. Maybe this is because managment sucks, but it's still a fact. Goals & requirements are unclear. This is a fact almost everywhere. Very few people (definitely programmers) have very clear requirements and goals to work against. So, I agree with you that having clear goals and requirements is a path to virtual workplaces. But, I think this is a troublesome route. Clarity is elusive. If it wasn't elusive, all the outsourcing efforts of 10 years ago would have been more successful. Computers are against us on this. If something is very clearly defined, it is a candidate for automation, outsourcing and such. The stuff we're left with is the poorly defined mess. That's why we have so much of it.

lloeki 9y ago

"Clear goals" can have different levels of abstraction. Junior code monkeys may need finely grained detailed steps while climbing the technical, architectural or management ladder will make your goals more abstract as they encompass greater breadth and depth, yet them not being any less clear. "Steer team to deliver product A in 3 months with top quality" or "provide analysis of strange crash events P, Q, R that appear to be vaguely related and originate in lib K, and propose possible short-term mitigation tactics as well as systemwide refactoring strategies to reduce or remove dependency on regularly problematic but heavily used lib K within a mid-term timeframe, and we'll talk about your conclusions in two weeks" can be just as clear to some people as "implement method foo doing X according to spec point Y.Z by the end of the day" is to others.

lliamander 9y ago
This is true. However, I think at the highest levels of autonomy is when people actually get to define what their goals are[0]. That is not to say that it cannot be done remotely. In fact, in most large tech organizations, the highest autonomy positions will almost certainly entail a lot of remote collaboration (with customers, sales, suppliers, support, remote engineering teams, etc.). However, the more autonomy one is granted, the more context one needs to make the correct decisions. Context requires access to high-signal information sources (i.e. relationships with the right people). Being in the office is a good way to discover those information sources. You also have to make yourself highly visible. You can certainly do that while being remote, but there is more conscious effort involved. [0] https://rkoutnik.com/2016/04/21/implementers-solvers-and-finders.html https://rkoutnik.com/2016/04/21/implementers-solvers-and-fin...

bluGill 9y ago

On site vs remote is a very complex topic that I just scratched the surface of. I agree that my arguments are NOT the only ones. They are not the only ones for working onsite (but they are major ones programmers like to ignore), and your arguments for remote work are not the only ones for working remote. We can spend years debating this and not come to a clear answer: a clear one size fits all does not exist. My implication is not that you do what you are told without concern. My implication is that remote workers in general lack critical knowledge of that should shape what their concerns are. Knowledge that you only can get by keeping in touch with lots of different people. (example, last week I was talking to an engineer who had to stay late because a bunch of others subtly broke the build system - In 10 minutes I had a solution so nobody would have to touch that part again. As the build system maintainer I have the knowledge to do that, while most people don't really understand the big picture. If I was remote I never would have learned of this issue) Yes clear goals are undesirable because requirements are unclear. As others have pointed out, your value has a human is ability to make sense of unclear requirements. Once you make sense of the requirements you automate them. You are not a factory worker doing the same thing over an over again on an assembly line. The office is not all rainbows - far from it. However there are real advantages to them that cannot be ignored.

wolco 9y ago
Companies that rely on hallway conversation to make decisions are missing key processes. You should have been involved officially when the issue happened. What if you never had that conversation. Luck shouldn't play a part. Communication is the key piece and easy access to face to face can hide a lack of process. Remote or in person you should have gotten an alert.
- bluGill 9y ago
  This is wrong on many different levels. First of all, the guy doing the manual process didn't even realize that it was easy to automate. So he never would have invoke the processes. Even ignoring the above, the official process is by nature too heavy. It would cost over hundred man-hours by the time the proposal is written, put before a committee, acted on, the proper story wrote, and someone assigned to the write the code. In the mean time 6 months have passed and the first guy thus spent another 2 hours doing it manually. That is 100 hours on a manual process that ultimately costs the company 4 hours a year over the expected 15 year life of this project - the math does not work out. Oh, and the committee includes marketing who don't really care about engineering tools (they should not!), so the end result would be the process remains manual because the final decision is this isn't worth doing - and it isn't worth the time it would take to make them understand why they should do it. There is a reason for official processes. There is a reason companies give trusted people authority to ignore them for trivial things.