"Targets" are a pretty low end way to think of such an open ended job.

You can think of your job as "They asked me to do X and I'm going to do X and after that the rest of my 40 hours don't matter." Or, "I'm going to do as much as I possibly can in 40 hours." From the start of my career I always thought of it as the latter. I don't understand the mindset of the former in a professional job. Maximize your value to your employer or you'll be the last one to get promoted and the first one to get laid off.

There's always a backlog of defined tasks and there's always open-ended opportunity to make progress in ways you can think up yourself. Do you want to sit around waiting to be told what to do or engineer your own path?

The healthy answer lies somewhere in the middle.

Burning out trying to overdeliver and prove your worth is no better than underdelivering and slacking off.

There is a balance. Exceeding your employer's expectations is of course a good thing as a salaried employee. That's how you build a highly successful career.

But one of my expectations as a manager is that you manage yourself so you're still around 3-5 years from now and don't need to take a break for mental health reasons.

You're a good manager.

It can be very difficult if not impossible to engineer your own path in most environments these days. These days most devs are simply trading time for money. If the backlog board is empty, they're on retainer waiting for it to fill up.

Because of the eternal effort of the enterprise to commoditize developers they're given no decision making power. So even though they continually identify work that could be done to improve product or process, they know it's a crap shoot to follow through on such work as it's more than likely to be rejected for one subjective reason or another.

The recognition must have a high return to make up for all the time wasted on rejected initiatives.

Are you guaranteed those things if you work better than the rest? No, external factors can nullify all your dedicated work.

What would you do if all you had to show for your effort was that employee of the month picture on the wall?

If the delta is worth "tens of thousands of dollars in salary", consider what your free time spent on other things is worth. It might not be.

But "freedom to design my own role"? Where do you get this?

This is an interesting point. We tend to conflate "greater control" with "greater responsibility", but we shouldn't. The first is a benefit, the second is a risk. They often go together, but having had a job with lots of responsibility and no control, they certainly don't have to.

Regardless, I would much prefer to have a working environment where I'm engaged and involved and making an impact than where I'm only grudgingly doing just enough to get by, even if it doesn't lead to recognition and rewards. Although, in my experience, it does.

However the inverse isn't true; your employer doesn't pay you as much as they possibly can for 40 hours work. They pay just enough.

So why not work just enough? It's meant to be a balanced exchange.

That's not the case everywhere though, which is the observation that TFA and the parent were starting from. Obviously if you do make more it's ok.

>And if my company has layoffs I'm one of the last who would be let go.

You'd be surprised how many people thought that and got the short end of the stick.

It's a delusion that helps people sleep at night...

The times I've been at a company where shitty politics supersede reasonable practices, I've left. And having a resume with greater achievements makes this easier than a resume with fewer.

The famous example Taleb uses in his book is the Thanksgiving turkey.

"Consider a turkey that is fed every day," Taleb writes. "Every single feeding will firm up the bird's belief that it is the general rule of life to be fed every day by friendly members of the human race 'looking out for its best interests,' as a politician would say.

"On the afternoon of the Wednesday before Thanksgiving, something unexpected will happen to the turkey. It will incur a revision of belief."

http://www.businessinsider.com/nassim-talebs-black-swan-than...

You're exactly right, in an unexpected way though.

I was working at a somewhat successful BigCo. (makes HN frontpage every other month or so) a few years ago. Then came the time to discuss raises that year. I did more than was required of me, helped other teams, rewrote a bunch of legacy code in languages that were not part of my job description, etc.

What did I get? A sub-inflation raise in a year where the company's revenues increased by 70%. My closest coworkers received about the same. All because we worked on infrastructure, deemed a cost center.

So next year I coasted and put in the bare minimum while working on side project and taking freelance work. Got average to below average marks when the special time came. Then got asked to work unpaid overtime to "fix my mistakes". I quit on the spot. It was a huge relief.

Now I work for the man in the mirror and he's the best boss I could have ever wished for.

Assuming you're rational, say you're paid $P for Q output. If you thought you had a 75% chance to get $P+10% for producing Q+5% output, you'd be right to work harder and produce that extra output. If, on the other hand, you thought you had a 10% chance to get $P+100% for producing Q+50% output, you would not accept that.

I'm sitting here at work typing this reply to you. It's not about using every hour, it's about fundamentally seeing your output as malleable instead of fixed based on your manager's "targets" and seeing yourself as responsible for your level production.

