I'm sorry for all the negative comments you're receiving in this post. I'm sure you worked really hard on this and I know it sucks when you share something like this and all people say is negative things.
My team and I have actually been looking for something like this. Not to judge engineers productivity but to understand workload imbalances. For example, say we notice 2-3 people are doing all the PR reviews (something I think we could detect with this). Maybe the other engineers need training on PRs or we need to set expectations that everyone reviews PRs or maybe our PR load balancer isn't set up correctly.
So, good work and good luck. I'll definitely be showing this to my team. Thanks for sharing this with everyone!
Thanks a ton! If you have any feedback/needs that the app doesn't currently account for, please email me of send the feedback from directly within the app!
OP here - really appreciate all of the feedback, whether it be negative or positive!
To answer the question on use case: as an eng leader overseeing a large team or multiple teams, I would use this purely as an internal pulse-check, and that's it. Bringing these datapoints into a single place can help determine places to dig in, such as:
Are we auto-shipping PRs without diligent review/code comments?.
Are senior engineers putting enough time/effort into PR review?
Are there a subset of engineers carrying the team in terms of PR feedback?
Does a junior engineer's progress align with status updates
Are we shipping PRs in reasonable sizes? We just finished planning and are moving into build cycle, are product requirements allowing devs to start building as expected?
None of this email content is meant to be source-of-truth, but instead a signal/pulse-check.
I do agree with a lot of the feedback on worry about how this data is used — e.g. commit count != productivity. That said, a good manager is not going to mis-use this data and your poor manager is already a poor manager without it.
I really appreciate you taking the time to do this! I would love to add trend data to the email. If you are willing, can you please contact me via email (available on the website) or send me a message (via the feedback in app) so that i can get your thoughts on how to implement?
This is great for teams that subscribe 100% to devops but have an entrenched core of shitty managers that still expect a weekly summary of their work in email.
It serves no other purpose than to engineer around awful leadership.
It’s cool that you built and launched something, but if an engineering manager is ever so disconnected that they need this then I fear I would not enjoy working there.
Readit News
My team and I have actually been looking for something like this. Not to judge engineers productivity but to understand workload imbalances. For example, say we notice 2-3 people are doing all the PR reviews (something I think we could detect with this). Maybe the other engineers need training on PRs or we need to set expectations that everyone reviews PRs or maybe our PR load balancer isn't set up correctly.
So, good work and good luck. I'll definitely be showing this to my team. Thanks for sharing this with everyone!
To answer the question on use case: as an eng leader overseeing a large team or multiple teams, I would use this purely as an internal pulse-check, and that's it. Bringing these datapoints into a single place can help determine places to dig in, such as:
Are we auto-shipping PRs without diligent review/code comments?. Are senior engineers putting enough time/effort into PR review? Are there a subset of engineers carrying the team in terms of PR feedback? Does a junior engineer's progress align with status updates Are we shipping PRs in reasonable sizes? We just finished planning and are moving into build cycle, are product requirements allowing devs to start building as expected?
None of this email content is meant to be source-of-truth, but instead a signal/pulse-check.
I do agree with a lot of the feedback on worry about how this data is used — e.g. commit count != productivity. That said, a good manager is not going to mis-use this data and your poor manager is already a poor manager without it.
I tried GitInsight and wanted to share my feedback. Recorded a 5 min feedback video.
https://www.loom.com/share/0fb4b5ec2f2744ed9f1239601f43f185?...
I hope you find it useful and if you don't please disregard the video.
Congrats on launch and happy building!!
It serves no other purpose than to engineer around awful leadership.
GH itself shcould provide a BigQuery-like query interface for API events
/? "github archive" inurl:awesome site:github.com https://www.google.com/search?q=%22github+archive%22+inurl%3...