Edit: Seems you're based in South Africa? My thoughts are biased from the US perspective, so take them with a huge pile of salt.

Surely you've worked on something with passion before? At least for me, there's additional energy, focus, and clarity of thought when I'm really engaged with something, this counts for more than just extra hours of detached professionalism (let alone negative mindsets). The quality of work and the hours put into it aren't so tightly intertwined. The "how" can matter quite a bit, and even if I don't get around to implementing it until the next day at the office, I don't mind thinking about something over dinner or in the shower when I'm technically not "working". (Salaried employees don't have to "clock in" / "clock out" anyway.) I'm additionally much more motivated to engage in self-learning of new things that I may be able to put into practice on the work later. A single tiny example is just knowing about regex can save tremendous amounts of work. Same with parser generators. Softer things like the "Mikado Method" are more ehhh for whether they're worth it.

Quite a bit further down the scale of people who don't care at all how something gets done, simply not half-assing things goes a long way. To even slightly more sophisticated looks into productivity, it also becomes clear that you end up going faster when you're not having to go back to half-assedly fix the flaws of the half-assed thing done a few months ago. It takes time to do code review? Yes, and? That time pays for itself, no one needs to start working more than contractual minimums in order to get planned features out on a good schedule because of code review. In fact, given it's the only practice that consistently replicates in studies on quality, introducing it if it's absent will probably speed things up over longer time scales even if some people get mad they can't just merge their diff into master right this second. (Code review is very much a "we care at least a bit about how the job is done, not just whether it's 'done'" thing.)

Though sure, you can also put in more time than the contractually obligated minimum. Sometimes that's fine. But it's not required. There are plenty of devs out there who do a fine job with professional detachment and make sure to be done and gone by a certain hour. But that requires caring at least a bit about professionalism, and not just hacking crap together to increase your ticket close rate.

> In any agile setup the dev who goes slower but better is going to get dinged in every single standup and metric

Not my experience, nor that of many other engineers I've talked to who have worked at a lot more places than I have. I'm sure it happens, maybe I'm lucky. Admittedly I don't know anyone who has worked for Amazon.

If it's a concern, I'll say it's helpful when you get team buy-in to care at all about quality, then expectations are easier to set and maintain even in the face of re-orgs. If you're the only one who cares, or wants to care, yeah, it'll be a struggle.

