151–160 of 194 posts
Earlier quoted context omitted.
are you the guy hosting that "time as a service" github repo? Where the time is always updated and you can curl the json or whatever and get the time?
Nope, not at all. Do you have any links to what you're talking about?
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 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, sloppy, riddled with issues and a nightmare to maintain. And it would inevitably fall upon us "lesser" performers to actually investigate and fix all those issues, making us look less productive in the process. This is o…
this this this.
More code might equal more bugs, but if it's a net gain in business value everything else is a secondary concern.
It doesn't mean you can just ship crap all the time. If customers start complaining/seeing errors/bad performance, business value decreases and there are going to be some $discussions.
If developers are rewarded for shoveling garbage into the pipeline all the time, there are deeper organizational issues afoot.
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…
What's even worse is if this metric ever becomes a target, Goodhart's Law will apply, and then Campbell's law will make it as useless as LOC.
Earlier quoted context omitted.
My experience is the same as the author's. If one defines top performer as you did, those who are "more focused on big ideas such as the structurally important parts of the architecture", and you run the numbers, you'll find most of these people will also be outliers in commit count. This is true in just about every team I've worked in. And it makes sense too. The person who best understands the design would be the f…
If you have to work on a very complex project, you need to plan the architecture at a high level or else it will be a disaster. I've seen the code-as-you-go approach fail miserably over and over. Try coding a decentralized P2P system where multiple instances of the same code running on many different kinds of machines communicates with itself in a scalable and DoS-resistant way. There is no way anyone can implement t…
Earlier 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…
Cause reasons for fear are not something people would tell you. I was in similar state twice and neither time I would be eager explain that to someone external. I was "afraid" to commit in a team where code review evolved into huge micro-management with inconsistent requirements on what good code looks like. The reviewer iteratively forced you to change it again and again each time with "this is bad code cant go in"…
In my org this can be somewhat of a problem (different teams have different code style guidelines for long historical reasons which can make cross-team changes tricky).
One thing that helped a lot with this is publishing these guidelines in a central location, but more importantly we also made bots that reviewed every code review to point out common mistakes that people made, so reviewers could focus on the change itself instead of naming/spacing nits.
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…
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…
What if every commit has to be reviewed by a certified code reviewer before it is accepted? That is how Google does it. Means you can't skip tests etc. Not sure why not more organizations do it, like wouldn't banks etc benefit a lot from it?
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 seen this over and over too. Put a Non-technical VP/Manager in charge. Maybe someone who started out as a UI designer or non technical PM and then somehow became VP of engineering because they were an early loyal employee. Charismatic coders will take advantage and the manager will eat it up. The "rock stars" commit tons of code put create massive tech debt. They write their own buggy versions of stuff they shou…
Because they are willing to take the risk of publicly being wrong. Committing your source code to the company git makes it very easy for others to point at you later, if things break. And it's pretty much impossible to undo once someone else has pulled your change. In my opinion, many top performers are simply people who do what needs to be done, and when it's needed.