New to WIP?

We're a group of makers shipping together. We help each other stay accountable and reach our goals.

Apply for access
Topics
📊 Analytics 👨‍💻 Developers 🌱 Personal Development
Other questions
🤔 What do you do for marketing? Be the first to reply
🎨 Freelance designers. When and how. 2 answers
What steps are included in your CI pipeline you should have added sooner? 11 answers
AI to work with a lot of data (two usecases) 8 answers
Back
 Question
Asked

Do you use any kind of code / developer analytics?

I like to keep track of my speed around developing and merging PRs, time-to-release, time-to-fix etc. Does anyone else care about this at all? It's relevant to larger teams, but perhaps not a "thing" for bootstrappers?

I'm curious if anyone has any tools they like for this, or if it's not even a consideration?

Dave Metrics
@davemetrics

👋 Join WIP to participate

You could use GitCred that I am about to release. Our version 2 will come with a GitHub App.

 Reply
Dave Metrics
@davemetrics

Sounds interesting - give me a shout if you want a beta tester.

 Reply
Matt Carey
@mattzcarey

We do alot of work in AWS CDK. We have custom constructs which track errors and time in between deployments.

Reply
Dave Metrics
@davemetrics

Interesting - does that provide any kind of DORA stats?

 Reply

I have never thought about it and I can't say it would be as useful to me. I project-hop all the time and try to get a few things done on a few projects.

My release cycles are automated so my time-to-release is ~2 to 5 minutes from when I git push to any of my projects to when tests run and then code is deployed (I prefer containers for the ease of promoting/demoting images in production.) This feels healthy/good enough.

My time-to-fix is tied to how quickly I notice an issue or someone reports it to me.

I PR bigger features, but I don't fear developing on main for my solo projects because I have tests running before code is deployed. This saves me time and frustration.

For clients and bigger teams, I PR every time and have different considerations, but it's not the end of the world if I need to fall back on a previous version for a bit while I fix something. 90% of the time, my changes are small and iterative enough that there's not much to have to worry about breaking.

Reply
Dave Metrics
@davemetrics

Good insights - thanks! I agree if you have a solid test suite you don't really need to worry about working directly on main. I think I'm probably in a similar boat to you - PR bigger features, and do small updates directly on main.

Would you care at all how your progress compares to other projects, in terms of time-to-release / failure rates etc, if that info were available?

 Reply