There are occasionally stories, and I've seen it a few times, of devs who just go slow, they don't actually do anything better. Sometimes those "dings" are to some degree valid, but there's usually more going on than apparent speed in closing tickets and even a toxic PIP process where someone's really just out to get someone else for personal reasons will involve more "evidence gathering" than just such a metric. Anyway, when a worker is actually just slow and not better, then instead of trying to pick two of good/cheap/fast you get 0. (Since unless you're dealing with a lot of offshoring, a lot of orgs and even startups have already abandoned cheap.) We should all strive to be good and fast regardless.

You've got a long post, so I am going to work through it point by painful point, while still being as brief as possible :-)

To recap, the question I posed is

     I have to ask, what's the alternative type of author to one who does the job however and goes home?

> Surely you've worked on something with passion before?

I don't think that is relevant to the question. It's unreasonable to expect people to actually be passionate about work. Engaged while on the clock? Professional? Competent? Studious? Yes to all of the above.

I would answer the same to someone who says "I always put in an extra 2 hours each day. Surely you've done the same too?": Just because you do it, does not make it reasonable to ask of employees.

> I don't mind thinking about something over dinner or in the shower when I'm technically not "working".

That's also not relevant to the question. Just because you don't mind doing legwork during dinner does make it a reasonable ask of someone else. Maybe they want to talk to their kids? Maybe they want to watch TV?

It is beyond unreasonable to expect that staff will forgo their private time to think about work problems.

> I'm additionally much more motivated to engage in self-learning of new things that I may be able to put into practice on the work later. A single tiny example is just knowing about regex can save tremendous amounts of work. Same with parser generators.

Once again, this is irrelevant to the question I posed. I don't get the point you are trying to make with (what I construe as) irrelevant anecdotes.

...

You next paragraph, using code reviews as an example, I feel can be addressed by "The Company Pays For That Because It Is Done On Company Time". IOW, the company values it enough to make time for it.

> Though sure, you can also put in more time than the contractually obligated minimum. Sometimes that's fine. But it's not required. There are plenty of devs out there who do a fine job with professional detachment and make sure to be done and gone by a certain hour. But that requires caring at least a bit about professionalism, and not just hacking crap together to increase your ticket close rate.

Here's the meat of the argument, I think: just hacking crap together to increase the ticket close rate.

My original point is that, when this is done, this is not the fault of the employee! If the company incentivises that behaviour, then you shouldn't be judging your coworkers for following that incentive.

After all, as you've demonstrated with the code-review example, if the company wants a particular output, they can so very easily get it! If the company wants non-"hacked together crap", they can incentivise that.

IOW, you are negatively judging some person for doing exactly what is wanted by the company! What you want is not relevant to the company.

The unfortunate reality is that "hacked together crap" is more often than not more valuable to the company than quality software as you define it, because if it wasn't then the company would stop incentivising the quality of "hacked together crap".

When the company removes ticket-closing rates in its metrics, and replaces it with "quality" (however you define it) then you won't see "hacked together crap".

Until then, it's almost certainly bad form to judge people who are simply optimising for the metrics that they are being measured on.[1]

The TLDR would be "You're blaming the players when it is the game that is rigged". Your ire is terribly misplaced.

[1] I worked, once, at a place that prioritised quality over development velocity. Four years of writing code for embedded devices in C, and I never once shipped a bug! _Not_ _Even_ _Once_ ... go on and guess what my bonus for that feat was? At a different place, I hacked together some spaghetti in a language I barely new, within a week, with no tests and 10% of the happy paths broken. Customer saw it, signed on, I got a nice bonus for ensuring that potential customer turned into actual customer, and some other poor shlub was given the project to move forward with the customer.

IOW, I am both the person you say you are and the person you say you dislike, and having both perspectives, vs your single perspective, makes me a lot more sympathetic to those who do an okay-not-hbad-but-not-actually-that-good job.

I hope that you, one day, can enjoy both perspectives too.

I appreciate the thorough response, and concede my communication hasn't been very clear. I have been both types as well, I thought that could be inferred from my first comment you replied to.

I think you have a Deming perspective, which I agree with, that employees work within the system which the company has created. Or more specifically, management has created, because management is responsible for the system. Where our disagreement lies is probably how much employee responsibility and output variance that actually bounds. Maybe we also disagree on how much influence non-management employees, particularly software engineers, have in inducing management to change the system, and perhaps even whether they should bother to try and what the range of likely outcomes is when people do try.

It is in those things that I think there is a lot of opportunity for alternatives an individual has to just doing the job "however", or doing the job "while just following the incentives", that don't require working overtime.

I also still see many alternatives to "however" that boil down not to increased time but just to increased thought or knowledge. Maybe you'll argue there's often no incentive for acquiring or utilizing such thought or knowledge, or maybe not if you think it's reasonable to expect competence and studiousness. But whichever, fine; still, if I already have it, well, I can use it or not. My irrelevant examples were trying to get at this. I'll try once more with something rather trivial: there is no time difference, really, in whether you return null or an empty collection from some function when there are no things. There's no time difference really when writing the calling side to do the null check before you loop vs. just going into the loop. There's no time difference really to write the arrange-act-assert unit test on this behavior, if unit testing is your thing. So do whatever, right? There's nothing in the system to incentivize either option? Regardless of what you do, you'll go home by 5, and you haven't had to rob the story of time (aka delaying it) in order to do something in a slower but correct way. I submit though that one of these options is "the correct way", and will flag it in a review if I see the wrong one done.

I didn't say anything about expecting extra things of individual employees -- management should only expect what they incentivize. Though thinking about it, I will say now that if we're to call ourselves engineers, it's reasonable to expect an engineer to have certain professional ethics and standards, something that makes them say "actually, as an economic free agent, I'll go find a different game to play." No, I don't think something like "doesn't or isn't allowed or isn't incentivized to write unit tests" rises to that level of standard, but I can see others disagreeing (some think no one should ever write in a non-statically typed language), and if they want to leave a place because of that, especially after trying and failing to spearhead a change, more power to them.

Anyway, my point was not that something like "passion" is expected, but that when it's there, it's yet another alternative way besides staying past 5 that can lead to actually getting more and/or higher quality work done. If "passion" is present, or can be incentivized somehow, I care enough to make use of it.

> When the company removes ticket-closing rates in its metrics, and replaces it with "quality" (however you define it) then you won't see "hacked together crap".

All I'll say to this is: "Were it so easy."