Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why do most top performers have the highest count of commits and pull requests?

swecareer.substack.com

Post reply on HN
Print view View original

111–120 of 194 posts

Re: Why do most top performers have the highest count of commits and pull requests?

#111

Post by corpMaverick »

corpMaverick wrote: post #107

For me at least. I am the most productive when I can do many SMALL commits and able to push them to prod. You have to be able to make your change; either a refactoring or a functionality change and get it through the QA, review, deploy process. Now days I spent a lot of time, dealing with multiple branches and deployment environments and my productivity is in the floor. In a previous job I was able to deploy 2 or 3 c…

Actually that seems to be one of main points of the blog post. Being able to stage their work.

Re: Why do most top performers have the highest count of commits and pull requests?

#112

Post by pizza234 »

My theory: simply put, a large number of commits (without considering excess/cheating for the sake of themselves) can indicate lots of qualities of a good software engineer: order, planning, precision and capacity of partitioning a problem in smaller units.

Re: Why do most top performers have the highest count of commits and pull requests?

#113

Post by rednum »

ericb wrote: post #84
ndepoel wrote: post #72

The 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…

> praised by management for the amount of work they produced 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…

> Don't worry about sanitizing inputs--extra effort slows you down.

I feel like many people downplay how important this is. I've wasted way too much time because of this. Doing code archeology to understand why data persisted to database many years ago breaks some seemingly unrelated feature for a customer is definitely not my favourite part of the job. Working on a validator that someone was "too busy to add" in the first place is also not fun (and a waste of time - because original author could probably do this in matter of minutes; whereas someone fixing things post-factum need to reverse engineer what is going on; check whether some funny data wasn't persisted already and potentially handle it).

To phrase my frustration in more constructive way: it's always a good idea to put explicit constraints on what you accept (What characters are allowed in text-like id - only alphanum? Only ASCII? What happens with whitespace? How long can it be?). Otherwise it's likely you will find some "implicit" constraint down the road; ie. other piece of code breaking down.

Re: Why do most top performers have the highest count of commits and pull requests?

#114

Post by emilecantin »

ndepoel wrote: post #72

The 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…

I've worked with this type of colleague. I remember a specific example where, fresh out of university, I was assigned to pair with one. We had to create a front-end validator for the password reset feature, for users stored in LDAP. I was thinking "Wow, getting the password policies from LDAP must be a pain, it'll take a while to implement that feature". Nope, just copied whatever settings were currently in LDAP into our app's config file.

A couple months later, a pair of engineers on the team had to spend 4+ weeks developing an "installer" to properly install & configure our app, as it had grown too complex to install & configure by hand. Management couldn't really figure out why...

Re: Why do most top performers have the highest count of commits and pull requests?

#115

Post by nrmitchi »

jeffreyrogers wrote: post #110

Top performers do more work (generally, not always). This is contrary to the HN conventional wisdom that lines of code are a bad metric, and I see where those people are coming from. But generally people capable of writing more code faster are also capable of writing the right code.

> Top performers do more work (generally, not always).

Yes, that is true by definition. What is not necessarily true is that all of that work involves writing code.

> generally people capable of writing more code faster are also capable of writing the right code

I disagree here though, and is highly dependent on what you consider to be "the right code". In my experience the people capable of writing more code faster are the people who don't necessarily take the step back and think "should this code even be written at all?".

Re: Why do most top performers have the highest count of commits and pull requests?

#116

Post by ryandrake »

eeZah7Ux wrote: post #87
bch wrote: post #12

Earlier quoted context omitted.

Which reminds me of this (attributed to Bill Gates): Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

> 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.

Yea, I get the point of the quote, but as someone actually building an airplane (in my garage), weight is something I'm constantly aware of and looking to minimize. It's not a measure of project progress, but it's a big factor in the final performance of the end product.

Re: Why do most top performers have the highest count of commits and pull requests?

#117

Post by ryandrake »

Mauricebranagh wrote: post #63
m_rpn wrote: post #56

I hope that someday this "version control craze" will end, this perpetual race where everybody is urging to fire PRs to up his stauts in the team, this sensation that before being a good engineer you have to know git dark arts to the core, in order to rewrite "HISTORY", and amend each misdoing as you see fit. We need to remember what is our job: writing software that makes sense, not commiting code.

"version control craze" ! Really! version control is one of the big improvements to software development I have seen. Now if we could get the rest of the customer chain to start version controlling their requirement docs and properly minuting meetings and action points

Version control is great as a productivity improvement tool and a way to organize contributions from multiple developers. It's not great when treated as a social network or productivity measuring tool. When you're firing off PRs to get your name up there again or to fill in your square on the calendar, you're kind of abusing the tool.

Re: Why do most top performers have the highest count of commits and pull requests?

#118

Post by EarthLaunch »

p5a0u9l wrote: post #100
ericb wrote: post #84

Earlier quoted context omitted.

> praised by management for the amount of work they produced 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…

the converse is also true, occasionally. depending on the business model, some engineers are too comfortable with a slow, methodical process. often, just getting something to work, despite accrued tech debt, helps a team iterate toward a better solution. if requirements or the rest of the realized architecture was perfectly understood from the beginning, then slow and methodical is the minimal risk implementation. bu…

Comments without capitalization are optimized for writing once at the expense of many readers.

Re: Why do most top performers have the highest count of commits and pull requests?

#119

Post by pydry »

lucideer wrote: post #83
pydry wrote: post #74

Earlier quoted context omitted.

Most problems are multi causal and if you have blame culture will degenerate into a litany of finger pointing.

I'm not sure what "blame culture" is, but any professional software team should ideally have some kind of "accountability culture". 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 programmer…

Blame culture is when bugs, downtime, etc. happen and people both look for somebody to blame and simultaneously look to exculpate their own behavior. It leads to CYA behavior, backstabbing and massive risk aversion. It can also lead to or be a result of a toxic work environment.

In multi causal bugs it can lead to people downplaying causes which they had something to do with and exaggerating the effect that co-worker thry don't like had something to do with. This often leads to confused attribution and poor rectification of systemic issues - e.g. writing more unit tests even when more unit tests won't really help.

"Accountability culture" sounds like it could be the same thing. Or not. I'm not really sure.

Re: Why do most top performers have the highest count of commits and pull requests?

#120

Post by pastage »

OJFord wrote: post #96
FeepingCreature wrote: post #32

Earlier quoted context omitted.

To me it's rebase > squash > merge. Nobody wants to read a commit history and see a page-long list of "fix audit", "fix typo", "retry ci", "test: change foo", "Revert: test: change foo", "Revert: Revert: retry ci"... That's why you rebase into a sequence of logical, if fictional, worksteps. But if you can't do that, squash is second-best.

My preferred is rebase (exactly as you describe) but keeping the original fork point, ( unless it becomes necessary to depend on some other later work from another branch, the original base or not) and then merge. So you end up with a cleaned-up branch history via rebase, and a master branch that's similarly clean, with a higher level view of 'logical commits' that 'merge X feature', 'merge Y bug fix'.

With rebase I keep my commits small, easier to merge then. I've seen strange things slip through large commits. E.g. Someone (me) missed the deleted files, rebased and hence recreated them.

Then I tried to squash them before merging. But if you squash your commits you get a large commit and you get the same problem. Oh well...

I guess it's easier when you have small features.

Post reply on HN