I'll be honest, I was surprised to read this sorry if environment still existed for programmers

Yes, I was already interviewing at other places when that happened.

Until I got hang of a manager and I asked what is this nonsense. He told me, he used to work as a manager in real industry and really really cannot comprehend why programmers "whine" so much about this. All his workers started the work at exact 8am so that the parts quota of the day would be achieved. I got no comment and after two weeks I just resigned...

When you let people run wild, you end up with angry people anyway as gold-brickers will always take advantage of the system. Communications and accountability break down as you can never have all parties involved in a matter in the same place or same phone call at the same time. I've worked in places where people get wacky because the guy who supposedly works 6-2 really is around from 8-1.

The key for us is communication. We make sure that each of us knows what the other is doing. Sure we have meetings every once in a while that we know we need to all meet, but for the most part we center our communication around ways to make sure that we can leave a message and they can get back to us when they can.

Also since people know the guy in your story is not working enough, it should be easy to check on him couple of times and then fire him.

If your habit is a 5 hour start window for an 8 hour workday, you're not going to work out.

now tends to only exist in mismanaged large teams

Getting "work done" is fairly easy to recognize - you can tell when bugs are getting fixed and features are being delivered and when they are not.

Getting work done to a high standard and delivered at an appropriate speed is, I think, only recognizable by another developer who is as good or better than you.

>Personally, I always try to get to the bottom of this stuff during job interviews - nobody wins if the employee assumes there will be flex-time and the company doesn't allow it!

Yeah, that's one of my red flags during interviews. Companies that are strict on this type of stuff are essentially advertising the fact that management is clueless about what development does and rely upon intrinsically meaningless social cues to build trust. Like suits.

Bob closed 20 tickets this week, and Dave is still working on that one ticket from last week. Who got most work done this week?

On the other side of things I have a guy at work who rocks out 20 tickets and a guy at work who tries to go into super plan mode and take his time and make sure every semicolon is perfect 20 times. This is ok, it's what management is for I need to make sure the fast guy is a little more careful sometimes and I need to check on mr planner and make sure he speeds it up sometimes.

To be clear, though, "Who got most work done this week?" is not a useful question.

But to answer your question, the original story should have acceptance criteria such that the ticket can't be closed if there are bugs. Failing that, the bug ticket should be linked to the original ticket.

Continual feedback is also important. If the manager who laid you off valued velocity over bug-free code, that should have been communicated way earlier.

You get an equally or more skilled developer than Bob and Dave to monitor their output and ask them that question. That's the only way.

Was that not obvious from my answer? C'mon.

Or knows that Bob is just that good. Or Dave's having a bad week because of X.

Direct superiors tend to have at least a vague idea of what is happening, along with a certain level of trust. These two make it less likely for the answer to your question to be as ambiguous. At least for ballpark estimates of whether one should be worried.

EDIT: realized after posting that multiple people made this point. Just goes to show that it should be common sense.