Why do most top performers have the highest count of commits and pull requests? • Hacker News Board

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

#161

Post by gfxgirl » Mon, Dec 07, 2020, 7:18 PM UTC

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…

This used to drive me nuts and I feel like I wish the rule was, if your code breaks something you are not allowed to work on anything else until it's fixed and if possible it will be reverted.

There needs to be some incentive to not let people shit all over the code based for everyone else to clean up. Reviews are enough. All code was required to be reviewed by owners and there was still lots of this.

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

#162

Post by rodw » Mon, Dec 07, 2020, 7:19 PM UTC

JoeAltmaier wrote: post #145

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…

In my experience, its the sloppy Engineers that create problems that get the most credit. They are called upon to be 'heros' again and again, to fix their crap they shipped with 1000 issues.

Yes, I've seen that a few times. What non-technical management sees is an engineer at the center of efforts to fix an issue in the midst of a crisis. What they don't see is that the work done by competent engineers doesn't blow up and become a visible crisis.

IMO this is a big red flag that something is wrong with both the technical and non-technical culture. Technical management isn't happening, at least not effectively, and non-technical management is getting too far into the weeds on technical details of production issues.

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

#163

Post by sgtnoodle » Mon, Dec 07, 2020, 7:41 PM UTC

justanotherguy0 wrote: post #73

sgtnoodle wrote: post #54

Earlier quoted context omitted.

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…

Is that slide deck publicly available?

Nah, but here's the content. You'll have to add your own clip art hastily pulled from google image search:

---

What’s the point?

Architecture documents are for you, not for everyone else

* Adds structure to chaos * Makes feedback progressive rather than regressive * You get to tell people to “Read The Friendly Manual”

---

But there’s so much boilerplate!

So don’t fill out the useless parts...

* Delete sections that aren’t relevant * If there’s a better format, just do it that way * Complain to if the template is silly

---

The requirements are too ill-defined to write down

I’m sure writing code will solve the problem then. /sarcasm

* This is exactly why architecture documents are helpful * Just barf out some bad requirements and ask for feedback * If no one has any ideas, we’ve got bigger problems

---

I’m the one writing the code, back off!

Software engineers are experts about everything and tend to have opinions.

* Enumerate alternative approaches and politely explain why they are dumb * Detail out the chosen approach * When in doubt, write out function signatures

---

When is enough enough?

When it starts to feel passive aggressive

* Writing code without an architecture doc is speculative * “Wasting” 30 minutes on a doc can save hours in a PR * I’ve never regretted writing an architecture document

---

Super Fun Activity Time

Whatever you’re currently working on, write an architecture doc for it.

(If you already have one, quit wasting time and go write code!)

You have 15 minutes!

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

#164

Post by giantg2 » Mon, Dec 07, 2020, 7:47 PM UTC

rendall wrote: post #130

giantg2 wrote: post #101

I was a top performer on my team in the past for a couple years. It was nice being an expert, but they never promoted me and were always playing games. I think it's better just be a average or below average person and not have to deal with the BS that comes with being a top performer. At this point in my career I doubt I'll ever make it back to that level of skill anyways.

Why not?

Why won't I get back to that level?

I have a kid, so I don't have any time to study outside of work or put in tons of extra hours. After years of being screwed over and passed over, I don't really have the drive/hope to get to that level since it wasn't rewarded the first time. Also, the work is very boring now and isn't transferrable to other groups or companies, so I don't have any interest in being an expert just to throw away that knowledge (like I was forced to do in the past).

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

#165

Post by cratermoon » Mon, Dec 07, 2020, 7:51 PM UTC

codegladiator wrote: post #30

sgtnoodle wrote: post #27

Perhaps some of the more productive workers are the ones that don't hesitate to make necessary code changes, test the changes adequately, and then move on to the next thing. I have noticed that pretty much every software engineer to some degree has problems that they procrastinate on. Folk can spend 10x more time talking about doing something than it takes to do it. For hard problems, that discussion is necessary and…

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…

That's also a sign they aren't comfortable with the version control system. I used to be like that, and with cvs and svn it was somewhat justifiable. Now that we have git and it's everywhere I'm far less anxious. Not that git is perfect and things don't happen, but it's extremely good at not Screwing Up. It may not do exactly what you expected, but it doesn't break the repo. It also tries really hard to never forget anything unless you make an effort to force it. It might take a bit of digging around in the reflog to figure out how to get back to a sane state, but in every case I've had to deal with it was possible.

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

#166

Post by notacoward » Mon, Dec 07, 2020, 7:51 PM UTC

temac wrote: post #131

notacoward wrote: post #76

