It is related to the unavoidable tech debt that any project has and only the strongest people see it and work on it.
Why do most top performers have the highest count of commits and pull requests?
81–90 of 194 posts
Re: Why do most top performers have the highest count of commits and pull requests?
#82The thing to note here is that this is a one-way correlation: top performers tend to produce lots of commits. That does not mean that people who produce a high amount of commits are the top performers in your company. I've had to deal with plenty of colleagues who moved very fast, committed extremely often, and were praised by management for the amount of work they produced. But in reality their work was rushed, slop…
If you are a trial and error type of programmer then of course speed matters a lot because it has a direct correlation on how fast you can iterate and increase your sample space of trials. The frequency of commits and PRs can be seen in the same light.
So IMO it's hard to find a true universal measure to identify the top programmers.
Re: Why do most top performers have the highest count of commits and pull requests?
#83The thing to note here is that this is a one-way correlation: top performers tend to produce lots of commits. That does not mean that people who produce a high amount of commits are the top performers in your company. I've had to deal with plenty of colleagues who moved very fast, committed extremely often, and were praised by management for the amount of work they produced. But in reality their work was rushed, slop…
Most problems are multi causal and if you have blame culture will degenerate into a litany of finger pointing.
Whatever the fallout from people feeling "blamed" may be, attrition of all of your genuine programming talent due to tech-debt-machine peers being promoted ahead of them is not exactly an ideal outcome either.
What's more, very often genuine potential in naturally talented new programmers can be stunted if they're rewarded for lazy faux "productivity". I've seen this: a programmer has a genuine interest and passion for quality, but loses it over time due to a focus on doing (different) work that gets them promoted.
Code ownership (being required to "own" ones work along with the bugs & maintenance burden that come with it) is one of the most valuable ways programmers learn. This needs to be balanced, as one runs the risk of having a bus factor of 1, but it's still vital.
Re: Why do most top performers have the highest count of commits and pull requests?
#84The thing to note here is that this is a one-way correlation: top performers tend to produce lots of commits. That does not mean that people who produce a high amount of commits are the top performers in your company. I've had to deal with plenty of colleagues who moved very fast, committed extremely often, and were praised by management for the amount of work they produced. But in reality their work was rushed, slop…
Management literally can't tell the difference, sometimes even if it is a former dev. There are many ways to ship code faster.
-Don't test
-Don't worry about sanitizing inputs--extra effort slows you down.
-Optimize for writing, not maintaining
-Take a tech-debt loan. Bolt your feature somewhere convenient it doesn't belong.
-Put on blinders. Your n+1 query problem is Tomorrow's Problem
-Avoid refactors
-Choose the first architecture you think of, not the one that is simpler, more flexible or more useful
-DRY code takes too long to write--you'd have to read more code to do that! That's bottom performer thinking!
-Securing credentials is hard. Hardcode them!
Remember, if you want to be a top performer and have breathless articles written about you, ship many commits, fast! Also, this is a virtuous circle--if any of these become "problems" you'll get to ship more commits!
Re: Why do most top performers have the highest count of commits and pull requests?
#85Earlier quoted context omitted.
I worked as a contractor with some companies and peer coded with their engineers. What I found was that its not just procrastination. Many folks are just afraid to commit code, like literally scared and I could never get a real reason for that. At one point I added some code based on the direction what requirements were taking. But I could not convince him to commit it. So we finally agreed to let it be there comment…
Commented out code is a terrible idea. It is the reason you look at source code and see it filled with garbage. When you have a developer who has no confidence in their code then you ask the usual question about requirements, testing, code review, etc. If it's still not committed then there's clearly a developer issue to workout with management. When a developer fails to follow through on their tasks and takes extra…
It was(is) a (very) huge project which is still in development (my last interaction was more than 3 years ago) being built by a very big company in tech space, and various parts of it were outsourced to various vendors (including Indian software shops) and I was consultant to one such vendor. There were huge number of layers of management, while all the usual questions you mentioned would have the answer "yes".
So yeah the devs were in general scared about the code and management both. They wouldn't ask questions, just say "yes" to everything.
Re: Why do most top performers have the highest count of commits and pull requests?
#86The thing to note here is that this is a one-way correlation: top performers tend to produce lots of commits. That does not mean that people who produce a high amount of commits are the top performers in your company. I've had to deal with plenty of colleagues who moved very fast, committed extremely often, and were praised by management for the amount of work they produced. But in reality their work was rushed, slop…
This is somewhat analogous to programmers who type very fast but delete half of what they type. This is very subjective again, most of the deletes can be legit deletes. There is a difference in the mistakes that are deleted and deletes that arise because of a thorough process change. I digress, but to a routine observer the person typing fast appears like a pro, someone who is really good at their job. While this can…
I think you overstate speed in carpentry, though: you can’t just backspace or amend a commit to fix your mistakes.
Great carpenters are smooth and purposeful — they can do an entire wall without breaking rhythm with a mistake. That’s where the real speed comes from: ever tried to backspace a joint you built wrong?
That can take days.
I would say that much the same is true of software - it’s more important to be purposeful and accurate than fast, because re-doing work adds a lot of cost.
If you turn in work 1.33 times as fast, but have to do it twice... you actually work 0.66 as fast.
Re: Why do most top performers have the highest count of commits and pull requests?
#87Earlier quoted context omitted.
Which reminds me of this story: https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
Which reminds me of this (attributed to Bill Gates): Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
...which is a very misleading comparison. Measuring the build by weight is a rough but not terrible metric, and it applies to cars as well.
It also implies that there's such thing as reaching 100%, which is very wrong for software: most poorly written software uses 10x or 100x SLOC than what is required.
Re: Why do most top performers have the highest count of commits and pull requests?
#88Earlier quoted context omitted.
That sounds miserable. I think, as a reviewer, it's important to keep in mind that most problems have many solutions. You have to be flexible and work with the person that did the hard work of implementing it. Everyone messes up and lets a bug slip through every now and then. That's what multiple layers of thorough testing is for. On my current team, I'm considered to be the most thorough code reviewer. Folk usually…
Also, it helps a lot to hammer out a lot of design and implementation details before writing any code. For any work project I start that I anticipate taking more than a few hours to code, I spend an hour or so writing an "architecture document" which I then distribute to anyone I think will have an opinion about it. That gives folk a place to ask questions and "bike shed" the problem long before I've invested any "ar…
Would you be willing to share this slide deck?
My question in regard to this is how do you write an architectural doc if you're exploring the problem space? If it takes 5h to explore, experiment and find the solution. And it takes 0.5h to write the doc. And 0.5h to make the change after you know the solution and have reverted the experimental/exploratory changes?
At that point is the doc necessary as a precursor to the change. By that I mean, do you send it out for feedback first and wait OR do you send it out/add that as a comment on you PR and push up the final change?
Additionally how do you know you're going to get feedback at all from sending out the doc? In my experience people are always busy with their own work and sending them a big chunk of text...well I wouldn't expect a response quickly compared to a short 1-2 line question
Re: Why do most top performers have the highest count of commits and pull requests?
#89I've worked on teams where I had colleagues who were incredibly deliberative. They would spend lots of time working with stakeholders to deeply understand their problems, and then produce elegant solutions that made their jobs drastically easier. Small changes with huge payoff. But management, and even most other team members, didn't recognize this. They just saw a slow programmer. Credit tended to go almost exclusively to other teams, when their members started using those tools to radically improve their own processes. The company's dev org largely didn't care about that effect, because it didn't positively influence their own KPIs.