Most of my time (and much of my team's time) is spent on projects that were my idea. It wasn't that way at the start of my career but I've always works towards taking control.

self-directed vs. manager-directed is a separate concern from whether or not a programmer can be expected to put in 40 hours of high focus, high concentration technical work per week.

in my experience getting 20-30 high focus hours in a week is a very good week. the rest of the time has to be used for things that are much less focused. like arguing about this shit on hacker news, for example. it's not even an either/or scenario. you need to do both. just like when breathing you have to both inhale and exhale.

Speaking for myself, I'm done with primadonna developers who think they can shut the door and code alone while running roughshod over their colleagues, then after a couple of years take off and leave behind their mess for others to sort out.

Development is a team sport. If you don't buy into that you won't be working at my company.

Meanwhile, management should provide opportunities for training and so forth to develop their talent.

BUT... it won't work. We're all on a spectrum of ability. Maybe more so, we're all on a spectrum of ability spectrums. Training, education, these aren't the answer to "my devs aren't as good as that one". You take the ability you have, your team has, and you manage and apply it the best way you can. Most often, that doesn't mean having your top developer spend her time training everyone else.

It means you give that top developer the protection and time she needs to get her shit done. If she happens to be the type that gets energy from training and helping others, THEN you have her train others.

In computer engineering terms, you have to balance your control path as well as your data path.

But not to the exclusion of all else.

Again: a team is a team. I, as a manager, need the team to functional optimally. If one developer is a 10x hotshot, but she makes the lives of everyone else substantially worse, I don't give a crap how much code she can write, she can find another team.

The top developer doesn't get to be a silo, a dictator, or a troublemaker. As a high-skilled individual, they are expected to produce code, collaborate with team members effectively, provide mentoring and training, and generally lead by example.

Again, if they can't handle that, they can find a company where their style is a better fit.

No, that's where you're wrong. If that developer is really your top producer, the bottleneck of production, you isolate and protect her exactly to the exclusion of all else. She becomes the worker that cannot, will not, be bothered. It seems counter-intuitive, but read on industrial engineering practices around optimizing an assembly line and you'll see it shown all around.

To get your team to function optimally, you must protect the core assets. And given that those assets are people, they have to feel protected. In the end, the rest of your team exists to support whatever it is that actually creates value. If that happens to be one developer who has their hands in 50% of the code (that others couldn't support if they wanted), then the rest of your team exists to support that one developer.

Ideally, though, no team is so one sided. There are no true 10x developers. And those that exist utterly fail at the rest of team management. At the end of the day, give your workers work they can actually do.

Development isn't an assembly line, and the fact you'd use that analogy says a lot...

If that happens to be one developer who has their hands in 50% of the code (that others couldn't support if they wanted), then the rest of your team exists to support that one developer.

Oh heck no.

If one person or only a few people are creating most of the value on the team, the team is dysfunctional and you've exposed yourself to enormous risk. If those people leave, fall ill, get injured, or go on vacation, you and the team are screwed. If you, as a manager, have put yourself in that situation, you have failed.

You're talking about risk management, not individual worker ability. Yes, it is a poor idea to have any one portion of a system maintained by only one person. So don't. It is a poor idea to have only one person who understands the system architecture. So don't. It's a poor idea to not recognize the different strengths and weaknesses of all your workers regardless of context. So don't.

Just because I label development an assembly line doesn't mean treat your developers like machines. They are machines, human machines. Meaning they have feelings and a whole host of things that must be managed in addition to keeping them well oiled.

"They are machines, human machines."

Contradiction.

Of course, there's meetings and fires, and so the dev should be available for that, but, in all, who cares about the number of hours?

If you're committed to Agile, I don't understand why you're talking about individual commitments at all.

The team commits to sprint scope. The team succeeds or fails in meeting that commitment as a group.

Beyond that the team should be free to figure out how the commitment is met.

We have one team that works 10:30 to 6:30. Another that works more traditional 9-5 hours. One is largely remote. Another is co-located. They all produce high quality work at a solid, and most importantly consistent, rate.

If we tried to force some work pattern on them, I doubt they'd be as successful.

https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

This is the crux. How does the business decide what's a reasonable amount of work to get done in a sprint? If the dev in the OP has time to work on his own stuff, why shouldn't the business ask for a bigger commitment in the next sprint?

Measuring output sounds like an ideal way to evaluate employees, but also sounds pretty challenging in and of itself.

To be clear, identifying a poor engineer seems simple enough. But how do you tell the difference between a bright engineer working on a hard problem and a bright engineer being lazy?

How long a task "should" take is often totally unknown. After all, if a programming task is so routine and well defined that it can be accurately estimated, that is probably good indication that this task can be automated, so we shouldn't be regularly doing such a task.

If the employee is doing external coding instead of surfing reddit on their 'mental floss' time, then that's probably a good thing and its making them a better programmer.

There's issues of course if they're making competing products, or using company proprietary IP, or making money on the side.

But this may come down to the fact that the biggest issue is that you've got an open office plan, where all your employees are snooping on each other. And if this employee was doing this side-coding behind closed doors (or at home) that nobody would care as long as they were hitting their targets.

And with that I'm off to grab some coffee and get back to work...

I was in a group where the non-smokers "saved" their smoke breaks and we all went to breakfast on Friday mornings. We'd take about a 45-60 minute break and the smokers were not allowed to come.

Heart that so many times and it is crap.

Only because i work better than some avg and my output satisfies you, you pay me for working 8 hours and not for something else. I'm going home after 8 hours regardless if i'm done with a task i thought i will finish, why should i leave/slack after 4 hours for a task someone thought it would take 8 hours?

Actually, if you're a salaried employee and not being paid hourly, that's objectively false.

A salaried employee is paid to ... Well, it's up to the employment contract to decide.

Personally, if I hire someone on salary I expect them to estimate level of effort honestly to the best of their ability and complete work at a rate I consider acceptable. If I lowball that expectation that's really my problem.

And the reality is most employees would be dissatisfied with that situation, because most people want to do meaningful and challenging work. So if someone completes their assignments early and ends up filling their time with side projects, it's because I've failed to give them work that challenges them.

The only thing I expect from the employee is that they tell me when they're done so I know what's going on and can decide what I want to do about it (and that should mean working with them to give them more satisfying work so they don't leave out of boredom).

Because you don't have competent technical management.

My team comes and goes as they see fit, we have the highest profitability margins of any of our departments so noone in HR bothers to tell me anything.

Edit: However, with that comes 3AM phone calls where I expect them to act like adults and do what needs to be done, so I'm not perfect by any means.