I think that if you only do a few hours of actual time working each week, you are deceiving not only your employer but yourself about what is productive and whether you're a good employee.
There are no good metrics for programmer productivity, but spending < 20 hours a week actually switched-on as a full-time employee is obviously a problem, to me.
I honestly doubt any one who says that they are productive for 40 full hours a week, or even 6 hours per day. There's a lot of downtime that employees usually do not notice from a first person perspective. Even still, the goal of IT is first and foremost to empower business goals through technology, one of the main aspects of that is increasing workflow efficiency and throughput of the rest of the business processes - in other words, make good software so the rest of the business doesn't have to work so hard.
I have definitely met workers who I've given a task and they produce sub-average work and, when confronted, give me the spiel about they worked "so many hours on this" and how could I "invalidate the time they spent".
At the end of the day, as long as you are doing the job at the pace I need you to be doing the job, then I don't care if you did it in 1 hour or 8 hours. If you want more work, ask, and if you're spending too much time on a task, then there is a communication problem as a team member should have caught that you were on the wrong track.
In my experience, focusing on hours worked has never produced quality work.
The goal of work is to intentionally decrease the amount of work you have to do to achieve the same tasks. Why pay you when I can find a person who will do the same work you do in less time?
I think what you're arguing is that employees should always have some work to do, which simply won't be the case in every industry
What I'm saying is that if I manage to build enough tooling to streamline my work so it takes me twenty hours of "at work" time instead of the forty it used to, then under the standard full-time employee arrangements, I have an obligation to use the remaining time for other tasks, like finding a new corner of the company's workflows I can help optimize and streamline.
I've never seen a system that was even close to perfectly designed or optimized. You can always find more to improve.
Yes, there are diminishing returns for any specific corner, and there comes a point when the increase in risk from doing further deployments is not worth the shrinking business gains for optimizing a given corner, but I strongly believe there are always more improvements that can be made, both at a small, focused level and stu the big picture level of what systems should even exist in a given company.
You don't though. If you become 40% more productive, you should be paid more. Quietly taking that time as part time hours, instead of staying full time and getting a promotion+raise, is fine.
You are welcome to your opinion, and to your own moral code.
Mine means I do have that obligation.
I suspect many share this aspect of my code, which boils down to "keep your commitments, both explicit and implicit."
Nobody hires a full-time employee expecting that they'll start slacking off once they get the basics of their job going smoothly, and I know that going in (as do most people).
Thus, if I plan to do that, I have to warn them up front that our expectations are likely not aligned.
If I don't want to have that obligation, then I can negotiate up front, or take on the risk of being a consultant or startup founder.
Thought experiment: ask yourself whether you'd hire someone advertising my work ethic or yours, if all other aspects are equal between the candidates.
Then ask yourself why you answered as you did, and which response the market will reward better in hiring.
My reason for this stance is my personal code of ethics, not pragmatism, but I think the pragmatic consideration may clarify my point.
You put a lot of weight on your morals and work ethic but my point is that those mean nothing to me. I don't care how hard you work to get the job done. Once you're salaried, how efficiently you perform your job is up to you, and what action I take when you don't meet the pace I expect is up to me. When I manage a team, I encourage those on my team to bring up any obstructions or changes they'd want to see to improve the efficiency of their work - past that I don't care as long as they understand the timelines we are working under and if everything is on time, why would I add undue stress to my team?
If timelines become tighter, at that point, and only at that point, would I crack down on efficiency.
>Thought experiment: ask yourself whether you'd hire someone advertising my work ethic or yours, if all other aspects are equal between the candidates.
That's like asking all else being equal, would I hire the person who wore Air Force 1s to the interview or the person who wore chelsea boots. That has nothing to do with your performance of your job and any distinction on that matter is personal preference. The only thing that is important is are you getting the job done on the pace it needs to get done.
At this point you seem like you'd discriminate your employees based on which IDE they were using. If they produced good work, would you care that the most productive person on your team was using Notepad++ to do their job?
It sounded to me like you were suggesting an hour or three a day of actually focusing your attention on your workplace is plenty for a full-time, salaried employee.
If that's not what you mean, then I've obviously misunderstood you.
What do you suggest regarding hours of "butt in seat" when WFH? It's a truly wretched metric for productivity, but I think ignoring it entirely is unwise.
I would (and do) encourage my teammates to use whatever editor or IDE they want, as long as it doesn't cause issues for the rest of the team (which I have seen crappy obscure tools do, in one memorable case by converting line endings to classic Mac OS style across many files, but only on edited lines).
> That's like asking all else being equal, would I hire the person who wore Air Force 1s to the interview or the person who wore chelsea boots. That has nothing to do with your performance of your job and any distinction on that matter is personal preference. The only thing that is important is are you getting the job done on the pace it needs to get done.
Whether a candidate thinks they should put in 8 hours a day vs. two or four, if that's all their current task takes, is directly relevant to how effective an employee they will be.
It is not at all like what kind of shoes they wore to the interview, which is indeed unrelated to their technical skills or workplace conduct.
As far as ethics or working hard mattering, I think of them as necessary but not sufficient. If I have a great work ethic and bust my butt but do not achieve anything, I'm a poor employee.
When I have a task estimated at four hours but it takes me two, I don't think "Sweet, HN until lunchtime," I grab the next thing off the stack.
Like I said, perhaps I'm not understanding what you're trying to describe.
There are no good metrics for programmer productivity, but spending < 20 hours a week actually switched-on as a full-time employee is obviously a problem, to me.