Commit Times and Work Culture
posted 27 Sep 2015
Lately, I have been interested in the times I commit stuff. It is mostly out of curiosity, but I also wanted to verify my feeling that I work overtime very seldom. I try to be rather strict about working 8 hours a day, and if I have to work 1-2 hours more than usual, I usually deduct it from the next workday or the day after that.
I started out using git-punchcard to visualise my commit patterns, but found
that it was not sufficient as I’m working on multiple projects at work. In
addition, I knew my work schedule was very sporadic when I worked as a student,
so I wanted to filter out old commits; they were not representative of how I
work at the moment. Therefore, I forked the project, modified it slightly, and
named it git-multipunchcard: You can pass it whatever arguments you want,
and it will crawl every immediate subdirectory in the current work directory,
git log, fetch the results and make an aggregate punchcard out of it.
Making aggregated punchcards turned out to be easy with the multipunchcard program. Make a new directory, clone all the work projects that you have, and filter by author and date like so:
mkdir -p aggregation cd aggregation for p in $projects; do git clone $p; done git multipunchcard file=jn.png -- \ --all --after="1 year ago" --author="firstname.lastname@example.org"
For me, the results were rather pleasing and verified what I thought:
I usually “clock in” around 9 am and start out with a little chat with coworkers about what needs to be done. I then do my research on those things or use that time to get back into the problem I worked on last day. I assume this is why I don’t commit as often between 9-10 am.
It’s not a surprise I don’t commit as often around 12 pm: We tend to eat lunch around noon, and I usually do more discussions with coworkers after that.
I usually wrap up and commit most of my work some hours before I leave, perhaps rebase a little to make the commit history readable, then fix edge cases or document the work I’ve done after that.
At Mondays or Tuesdays, I have some commits around 6 pm too. Not coincidentally, this is when we deploy from dev to staging, so presumably, we’ve had some issues those days we needed to fix on the spot.
While I have used it for making my own punchcard, a punchcard generator like this may be valuable for conducting due diligence on companies. If a company you want to interview for has any open source projects, or you get access to some of their projects during the interview session, you can run the punchcard code on those as well. Just make sure to filter the authors to people inside the company – people doing pull request are likely to do it in their spare time.
What an “optimal” punchard should look like is obviously highly subjective, but at least I can give you my thoughts on what a closed-source punchcard should not look like1:
Long hours just doesn’t work, and I’d recommend you to stay away from companies that try to make you do just that.
It’s also worth noting that company culture might change, so ensure to limit the logs to a sensible timeframe – last 6-12 months should generally be fine, as long there hasn’t been any major organisational changes in that timeframe.
Don’t Read Too Much Into It
Although git commit timestamps are a good indicator, they don’t tell the whole story. git-multipunchcard only shows you a punchcard of commit times. If a company has flexitime, it might look like workers work more than 8 hours per day, when in fact it’s possible they start working at different times in different weeks.
So while a punchcard like this doesn’t provide you with super good insights, it can give you some hints on what is going on. If people are committing in code on Saturdays and Sundays or frequently after 7-8 pm, alarms should go off in your head. But what may seem like a 10-hour schedule is not necessarily the norm or a trend within the company, although it is worth looking further into.
The converse is true as well: If the commit schedule implies 8 hour days, then that may not necessarily mean the workday is 8 hours long. If the company has a 1-hour meeting at the beginning of every workday, or frequently end days with meetings, then you have to account for that as well.
But at least do a little research so you know what kind of time schedule you will have when you accept an offer. Although an employment contract should include hours of work, actual work schedules usually tend to be slightly different.
This was “randomly” generated by picking some unrelated open source git projects. ↩