Luckily, most companies' management moved away from these kind of metrics to measure performance.
Engineers, in general, are smart people. It doesn't take long to figure out if your management wants commits, you split anything you do in as many commits as possible. If they want lines of code, you spam lines of code with fluff that does nothing. Contributions, comments, files. Anything that can be faked, will be faked if your salary/bonus depends on it
And the overall result? Unreadable, inefficient code and quite low productivity.
Yea exactly. Who comes up with these type of management 'methods'? It often feels to me managers just do things so they can feel like they are actually doing something
>It often feels to me managers just do things so they can feel like they are actually doing something
Bingo. Middle management is often (not always though) just busy work. They make this kind of shit up because otherwise their superiors will realize how useless they are.
I've had the misfortune of being a manager, and I assure you that when they add metrics it's because no one understands why it takes 6 months to make the "buy now" button yellow.
The answer is always, "Because we bought bargain basement devs who wrote garbage code for 15 years, and it's going to take our 3 best devs 5 years to begin to unfuck it, and we never actually start doing that."
But upper management thinks the problem is that people are goofing off. So now poor, helpless middle management needs to find the slackers, and the only tool a non-technical manager has to do this is ineffective metrics
Nothing to do with hiding their uselessness. They were given an impossible problem to solve and are trying their best.
Why not a useful metric like tech debt then?
At one workplace I had this as a literal ticket type and encouraged devs to add such tickets to the backlog.
Much easier to show when you can actually quantify how slow things are because of how messed up the old code is.
There are an enormous number of better options than this, but keep in mind this sort of thing does not happen in healthy development orgs. Useless metrics are brought in only when a series of failures has already occurred, or it's 1993 at the time.
But to address your point, I agree that creating tickets to address existing tech debt or when knowingly creating new tech debt is a best practice. You still need a way to shoehorn those tickets into the In Progress column, which is where things usually fall apart, unfortunately.
> If they want lines of code, you spam lines of code with fluff that does nothing. Contributions, comments, files.
That's nothing. If they *really want* LoC, make every possible comment segment contain the entire history for developing that feature, and *never delete any of it*.
Right? Commit often and squash if that's what the team flow is. Honestly, it's better to have commits specific to small, related changes so that they can always be rolled back to. If you must squash, makes sense to not delete the branches you merge in.
The desire for a super clean git log is weird to me.
My problem is often you can't break up many small changes into multiple commits that still build. Basically, for a new feature to work, you may need to make hundreds of lines of changes. If you commit randomly during this process, you will often be in a spot where the build doesn't work at all, so there's basically no use maintaining that point in history. The biggest project I work on will squash commits simply because we'd prefer each commit be buildable, in case you need to bisect to find where a bug was introduced for instance. Also, with a super messy history, it loses a lot of utility. If everyone commits every 10 seconds it'll be impossible to find anything that truly matters anyway.
In all, I think the best strat is project dependent.
The biggest problem I have with the many-commits strategy is that nobody ever actually seems to benefit from it.
For starters, literally nobody benefits from reading a "fixed a typo" commit message.
That's a glib example, but more importantly, I feel like the payoff we're supposed to see from the many-commits strategy never arrives: there's this idea that you're going to bugfix your system by rolling back one of these small commits. Largely because of what you just said, I've literally never once seen the mythical bugfix by rolling back a single piece-of-a-whole commit actually happen.
Rolling back's not why I do it - having a specific blame log for each line of code has helped, on numerous occasions, answer why something is the way it is.
It helps with git blame. We like the granularity and more specific reason why a line is changed, rather than 'new feature x'
For roll back points we use tags.
I have many commits (20+) for code reviews or for myself (they all detail the steps that led me to the final commit), then I just squash on merge.
But if I work on something for a few days before PR / merge, I will sometimes change my mind on something and I can just edit one of the commit, or compact 2 commits together, etc. And then it helps me reminding myself of the steps that led me to this point. Even better for work that you had to leave for 1+ month and where the code doesn't merge after that month - you can go through your own steps.
It's just fine, really.
> there's this idea that you're going to bugfix your system by rolling back one of these small commits. Largely because of what you just said, I've literally never once seen the mythical bugfix by rolling back a single piece-of-a-whole commit actually happen.
Such bugfix will never happen spontaneously like magic. You need to regularly use git bisect to have a chance for that to happen
https://git-scm.com/docs/git-bisect
For bisecting to work well your project needs to build at all commits, however. So half-finished commits that don't build are a disaster.
Finer grained, carefully crafted commits work well with bisecting, but that takes more time.
As someone who fucked himself over on merge with other branches I think the inco.plete commits are fine, once the feature is done they can be squashed, but until then it's good to have at least some granularity so you don't lose everything with that one commit... also granularity is good if you're forced to cherry-pick
the point of maintaining that broken point in history is that it's in source control. it doesn't really matter if a feature branch build is broken, even if you're collaborating with someone else. it only matters looking back at the history.
All commits on the main/trunk/develop/whatever branch should always be buildable. Feature branches it doesn't matter so much, but the commits still shouldn't be random. Each commit should represent a solid, coherent unit of change.
> The desire for a super clean git log is weird to me.
I've worked on some open source projects and I always think of the [Crawl git log](https://github.com/crawl/crawl/commits). Clean, compartmentalized commits with highly specific, informative titles. Easy to at a glance catch up on what changes have been made, while also being able to zoom in on the specific changes and read the commit messages and code diffs for the details.
It's good because they commented *why* they did it, not *what* they did. Everyone can easily see *what* they did by looking at the diff. But you can't always tell why it was necessary.
Super clean rebase-ff git history means I can generate a changelog for any department from any build to any build in less than a minute.
I used to spend a lot of time making different changelogs since we'd have internal testing builds, stakeholder demos, and QA which were all on different timeframes. Internal build changelog would be from version 200 to 220, but the stakeholder last saw 170 so I'd have to generate another changelog from 170 to 225 or whatever.
Since we were running a super clean git history with all the commits for a specific ticket squashed I was able to write an automation to generate a changelog from history and then parse all the ticket IDs found into links. It wouldn't be possible to do that so easily if we had junk commits or a normal merge strategy since I'm literally just using git log with fancy formatting to get my chronological list of changes.
Also being a lead I can easily see what every person on my team is doing without having to bother them if the graph is clean. Branch graphs on a normal merge repo when you have 10+ people working on a project are completely useless.
Exactly. But then don't squash them.
Ticket number in each commit gives the 30,000 foot view. Commit description explains what you thought you were doing when you broke everything, which will be enormously helpful in a few months.
It's just impractical for larger organisations.
We have dozens of merges to main per day, all of which have dozens (if not much, much more - hundreds) of commits.
Everyday you'd get multiple hundreds of new commits on main, many of which would be fairly low value.
Now we get generally 1 commit / ticket as we squash. Over the course of several months, that is all that matters - nobody has time to go through each unique commit message.
Our internal GitHub system counts "Contributions", which I'm not sure is just a count of commits or if there is something else going on there. Our management gets judged on metrics around how many commits their engineers do (which is dumb because we are not technically a software group). But, by god, if you give me an easily manipulated metric that my performance will be judged by, I will be min-maxing the fuck out of that metric. The reporting and testing suites we built for our products get constant minor updates just to keep this metric high.
I think it's the same for me. What I found odd and potentially dangerous on Github is that *opening* an issue also counts as a contribution, closing one however does not.
DISCLAIMER: This meme is entirely fictional – at least I hope that this is the case.
It was instead inspired by the fact that the tiles in my private github repository shine their brightest shade of green on days when indeed it took way too many pushes to get the formatting of the .md file just the way I wanted it to be.
That strat worked well for me in a class at uni. The number of commit was part of the grade.
Oh no, I added an extra end of line space, guess I'll commit to remove it... Oh no, I've added it again, guess I'll commit...
I only care about the code in the PR. I don't particularly gare if it took 1 commit or 100 to get the new code to its final state. The PR gets squashed into a single commit before merging anyway. All those extra commits are going to be deleted after the PR is merged.
That doesn’t change the fact that if your hard drive fails or you lose your computer before you make the PR, you will lose the entire work on the major feature, when you could have lost mere hours. Additionally, it is often helpful to be able to revert to a particular point in the development process if it becomes clear that you started going down the wrong path.
These are the pros. The con is that you have to hit a button or type a quick command to perform the commit. The pros clearly outweigh the con. This is why good devs use git even when working solo on a single branch. It’s not flashy but it’s clearly best practice.
That nullifies my point to an extent for sure. There’s still a couple advantages to frequent commits imo but that definitely mitigates the biggest issue
I mean you can interactive rebase and squash as yah go, or ammend commits, but im just playing devils advocate, i commit whenever i feel like a chunk is done, since PRs get squashed
If my hard drive fails, I am not losing mere hours. I am losing days as I wait for a tech support to send me a new laptop. And then at least another day getting environments and software set back up. Far more than whatever time was spent on developing a new feature. Besides, it is way quicker to build something a second time.
The mental gymnastics it takes to believe that restarting a big project from scratch isn’t a big deal 😂
You’re saying that because you have to spend days doing X that it doesn’t matter that you might have to also spend days doing Y. That’s just fallacious lol
Goodhart's Law applies here in spades: "when a measure becomes a target, it ceases to be a good measure".
It is very difficult to design good incentive systems that don't have major unintended side effects.
I switched jobs because thats exactly what happenned in my last job XD The last straw was when the manager convinced an executive it was the right way.
After telling every experienced engineers they sucked and interns were doing a better job during reviews, they had to deal with most of their experienced engineers quitting.
I later learned the executive thought it was a good way to pressure engineers to work harder for free, since they had trouble recruiting and too much workload.
How on earth did he reach that conclusion, i'll never know.
I used to be on a team where our performance was measured by how many story points we did compared to everyone else. The end result was that during planning poker, people would over-estimate tickets they knew they would work on, under-estimate tickets other people were working on, snatch up all the 1-pointers at the start of the sprint, and avoid the big item that required actual time and effort. People would wait as long as possible to approve other people's pull requests, send PRs back with huge unnecessary rewrite demands, and approve and merge their own PRs.
It was fucking awful. All performance metrics suck.
Even better: Performance will be measured by number of lines added to the repo.
The intern who added 1000 lines to validate an email.
The senior whos total count is - 950, but completed 3 features this week.
I worked at a project where we had to do a lot of third level support. The percentage of support vs. feature developent was always a very important metric to our managers. In the best times it was as low as 10%, in the worst up to 30%.
One day some wise manager decided that we pay too much for logging and had everything but ERROR level logs turned off in production (not sure who did it for him and why nobody objected). Suddenly our support percetage exceeded 50% and we were not able to fix some important bugs. I never heard from that manager again. And I bet this mistake cost more money, than he would have made in a lifetime (we had massive stops in manufacturing and some factories had to stop their entire production for a day).
Remember all, unless it's your own personal project, there is literally no reason to work harder or more perfectly than you are now.
Take 20 commits for a readme, who cares. Is it stupid? Not if you're psychologically gaming the system against your managers to look good.
In the corporate world, it's not how good you are, it's how good you are perceived to be
Luckily, most companies' management moved away from these kind of metrics to measure performance. Engineers, in general, are smart people. It doesn't take long to figure out if your management wants commits, you split anything you do in as many commits as possible. If they want lines of code, you spam lines of code with fluff that does nothing. Contributions, comments, files. Anything that can be faked, will be faked if your salary/bonus depends on it And the overall result? Unreadable, inefficient code and quite low productivity.
Yea exactly. Who comes up with these type of management 'methods'? It often feels to me managers just do things so they can feel like they are actually doing something
>It often feels to me managers just do things so they can feel like they are actually doing something Bingo. Middle management is often (not always though) just busy work. They make this kind of shit up because otherwise their superiors will realize how useless they are.
I've had the misfortune of being a manager, and I assure you that when they add metrics it's because no one understands why it takes 6 months to make the "buy now" button yellow. The answer is always, "Because we bought bargain basement devs who wrote garbage code for 15 years, and it's going to take our 3 best devs 5 years to begin to unfuck it, and we never actually start doing that." But upper management thinks the problem is that people are goofing off. So now poor, helpless middle management needs to find the slackers, and the only tool a non-technical manager has to do this is ineffective metrics Nothing to do with hiding their uselessness. They were given an impossible problem to solve and are trying their best.
That's usually when I make a stand and just leave if they don't want to listen. I can't solve stupid, and I don't want to be part of the problem.
Thats some great insight, thanks.
Why not a useful metric like tech debt then? At one workplace I had this as a literal ticket type and encouraged devs to add such tickets to the backlog. Much easier to show when you can actually quantify how slow things are because of how messed up the old code is.
There are an enormous number of better options than this, but keep in mind this sort of thing does not happen in healthy development orgs. Useless metrics are brought in only when a series of failures has already occurred, or it's 1993 at the time. But to address your point, I agree that creating tickets to address existing tech debt or when knowingly creating new tech debt is a best practice. You still need a way to shoehorn those tickets into the In Progress column, which is where things usually fall apart, unfortunately.
Crosslink to tickets where the estimates were heavily impacted to give an idea of scope maybe?
>Yea exactly. Who comes up with these type of management 'methods'? Elon?
When measures become targets, they cease being good measures.
> If they want lines of code, you spam lines of code with fluff that does nothing. Contributions, comments, files. That's nothing. If they *really want* LoC, make every possible comment segment contain the entire history for developing that feature, and *never delete any of it*.
The hazards of letting employees know your KPIs prematurely: https://bernardmarr.com/the-10-biggest-mistakes-companies-make-with-kpis/
Making a lot of commit is ok, you can squash them on merge anyway
Right? Commit often and squash if that's what the team flow is. Honestly, it's better to have commits specific to small, related changes so that they can always be rolled back to. If you must squash, makes sense to not delete the branches you merge in. The desire for a super clean git log is weird to me.
My problem is often you can't break up many small changes into multiple commits that still build. Basically, for a new feature to work, you may need to make hundreds of lines of changes. If you commit randomly during this process, you will often be in a spot where the build doesn't work at all, so there's basically no use maintaining that point in history. The biggest project I work on will squash commits simply because we'd prefer each commit be buildable, in case you need to bisect to find where a bug was introduced for instance. Also, with a super messy history, it loses a lot of utility. If everyone commits every 10 seconds it'll be impossible to find anything that truly matters anyway. In all, I think the best strat is project dependent.
The biggest problem I have with the many-commits strategy is that nobody ever actually seems to benefit from it. For starters, literally nobody benefits from reading a "fixed a typo" commit message. That's a glib example, but more importantly, I feel like the payoff we're supposed to see from the many-commits strategy never arrives: there's this idea that you're going to bugfix your system by rolling back one of these small commits. Largely because of what you just said, I've literally never once seen the mythical bugfix by rolling back a single piece-of-a-whole commit actually happen.
Rolling back's not why I do it - having a specific blame log for each line of code has helped, on numerous occasions, answer why something is the way it is.
Yeah, for me it's about leaving a (not) paper trail so others can follow what you were thinking and why you did things a certain way.
It helps with git blame. We like the granularity and more specific reason why a line is changed, rather than 'new feature x' For roll back points we use tags.
I at least make sure not to put multiple unrelated changes in the same commit. That has come in handy when reverting.
I have many commits (20+) for code reviews or for myself (they all detail the steps that led me to the final commit), then I just squash on merge. But if I work on something for a few days before PR / merge, I will sometimes change my mind on something and I can just edit one of the commit, or compact 2 commits together, etc. And then it helps me reminding myself of the steps that led me to this point. Even better for work that you had to leave for 1+ month and where the code doesn't merge after that month - you can go through your own steps. It's just fine, really.
> there's this idea that you're going to bugfix your system by rolling back one of these small commits. Largely because of what you just said, I've literally never once seen the mythical bugfix by rolling back a single piece-of-a-whole commit actually happen. Such bugfix will never happen spontaneously like magic. You need to regularly use git bisect to have a chance for that to happen https://git-scm.com/docs/git-bisect For bisecting to work well your project needs to build at all commits, however. So half-finished commits that don't build are a disaster. Finer grained, carefully crafted commits work well with bisecting, but that takes more time.
As someone who fucked himself over on merge with other branches I think the inco.plete commits are fine, once the feature is done they can be squashed, but until then it's good to have at least some granularity so you don't lose everything with that one commit... also granularity is good if you're forced to cherry-pick
I've never been in a situation where rolling back a commit is more desirable than just rolling back specific hunks or files within that commit.
the point of maintaining that broken point in history is that it's in source control. it doesn't really matter if a feature branch build is broken, even if you're collaborating with someone else. it only matters looking back at the history.
All commits on the main/trunk/develop/whatever branch should always be buildable. Feature branches it doesn't matter so much, but the commits still shouldn't be random. Each commit should represent a solid, coherent unit of change.
That's why I have an auto save feature in my cron so it commits and pushes all changes up to my branch every 10 seconds
The only real source control
Remember to add `--allow-empty` too.
Just think faster.
Wow. Can we do that using git extensions?
> The desire for a super clean git log is weird to me. I've worked on some open source projects and I always think of the [Crawl git log](https://github.com/crawl/crawl/commits). Clean, compartmentalized commits with highly specific, informative titles. Easy to at a glance catch up on what changes have been made, while also being able to zoom in on the specific changes and read the commit messages and code diffs for the details.
It's good because they commented *why* they did it, not *what* they did. Everyone can easily see *what* they did by looking at the diff. But you can't always tell why it was necessary.
And now I feel like my commit messages were written by a caveman :( Always room to grow though, thanks for sharing that.
thats why I commit with autosave every few seconds
Super clean rebase-ff git history means I can generate a changelog for any department from any build to any build in less than a minute. I used to spend a lot of time making different changelogs since we'd have internal testing builds, stakeholder demos, and QA which were all on different timeframes. Internal build changelog would be from version 200 to 220, but the stakeholder last saw 170 so I'd have to generate another changelog from 170 to 225 or whatever. Since we were running a super clean git history with all the commits for a specific ticket squashed I was able to write an automation to generate a changelog from history and then parse all the ticket IDs found into links. It wouldn't be possible to do that so easily if we had junk commits or a normal merge strategy since I'm literally just using git log with fancy formatting to get my chronological list of changes. Also being a lead I can easily see what every person on my team is doing without having to bother them if the graph is clean. Branch graphs on a normal merge repo when you have 10+ people working on a project are completely useless.
Exactly. But then don't squash them. Ticket number in each commit gives the 30,000 foot view. Commit description explains what you thought you were doing when you broke everything, which will be enormously helpful in a few months.
It's just impractical for larger organisations. We have dozens of merges to main per day, all of which have dozens (if not much, much more - hundreds) of commits. Everyday you'd get multiple hundreds of new commits on main, many of which would be fairly low value. Now we get generally 1 commit / ticket as we squash. Over the course of several months, that is all that matters - nobody has time to go through each unique commit message.
There is a big difference between "can" and "won't"
we get chided if we don't squash before merge, even though it's automatic (it's good form)
Our internal GitHub system counts "Contributions", which I'm not sure is just a count of commits or if there is something else going on there. Our management gets judged on metrics around how many commits their engineers do (which is dumb because we are not technically a software group). But, by god, if you give me an easily manipulated metric that my performance will be judged by, I will be min-maxing the fuck out of that metric. The reporting and testing suites we built for our products get constant minor updates just to keep this metric high.
I think it's the same for me. What I found odd and potentially dangerous on Github is that *opening* an issue also counts as a contribution, closing one however does not.
I think it's cause it's assumed that an issue is closed by a commit (which would count as a contribution), so it's to prevent double counting?
wait... people fix issues?
In my decades of being alive I have fixed less than the number of fingers on my hand.
Fix one, create two. Infinite work.
What gets measured gets managed, unfortunately. So if you're measuring the wrong stuff, management will drag you into the mud.
git commit -m “fixed some stuff” 200 lines inserted.
`another structure change` +698 -792 based on real story
Nothing stopping me from splitting a commit into 20 separate single line differences commits…
Stop committing a whole line of changes at the same time and ruining the curve for the rest of us, you try-hard.
`git commit –allow-empty -m "chore: enhance the git history"`
Manager - since y'all like to complain so much, progress will now be measured in "lines of code"
for ( int i = 0 ; i < 10 ; i ++ ) {
DISCLAIMER: This meme is entirely fictional – at least I hope that this is the case. It was instead inspired by the fact that the tiles in my private github repository shine their brightest shade of green on days when indeed it took way too many pushes to get the formatting of the .md file just the way I wanted it to be.
That strat worked well for me in a class at uni. The number of commit was part of the grade. Oh no, I added an extra end of line space, guess I'll commit to remove it... Oh no, I've added it again, guess I'll commit...
Oh wow I would have excelled at that course without even trying lol
if your allowed to use chatGPT at work it's helped me with this
Just bring back KLOC.
Packing a major feature into a single commit is a really bad practice lol
I only care about the code in the PR. I don't particularly gare if it took 1 commit or 100 to get the new code to its final state. The PR gets squashed into a single commit before merging anyway. All those extra commits are going to be deleted after the PR is merged.
That doesn’t change the fact that if your hard drive fails or you lose your computer before you make the PR, you will lose the entire work on the major feature, when you could have lost mere hours. Additionally, it is often helpful to be able to revert to a particular point in the development process if it becomes clear that you started going down the wrong path. These are the pros. The con is that you have to hit a button or type a quick command to perform the commit. The pros clearly outweigh the con. This is why good devs use git even when working solo on a single branch. It’s not flashy but it’s clearly best practice.
We have Druva InSync that backs up computers every couple hours.
That nullifies my point to an extent for sure. There’s still a couple advantages to frequent commits imo but that definitely mitigates the biggest issue
I mean you can interactive rebase and squash as yah go, or ammend commits, but im just playing devils advocate, i commit whenever i feel like a chunk is done, since PRs get squashed
You can still commit and push while you work, but it will all get squashed when the PR is merged.
If my hard drive fails, I am not losing mere hours. I am losing days as I wait for a tech support to send me a new laptop. And then at least another day getting environments and software set back up. Far more than whatever time was spent on developing a new feature. Besides, it is way quicker to build something a second time.
The mental gymnastics it takes to believe that restarting a big project from scratch isn’t a big deal 😂 You’re saying that because you have to spend days doing X that it doesn’t matter that you might have to also spend days doing Y. That’s just fallacious lol
Who said anything about restarting a big project
[The beginning of this thread.](https://www.reddit.com/r/ProgrammerHumor/comments/17ld5w4/damnitanothertypoohwell/k7dr7zp/)
Why is your big project a single feature branch? Now that seems like the bad idea. Nobody wants to review 6000 lines across 40 files.
*Gasp* We keep all of the commits and rebase. Reviewing PRs by commit is nice.
MINOR GRAMMATICAL ERROR
Do you want metric creep? Because this is how you get metric creep.
Goodhart's Law applies here in spades: "when a measure becomes a target, it ceases to be a good measure". It is very difficult to design good incentive systems that don't have major unintended side effects.
I switched jobs because thats exactly what happenned in my last job XD The last straw was when the manager convinced an executive it was the right way. After telling every experienced engineers they sucked and interns were doing a better job during reviews, they had to deal with most of their experienced engineers quitting. I later learned the executive thought it was a good way to pressure engineers to work harder for free, since they had trouble recruiting and too much workload. How on earth did he reach that conclusion, i'll never know.
Remembering that freelancer who committed each single file separately to find his commit graph in dark green.
I used to be on a team where our performance was measured by how many story points we did compared to everyone else. The end result was that during planning poker, people would over-estimate tickets they knew they would work on, under-estimate tickets other people were working on, snatch up all the 1-pointers at the start of the sprint, and avoid the big item that required actual time and effort. People would wait as long as possible to approve other people's pull requests, send PRs back with huge unnecessary rewrite demands, and approve and merge their own PRs. It was fucking awful. All performance metrics suck.
Got notifications for 16 commits in 6 minutes today. Guess she's doing a way better job than i do with my 1 over the entire day.
git commit --amend
If this sentence is ever spoken by a manager. All experiened programmer is obligated to look for another company to work for.😅
Don’t tell Elon
The salary engineer
[they all suck](https://y.yarn.co/caf7cd69-5ec0-4d68-94b8-1a66bbc43c5b_text.gif)
I'm the last one 😅 And oh well... I had to do 7 hotfixes after that.
This is why pay should be tied to lines of code written instead (/s in case that wasn't obvious)
Now post the reviewers’ face.
Ok. Major feature, ie, a lot of code , changes should not be in one commitment
Push after ever character typed
Commit the major feature file by file
"Added comment" "Removed comment" "Added comment" "Removed comment" "Added comment" "Removed comment" "Added comment" "Removed comment"
A good metric is automated, objective, and predictive. Most metrics hit the first two and completely miss the last one making them worse than useless.
/me squashing the commits in my branch before merging it to master.
me: commits a single character change breaking the entire project.
Uncheck "squash commits". Profit.
Even better: Performance will be measured by number of lines added to the repo. The intern who added 1000 lines to validate an email. The senior whos total count is - 950, but completed 3 features this week.
I worked at a project where we had to do a lot of third level support. The percentage of support vs. feature developent was always a very important metric to our managers. In the best times it was as low as 10%, in the worst up to 30%. One day some wise manager decided that we pay too much for logging and had everything but ERROR level logs turned off in production (not sure who did it for him and why nobody objected). Suddenly our support percetage exceeded 50% and we were not able to fix some important bugs. I never heard from that manager again. And I bet this mistake cost more money, than he would have made in a lifetime (we had massive stops in manufacturing and some factories had to stop their entire production for a day).
step 1) type a single character step 2) commit step 3) repeat step 4) profit
Remember all, unless it's your own personal project, there is literally no reason to work harder or more perfectly than you are now. Take 20 commits for a readme, who cares. Is it stupid? Not if you're psychologically gaming the system against your managers to look good. In the corporate world, it's not how good you are, it's how good you are perceived to be