Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
gitreflog3368223dYeah, thats annoying. But at least it's better than having them write no tests, have no style guide compliance, and no comments.
deadPix3l1874222d@gitreflog I agree. I'm glad they do all those things, but they don't see all the hundred of lines that I write, rework and eventually remove to make this beautiful, elegant 5 line function. And then have the audacity to say things like "keep up" or "well if you contributed more, I mean just look at the differences in the graph" like commiting broken, untested code filled with "//TODO:" some how makes them more useful and dedicated.
YourNemesis3401222dSame here. I squash my commits when I feel something should be in a single commit
cjbatz1555222dWhen I was a young developer, I would ask the developers I looked up to, how many lines of code they wrote in a day... A few years later I would ask how many lines of code they eliminated.
Now I just ask to watch them work.
You can't use metrics to understand the real value of a developer.
Kristiyan177222dThis is a recurring theme where people are asking how to analyse developer performance.
I am yet to find a suggestion that accurately represents one's contribution to a project.
WildOrangutan783222dDunno, if you're commiting on some short lived feature branch, it shouldn't really matter that much, since it will get merged anyways.
I think sometimes it's just not possible to to nail everything in the first go. I'd rather commit something roughly made, than delay it until it's finished.
When I was trying to push only completed stuff, I've noticed I ended up with too much local changes.
Again, I'm talking about short lived branches.
This is my current opinion, please correct me if I live in a lie.
capcj184222dBaby steps commits have a reason: track the developer activity and help the team to learn about the workflow style of each dev, IMHO.
It's obvious that some tasks don't require a profound level of commit details, but it's better than one single commit with multiple tasks/responsabilities.
Some years from now, other devs that don't even has the actual culture of your team anymore can understand so much by one commits that I can't standing by your side in that mindset.
Yes, most of the times I think like you, I hate messed histories and stuff, but in the end it's for the best. I expect to improve in that matter soon, because my team will only grow with that.
Your Job Suck?
Take a quick quiz from Triplebyte to skip the job search hassles and jump to final interviews at hot tech firms
Get a Better Job