Hacker News Reader

Comment by hirundo | Hacker News Reader

My boss has us using a bossware SaaS app that tracks our work with exquisite detail. It's called GitHub. The tracking consists of our trail of commits to various repos. (Along with the resulting error logs and tickets.) He can see exactly what we're doing for the project and when. In fact he has a team that "peer reviews" the tracking data line by line and are not shy about pointing out deficiencies.

To track other things, like time on task or web surfing habits, would not even be redundant, just superfluous.

View on HN

People who truly think this is any useful kind of metric are probably the ones who think # lines of code written = productive work. Or, as Bill Gates put it so nicely, they are measuring the progress on the aircraft by its weight.

There's nothing as effective as a good manager.

A good manager can often sense when someone is not doing their job, or has disconnected.

In one case, a good manager came to me and asked me to check the "bossware" software to see if a certain employee was working while "working from home".

...turns out they were not. So we terminated them.

Good manager + bossware = Efficient process.

He could have been sleeping days and working nights etc. Surely you look at their actual ouput and judge from that, unless I'm missing something.

Yeah, that's good management, only detect after the problem has gotten too big, and then deal with it in the most useless way possible. Go team.

How was the manager a good manager here?

They didn't "sense" anything, they just asked you to show them some stats on a dashboard. They didn't approach the person for an explanation or conversation.

This manager totally removed the human from the person struggling with their job. That makes them a good robot.

Just to give them the benefit of the doubt, we don't know if this is the first or tenth time this employee was slacking off, or what action (if any) had already taken place to improve things.

I can additionally imagine that koheripbal was not privy to any information regarding that employee's performance besides that one thing.

Excellent way to treat people with personal problems like depression, health problems or a failing marriage. This is really an efficient society that I don't to live on.

Counting lines of code is definitely not a useful metric, however, you can extract a lot of information via the Github API that I believe can help with managing a tech team. It's exactly why I created getdevinsight.com as I think too many managers rely on bad metrics like lines of code and we can do better.

Perhaps one should look at the work being done instead of "relying on metrics"? Just a suggestion...

Easier said than done when you've a large, busy team to manage alongside lots of other work.

Besides, if you're a non-technical leader it can be difficult to understand how things are going unless you have some kind of metrics to track.

"When a measure becomes a target, it ceases to be a good measure" - Goodheart's law.

Give people a metric - any metric - and they will (conciously or otherwise) start optimizing that instead of the actual goal.

Reminds me of this store:

https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

If ones job is to break rocks, it’s hardly bossware to track how many fractures one has committed today?

This is very poetic and as amusing as it is depressing

Right. If a manager has no means of gauging the progress of those they're meant to manage, they can't do any managing, pretty much by definition.

From the article:

> Bossware typically lives on a computer or smartphone and has privileges to access data about everything that happens on that device.

It's a question of intrusiveness and granularity. Git commits are plainly not 'bossware'.

It's not wise for a manager to use git commits as their sole estimator of progress, but that's another question entirely.

Managers always have a means of gauging progress: asking the people doing the work.

True enough. I should have said it's not an unreasonable thing for a manager to look at. It's not that it would be impossible to get by without management looking at git commits, and as you indicate, it's not a substitute for communication.

Exactly. Some jobs don't produce easily trackable work product.

So the only option is to track whether they're working or not.

You can modify both the author date and the commit date on a commit if you need to. Git log is not trustworthy spying tool.

Commits should really be signed. The first time I learned of this was when a malicious update was supposedly pushed to Tesla firmware.

https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

You can even require signed commits in GitHub.

If I'm signing commits, I can sign any commit I want with any time I want, no?

If others are signing commits too, good luck changing history!

If it's already shared history it would be too late anyway - thread is about lying when you authored/committed.

Not really sure what the benefit in cheating your boss would be though? You still had to do the work at some time. Maybe you work extra hard one day but push only the first half of your commits, then give yourself a day off where all you do is check in at the end to push the fake-timed other half of them?

It'd probably be easier to find an 'unlimited holiday' job that pays you for output rather than keeping your seat warm.

I think only tags should be signed, Torvalds has a good discussion about signing commits vs signing tags at http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

While I know this is possible and have done it sometimes for fun, I would never spend any appreciable amount of time doing it at a job.

If you are at the point where you need to modify commit timestamps to satisfy some micromanager, it's highly likely that there are other things wrong with them that will lead to you searching for a new job fairly soon.

You would if you knew it was being tracked and you otherwise liked the job, you'd even automate it. Let's not kid ourselves.

* you knew it was being tracked

* you otherwise liked the job

All I was saying is that these two are very likely mutually exclusive.

Sure, it's hypothetically possible that I have a micromanage-y boss who only tracks my commit times and nothing else. But really? That's the same boss who's going to mentally think you're "not a team player" because you left an hour early for your son's birthday party. That's the same boss who's going to obsessively tracks how many vacation days you "accrued" and insist on you coming in when you're sick if you don't have any left. Let's not kid ourselves.

Every morning I rebase my local changes from the previous day and push them at roughly the same time. I suggest everyone do the same!

I might switch to doing it once a sprint :)

Why not at the end of the day in case something happens to your computer?

Sounds like my employer's problem.

...but also because I'm a weird night owl and don't like my employer to see me slacking off all day then doing work at 1am.

Doesn't the author date stay unchanged by a rebase?

You can doctor author dates pretty trivially. git commit --date=

Our workers council (Betriebsrat in german) required certain features in our internal Bitbucket to be disabled to prevent such tracking.

You disabled code reviews and commit timestamps?

I believe their attacker model is a manager who can look at statistics on a web page. Not a developer who can do git-checkout. :)

It's this interesting thing in Germany.

I'm sure I'm getting details a little wrong here, but basically if you're paying someone a certain salary to do a task, you aren't allowed to know how long it took to do it.

Microsoft Word has an example of this: The 'Total Editing time' tracking feature is disabled in Germany (and likely other countries.)

If I'm understanding this correctly from you, you mean that in the sense that if they complete the task in the time allotted, there shall be no record of specifically how much of the deadline it took up?

That seems like a decent managerial practice for some types of workplace, and it's definitely the model I have for my direct reports; but doing it by law seems like a bit of a shortcut for some reason to my anglo brain.

I -think- that's the general intent.

I also think it's an aspect that should be explored more. Sometimes people forget that the time to complete a task does not always correlate with the cognitive load of completing a task.

I've seen orgs where 'top producers' on a team slowly get loaded up more and more, eventually having 50-100% more points on a sprint than their peers on the team. They usually wind up 50-100% more drained at the end of the day too, and it winds up impacting their quality of life.

Never spent six hours to figure out a one-line fix?

Still, I'd very much write the reasoning down in the commit log. My commit logs sometimes were essay-long

I know someone who spent about three months on a 10-line fix, which was primarily a configuration tweak. As part of that process, they had to discover and describe emergent properties of an architecture that formed organically over several years from multiple teams building components that interacted with one another in non-trivial ways. They ended up getting a promotion due to that code’s incredible impact.

Reply on news.ycombinator.com