Hacker News Reader

Comment by fogetti | Hacker News Reader

Give me clear goals which are measurable, and I will get things done either remotely or on-site. It doesn't matter which one. This is a win-win situation because my manager can track my progress based on the previously setup measurements. And to achieve this, location is irrelevant.

Things usually start turning south when managers just simply demand speed. Or eagerness. Or dedication. Or other bullshit which has no relevance regarding any specific task.

These are the cases which brilliantly show the lack of management skills. These are the kind of little men who demand you to be at the office all time. You can call them control freaks, or micro-management fetishists. It doesn't matter. These people just show one thing with their behaviour: that they don't trust their subordinates.

View on HN

That is technically true, but you do NOT want clear goals though. Clear goals are for junior "code monkeys" who just do what they are told without any concern for if they are going the right thing.

If you want input into your work and the feeling that you are actually doing the right thing you need to have the context around your goals. Your physical presence in the offices lets you take part in "water cooler" and "hallway" conversations with various people.

Yes you can do some of that via email, forums, and the like. However the human factor of your presence changes the tone of the conversation. It isn't just you either, the other person(s) involved.

When you have a short, critical, task that needs to be done fast, then staying home without a phone or email is the best way to get it done fast. However for anything else communication is an important part of your job and physical presence aids that.

That isn't to say remote work cannot - it does. However there are real disadvantages to it that need to be considered.

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.

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

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

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.

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.

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.

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.

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.

> Clear goals are for junior "code monkeys" who just do what they are told without any concern for if they are going the right thing.

Agree 100%, the less you act like a cog in a machine the less people will treat you like one. Lots of developers seem to want to log in to a system every day and just have a list of tasks they have to complete without any real collaboration or divergent thought and have their salary calculated by % of task completion.

In my experience the people who collaborate in the office and try to push things further are the ones easily granted autonomy and no longer have to answer to micromanagement. Managers can see the difference between a box ticker and the breakouts that are actually making a difference at the company, once you achieve that then you'll notice people stop questioning what time you turn up to the office if at all.

You can act like you're not a cog, but there's only so much autonomy you get working under someone else.

If you're an employee you are a "code monkey" to one degree or another. If you do not need clear goals, Work for yourself.

You don't need dozens of people above you telling you what to do and extracting part of your paycheck if you can figure it out and execute it on your own.

The CEO of my company doesn't tell me what to do. He tells a vice president who tells [skip a dozen or so layers of management] who tells my boss who tells me. Part of my job is to go on down the line - I'm expected to feed work to a half a dozen junior engineers (there are other senior engineers on my team who also are expected to find work to feed on down the chain).

Each level of the chain requires understanding of what the business needs. I need to make autonomous decisions every day that ultimately the CEO stands behind. The composite of all the good decisions (enough better be good) results in the success of my company and the CEO will take credit for it. However all the CEO says to me is "we will be the global leader in [the generic area my project is in]" in an all company meeting. Every step down the chain has just been filling in details.

I get what you're saying (and agree) but you're using my metaphor on how to extract a better work life in a team environment to make a completely different different point on a completely different topic.

> Clear goals are for junior "code monkeys" who just do what they are told without any concern for if they are going the right thing.

Most of the interview processes in tech are geared towards hiring for this exact role. There's some ego stroking involved, but for the most part the sorts of "code trivia" questions candidates jump through are basically "can you implement this algorithm or data structure" correctly. They don't actually test problem solving ability.

So it seems to me for he kinds of trivial work most of us in the industry are doing your objection is a bit immaterial.

Some of us are engaged in more complex work, and I agree 100% with you about that. Remote doesn't quite cut it most of the time for that sort of thing.

I think this is confusing goals with tasks. And even then, sometimes you still want a mix of both.

A nice backlog of tasks that need done along with high level goals we'd like to achieve (but no solid tasking to make happen) is a beautiful thing. Unfortunately, it isn't free and takes effort. Which is a large part of what a manager should help with.

I find that even when given "goals" in a broad sense, when you break down the problem into its constituent parts there generally is very little to debate. And when there is something to debate, those conversations take time to accumulate information and research, and for people to "digest" them completely.

I find that in-person discussions about said topics is more counter-productive than productive since in-person meetings sometimes inadvertently suggests you have a fixed time-frame within which to come to a conclusion. And the "debatable" topics generally aren't going to be acted on immediately. There needs to be coordination and planning when you all come to a conclusion that a particular strategy is going to be the way forward, and a lot of times assumes you're probably going to break backward compatibility so it won't be released until a major version bump.

I would say there are trade-offs with remote based communications with distinct advantages you don't mention that help make up for the lack of the human factor. The most obvious is that it eliminates the human factor, which can make it a lot easier to work with people who have unpleasant personalities. It also makes all communications more asynchronous, which means you can discuss things at the pace needed instead of the forced sync of a person staring at you. Then there are all the technical benefits, like cut-n-paste, live URLs, screen sharing, logs of conversations, etc.

It also sounds like you haven't experienced a fully remote team working. You don't miss out on the physical presence because it is not there to miss and people make up for that absence in other ways. All the water-cooler/hallway conversations are then there, online, in the chat rooms or what not.

> Clear goals are for junior "code monkeys" who just do what they are told without any concern for if they are going the right thing.

Yeah, this is so true.

I think the task with an clear process to do it have an clear goal. But other than that, tasks that's very vague such as design an API, design schema to efficient some kind of certain query usually requires a bit of art, and we learn from the mistake/success of last similar project to improve this one.

> Give me clear goals...

Arguably, I need talented individuals forming good teams to clarify the goals and to have direct input to the roadmap. Reducing people to implementors may not be great for morale, motivation and engagement. Some people want their input to be more than their code, and rightly so.

You are implying things which I didn't say. See my previous answer to bluGill.

If you have very clear goals, tasks and visibility, a lot of stuff is possible. Flexible, hours, flexible locations, contracting.

At the extreme end of that statement, you might even say that if goals and tasks are welll enough defined, post-work-AI-automation-Jeremy-Corbyn. :)

For most jobs, tasks and goals are not clearly defined. That's why managing and being managed is hard.

If conditions were amenable enough, I'd work in a factory too. (I'm being serious, I would.)

Reply on news.ycombinator.com