OP mentions three things: staging their work, velocity, and sense of agency/ownership. All three are problematic. Often those who have worked with a component the longest and/or wrote significant parts of it become its maintainers, either formally or de facto. As a maintainer (I've been one myself) it's simply easier to get commits in, not necessarily because you're better at the work but because of the role itself.…

OTOH I'm tired of people who don't "have the time or knowledge to complete [their ideas]". Ideas are cheap. Show me the code. Asking, explicitly or implicitly, for others to "implement/finish" their ideas is easy. I would even call never finishing / polishing anything very disrespectful: I'm not (should not be) here to cleanup after "talented" individuals. This is detrimental to my own "ideas." So at least, if not an…

> Ideas are cheap. Show me the code.

I mostly agree with you, but also don't want to be too developer-centric. Sometimes the ideas come from people who aren't primarily developers - production engineers, system architects, etc. Let's say an idea from such a person is fundamentally good and will benefit the project but they lack the time or skill to do more than prototype it. What should happen?

(a) Drop it on the floor.

(b) Let their patch(es) languish and eventually get reaped. Same result in terms of functionality, plus contributes to an "maintainers aren't open to new ideas" reputation which harms recruitment/retention.

(c) Get a developer with more knowledge/skill to finish it. In general, this is just going to be the maintainer, because nobody else will have a strong enough sense of ownership to sacrifice time toward their own goals for it.

Obviously this is going to be case by case, but I'd say that (c) is at least sometimes a valid answer. Depending on the makeup of people involved with the project, which in turn might depend on the nature of the project itself, it might even be quite often.

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

#167

Post by p5a0u9l » Mon, Dec 07, 2020, 7:54 PM UTC

EarthLaunch wrote: post #118

p5a0u9l wrote: post #100

Earlier quoted context omitted.

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.

Fair.

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

#168

Post by datagram » Mon, Dec 07, 2020, 7:58 PM UTC

Ozzie_osman wrote: post #108

There's a pretty subtle pitfall that teams can fall into here. Let's say a team has 2 developers. Josh is 20% "better" than the John, or simply started earlier and has more context on the code base. So initially, Josh is 20% faster, but now John has to spend an extra 20% of his time reviewing Josh's code in a pull request (or understanding Josh's code so he can make a change) instead of making forward progress. So no…

I've found myself in this sort of situation a lot, including on 2-person teams. While I'm pointing out all the bugs, maintability issues, etc. on their commit, they're busy writing a new commit full of the same types of issues. And on the flip size: because I self-review my code with the same attention, I rarely have any of those same sorts of issues in code that I make others review.

I'm lucky in that my company recognizes and appreciates the quality that provide with my work and encourage from others, but I'm not sure of how to actually address the imbalance. Many times I've thought of just asking engineers to put more effort into self-reviewing their code, but I always feel like it would just be too rude.

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

#169

Post by sgtnoodle » Mon, Dec 07, 2020, 8:09 PM UTC

frfl wrote: post #88

sgtnoodle wrote: post #54

Earlier quoted context omitted.

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…

> Writing Mediocre Architecture Documents 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 poin…

I consider any code that's written to be "speculative" until its design has been vetted by another engineer. By speculative, I mean that there's no expectation that the code will be approved and merged in its present form. An architecture document is simply a good way to get that buy-in. If I write down what I plan on doing in a document, and then solicit feedback on it from a coworker, there's a very good chance that the same coworker will approve the resulting code without anything but bug and style fixes. If you're exploring the problem space, yeah of course go ahead and hack away at some code. If the experiments go exceedingly well and you end up with production quality code, go ahead and throw it in a PR for review. You have to be receptive to "bike shedding" feedback, though, since the PR is the first opportunity you gave for folk to give that type of feedback.

It's also perfectly reasonable to write and distribute a document that effectively says, "I have no idea what the requirements are, but I have an arbitrary idea for how we should proceed anyway." More often than not, your coworkers will help flesh out the requirements, or agree with your arbitrary design decisions. Either way, it's a lot easier to have that type of discussion on a free-form wiki page rather than in a github PR that you already spent 4 hours getting to compile and pass test suites.

Re: soliciting feedback, even verbose architecture documents tend to be relatively easy for your coworkers to digest. It is communication written for human consumption rather than machine consumption, after all. For one thing, you can have a lot of fun with them. One of my recent arch documents had at least a dozen MC Hammer puns in it. I had no trouble getting anyone to read through that. Also, if you give your coworkers the opportunity and they don't follow up on it, it does give you the high road in any eventual PR contention. "I mentioned this a week ago and asked you for feedback on it, why are you making a fuss about it now?" Not that you should be setting up your coworkers like that. You should make a good faith effort to solicit feedback, and keep politely pestering folk until they get to it. Until you get buy-in, any code written is still speculative, even if you tried your best and your coworkers let you down.

It helps to lead by example. If you prioritize giving feedback to coworkers over your own implementation work (reading their documents, doing their code reviews in a timely way, etc.), then your coworkers will tend to notice and reciprocate.

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

#170

Post by frfl » Mon, Dec 07, 2020, 8:52 PM UTC

sgtnoodle wrote: post #169

frfl wrote: post #88

Earlier quoted context omitted.

> Writing Mediocre Architecture Documents 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 poin…

I consider any code that's written to be "speculative" until its design has been vetted by another engineer. By speculative, I mean that there's no expectation that the code will be approved and merged in its present form. An architecture document is simply a good way to get that buy-in. If I write down what I plan on doing in a document, and then solicit feedback on it from a coworker, there's a very good chance tha…

That's very insightful. Appreciate the write up. Thank you.

I noticed the slide deck stuff in a sibling comment, +1