11 ms·

Prolific Engineers Take Small Bites

251 points by tbassetto 10y ago

trevyn 10y ago
Non-technical co-founder of Git analysis tool writes blog post that makes assertions about all sorts of things and then justifies this with mockup charts whose axes are unlabeled. Then offers tools to help micro-manage engineers.
- thebent 10y ago
  @trevyn Co-founder here. You’re right: this post is a narrative about product development, and a strong correlation we found between two variables across 20 Million+ commits that we thought was fascinating and supports general 'kitchen logic' around best practices. The axes are not labeled, but if you like we can set you up with a demo account and walk through your data with you. One other note: the typical common use case for the product has been stakeholder management; something we have doubled down on in product development. Any specific critique about how we can improve most welcome!
  - benwr 10y ago
    Specific critiques about how you can improve your blog post: 1. Data is always necessary to back up claims like these. Almost _any_ kind of quantitative data will do - just a simple average! just give me something I can replicate on other data sets. Similarly, just saying "we made up these variables as a combination of these other variables and called them Flavorfulness and Musicality, look how nicely our circles line up!" is not useful to anyone - a formula or methodology would be. 2. As a software engineer, I came to this post expecting to find a way to improve myself. I invested time in reading it because I expected a payoff in the form of, for example, a metric I could apply to my own work. I suspect that the author of this post intentionally gave the impression that the post contained tools like this. I didn't find anything remotely like that. 3. More generally, this post does not show signs of being written with the reader in mind. You have not given me any new information that I can apply; instead you have given me a marketing pitch (we did this data analysis, we promise! Don't you want us to work with you?) dressed up like information.
  - trevyn 10y ago
    Sure, specific critique: It appears that you are making fancy metrics that are more complex but fundamentally no better than a LOC metric. Is there a way that you could create metrics reflecting actual monetary business value created?
    - thebent 10y ago
      @trevyn We've got some things in that vein that are working in the app today — and are working toward even more. If you’d like, we could hop on a call and give you a tour of the app and show you where we’re headed? Seems like you've given this some thought on how this should be done right; would love to include them in our product development discussions.
  - DenisM 10y ago
    > The axes are not labeled, but if you like we can set you up with a demo account and walk through your data with you. Really? Rather than going back and labeling you axes you are converting this into a sales call???
    - thebent 10y ago
      My actual suggestion was to hop on with the product team/co-founder. This article is a narrative about something we found pretty interesting during product development. Similarly, the offer here is to take a deeper look at what we're building and a (quite genuine) offer to incorporate any suggestions you might have into our roadmap.
      - bojo 10y ago
        Congratulations, you have completely missed the point.
  - tedmiston 10y ago
    This post and the follow up comment "talk to sales" costs your company a lot of credibility. Your post gives prescriptive conclusions not supported by the data presented. Of the data that you did analyze, we're given so few numbers actually published that everyone is forced to question the fundamental methodology, even that is not clearly stated. The specific critique is to make well-founded claims.
- focusgroup0 10y ago
  On the one hand, I have this depressing vision of the future where a non-technical micromanager is imploring me to 'code smaller' because a tool the suits are paying $1250 / month for told them to. On the other hand, the irony of being told what to do by a tool coded by some 'out-of-touch know-it-all tech people' is not lost on me - some of my work has surely been used to inflict this sort of micromanagement on others.
  - 0xdeadbeefbabe 10y ago
    Makes me wonder what qualifies a micromanager for micromanagement.
minimaxir 10y ago
This post is a good example of my current issues with modern data journalism as content marketing: you can say anything you want without evidence to back it up, but hey, there's a pretty chart, so it doesn't matter. (In this blog post, the data points don't correspond to actual data!) This is also the primary reason I have switched to Jupyter/R Notebooks for my blog posts: if I make ridiculous claims, people can check my work as evidence. This post doesn't even provide any quantifiable metrics, just "we analyzed millions of commits."
- thebent 10y ago
  Would love to better expose our data set. It’s a bit tricky however: we’re specifically interested in enterprise software engineering (the patterns of which differ radically from the open source world). In order to dig into enterprise data, we sort of need to have a ToS that only allows us to talking abstractly about aggregate data. Any thoughts on how we might navigate that?
  - minimaxir 10y ago
    You don't have to expose the raw dataset explicitly, but you do need to describe your methodology (moreso than an arbitrary "impact" score; give a formula) and give actual numbers for the analysis, and not just argue a "strong correlation" with a highly arbitrary matrix of attributes.
    - arethuza 10y ago
      It's a marketing article - trying to explain their product to potential customers, not a scientific publication. I'm not saying that you are necessarily wrong but I do wonder if making an article like this more like a formal publication will actually make it better or worse at it's real goal which is presumably to sell more.
      - minimaxir 10y ago
        Yes, the standards of an marketing article are nonacademic, but you can't make a article containing a data driven argument and skimp on both the data and the argument.
dasil003 10y ago
I large agree with this, although with some provisos. First of all, sometimes it's most useful to take a step back and think about problems in a wider context. Often the biggest impact is from the code you don't write. There's really no way those kinds of contributions come out in any kind of metrics, but the team will sure remember them. More commonly, I prefer to commit often to aid my dev process but then rebase those commits into more cohesive units before merging. How chunky to make those final commits is somewhat a matter of taste, and probably shaped by the domain one is working in. Personally I like the finest grain possible without any build breakage, that way git-bisect still works, but hopefully there's still enough granularity to help with trickier merge/rebase scenarios around dependency upgrades and/or db migrations. But pardoning the digression, my point is the output seen by the rest of the team may not represent the original frequency of commits.
- jimaccount 10y ago
  I tend towards larger commits, large enough that the commit message can be more "why" than "what". That way git blame works better. (My issue tracker isn't coupled to my repo, and bisect is mostly useless for me because my builds take so long. So like you said, depends on the codebase.)
coldcode 10y ago
What are they measuring? Public git repositories? The article doesn't say anything about whatever data is being analyzed. If its public git that's hardly comparable to a large corporate entity.
traverseda 10y ago
Jesus that site was annoying. I go to read the article, and a popup beeps at me distracting me. I think "what the hell is this crap" and move my mouse towards the "about" page. A pop-up pops up (as they do) and distracts me from even that. Both times I tried to get information out of their site they found a way to interrupt me. Then I leave without reading the article.
- sean_patel 10y ago
  Heard of Adblocker much? I didn't have your experience on that page :)
  - traverseda 10y ago
    I've got ublock installed under ff, and there weren't popups in the sense of a new window, but in the sense of an in page element.
  - Graphon1 10y ago
    a non-sarcastic phrasing might be.... "Do you use an Ad blocker? I do, and didnt have that experience."
NumberSix 10y ago
Neither in the article or in the referenced article/blog post linked to "Impact" is impact defined. https://blog.gitprime.com/impact-a-better-way-to-measure-codebase-change https://blog.gitprime.com/impact-a-better-way-to-measure-cod... What I found is: Impact takes the following into account: The amount of code in the change What percentage of the work is edits to old code The surface area of the change (think ‘number of edit locations’) The number of files affected The severity of changes when old code is modified How this change compares to others from the project history No exact or detailed formula for "impact" is given. "takes the following into account" is extremely vague as it could indicate any relationship. Is impact higher with more files changed in the commit? Why would it be better if more files are changed? Is it lower? Why would it be better if fewer files are changed? Is it some totally unobvious non-linear function such as a trigonometric sine? Based on the vague description above, nothing in "impact" is directly related to the actual end user/paying customer experience or a reasonable proxy such as systematic end user testing by a QA team. This lack of a direct relationship to the desired end result is the same problem that lines of code (loc or LoC) and many other metrics of software engineer output have. The "impact" metric, whatever it precisely is, looks suspiciously like it would naturally be positively correlated with a large number of commits/high frequency of commits. Also the plot is labeled with "volume" on the horizontal axis and not the mysterious "impact" metric. The text implies this horizontal axis is the "impact" metric. Why is the horizontal axis not labeled impact? Even more peculiar, "impact" is claimed to measure cognitive load: Impact attempts to answer the question: “Roughly how much cognitive load did the engineer carry when implementing these changes?” A good engineer will attempt to find a low or no cognitive load solution to a problem! In general this will be faster and less error prone and cheaper! Reinventing the wheel has a very high cognitive load.
- debaserab2 10y ago
  Not to mention that's a pretty easy to game metric. By that rational, renaming a variable name across a few files is going to make me quite impactful. If my job were being judged by this metric, I'd sure be thinking a lot about that. This measurement also seems to favor overengineering, which is one of the biggest things I've learned to stay away from. When I was early on in my career, I thought I could implement anything myself, and so I often did. It wasn't until years later that I understand the implications of maintaining these implementations. A true measure of impact to me would be a ratio of the most concise (but still understandable) amount of code to the amount that it solves the requirement it's built for. It's impossible to measure that without the context of the problem you are trying to solve.
ninjakeyboard 10y ago
Can you make any claims about the number of commits? That's another metric that changes depending on tools and processes. If you're using a code review tool well (if you are more experienced with it) then you'll automatically be making lots of small commits vs people that may not be well versed in working that way. If you're working with large or prolific teams then you'll be committing all the time with eg feature toggles to ensure everyone is as close to the current code with their changes as possible. So making general claims about more commits without taking into consideration the ways that metric is bent and changes with tools and processes and different experiences seems to be dangerous.
deleted 10y ago
[deleted]
clifanatic 10y ago
There's a great, fun, programmer-centric website called thedailywtf.com (sorry, I just scheduled the rest of your afternoon for you). Developers can submit WTF's that they've found in other's code - as the site admin says, "curious perversions in information technology". One thing that strikes me about the majority of the submissions, as funny as they are, is that they mostly boil down to "so-and-so didn't know that such-and-such feature existed, so wrote reams of code to implement that feature in a complex way". It also strikes me that just this article's sort of analysis of "prolific" (aka "good") engineers/programmers drives this same sort of behavior. If every developer is supposed to be committing code all day, every day, there's no time left over to read the product documentation, try out a new feature, review a reference implementation, read a blog post: to be "good", you must be spending as much time as possible _typing_, because that's what you're paid to do. This (ubiquitous) management mentality is how we end up with roll-your-own crypto, or five competing Javascript frameworks, parsing using regular expressions... it's not so much that what they did was wrong - and trust me, if it works, it won't be removed - it's that it's pointless.
- darkerside 10y ago
  It can also work the opposite way. You can think you understand the requirements and go hole yourself away for a couple of days pumping out code. When you finally merge your work, another developer tells you, "Why didn't you just use function X or package Y?". If you're doing your work in small, sharp bursts, you actually end up with more time in between work for talking with other devs, reading up on technology, etc.
  - Bartweiss 10y ago
    I think this is the better insight. A lot of DailyWTF posts are about people not knowing a function existed and then reimplementing it horribly. Many of them include a note like "the other 10,000 lines were similar". Ignorance is not embarrassing, it's the default state when all of our tools grow and change daily. But a lot of the worst wtf moments are clearly cases where something wasn't sanity checked by anyone until it was presented as a finished product - sometimes too late to keep out of production. That's the benefit of frequent commits, reviews, and research breaks; they might not prevent our ignorance, but they keep it under control.
bertr4nd 10y ago
This reminds me that one of the things I loved about working on server-side efficiency is that for any given diff, you can measure the performance improvement, multiply by hardware costs, and say, "That diff saved $X." Makes it really easy to measure impact and feel that my salary is justified.
- scalesolved 10y ago
  That is one side to the coin, however if you made a change that was a performance improvement yet the code was highly cryptic and hard for anyone else to understand then this wouldn't be a good thing. Essentially what I'm getting at is that peer review from team members is the best metric for what is good and isn't.
  - bertr4nd 10y ago
    Absolutely true. Still, it helps when one side of the coin is precisely quantifiable, since it helps frame the more subjective questions like code complexity.
Dowwie 10y ago
Analyzing churn is tricky and can be easily misinterpreted by management. This reminds me of what was revealed from studies in behavioral sciences and presented by Dan Ariely: https://www.youtube.com/watch?v=Q92BqouxyX4 https://www.youtube.com/watch?v=Q92BqouxyX4
arnon 10y ago
Unfortunately know some bottom-right quadrant people. We got rid of some of those not too long ago - wouldn't want them on my team again. Super hard to manage and work with.
nano1237 10y ago
We tried this. Fast commits for small features gave us an unmaintainable code base that eventually didn't work anymore.
nano1237 10y ago
We tried this. It gave us an unmaintainable code base that our platform could no longer add features unless we threw so many people at it.
awinter-py 10y ago
concepts missing from the article: 'staging' and 'commit size'. People who have worked in code review shops tend to stage their commits, i.e. do a bunch of work but commit it with git commit -p. Article also doesn't look at deployment frequency, and 'merge' appears only once. We don't know if these 'high impact' devs are in their own branch for 6 weeks cooking up the PR from hell. That's one way to have a high impact.
kristianc 10y ago
Unless I'm missing something, how is 'Impact' derived here? Impact as a metric is fine, but you have to show what it is and how you arrived at that conclusion, and have verified that against a test set of data otherwise it's turtles all the way down. https://en.m.wikipedia.org/wiki/Turtles_all_the_way_down https://en.m.wikipedia.org/wiki/Turtles_all_the_way_down
ticktockten 10y ago
This is misleading, however I would like to point out that if Small Bites == Kaizen. Then, Prolific Engineers like any other prolific professionals may be Kizening the crap out of their codebases. No data here either to back the smart ones up though.
xt00 10y ago
Title of the article uses the word "Engineers" rather than software engineers, and if you lump together virtually anybody who makes changes to a code base (testers, sw architects, sw leads, etc), it seems like its easy to have the data obviously skewed by people who essentially spam the commit process. I think most people can look at a commit log and sort of eye-ball who are the people who really make shit happen on a project--and who is probably causing more grief than anybody else. I agree its hard to quantify, but to be honest I didn't take away much from this article. I like the goal of the article, just think it didn't really hit the mark.
ianstallings 10y ago
Huh, strange. My made up charts say something completely different.
rsp1984 10y ago
The title, well actually the entire article, is one of those things where A -> B is stated, well knowing (and almost expecting) that readers will understand it as B -> A or B <-> A. It's the developer version of the typical "10 Things Successful People Do" clickbait. Yes, a lot of (although far from all!) good coders have the habit of taking small bites. That doesn't mean though that by taking smaller bites you are (or are becoming) a good coder. I've had the past displeasure of dealing with code that hit all the superficial checkmarks (small commits, unit-tested, peer-reviewed, you name it...) yet completely stunk.
tedmiston 10y ago
Extrapolating a "prolific engineer" from one's commit log is no less absurd than from lines of code. Their methodology fails to account for so many things, commit squashing feature branches, for example. A fundamentally flawed "study".
- mateo411 10y ago
  The methodology also suggests a particular workflow is better. A workflow where you commit and merge, instead of commit, rebase, then merge.
keeptrying 10y ago
This article and company can be safely ignored.
z3t4 10y ago
How do you finish a project ? One step at a time !
ns8sl 10y ago
We have a hard rule that you do not commit code that doesn't pass unit tests. This leads to bad coders not being able to commit as frequently as good coders. However, this seems like a very, very loose heuristic.
alphanumeric0 10y ago
Well I guess I'd be labelled a poor programmer since I wait to commit until my code has passed a few core specification tests.
agentultra 10y ago
I'm curious what the general vehemence is to quantifying and understanding this information is? It's right there in your commit history. I've run my own analyses out of curiosity in the past... statistics just isn't my favourite subject. I think it's an interesting metric and I'd certainly like to know more about how it's calculated. (Although I'm sure that's part of the secret sauce).
- overgard 10y ago
  I think people get uncomfortable because people will run with the data and enact policies that are potentially detrimental, and then people will game it. (You see this happen all the time with "velocity" at agile shops). Data itself is great, it's just scary what happens with it when it falls into unwise hands.
deleted 10y ago
[deleted]

251 points by tbassetto 10y ago

Non-technical co-founder of Git analysis tool writes blog post that makes assertions about all sorts of things and then justifies this with mockup charts whose axes are unlabeled. Then offers tools to help micro-manage engineers.

thebent 10y ago
@trevyn Co-founder here. You’re right: this post is a narrative about product development, and a strong correlation we found between two variables across 20 Million+ commits that we thought was fascinating and supports general 'kitchen logic' around best practices. The axes are not labeled, but if you like we can set you up with a demo account and walk through your data with you. One other note: the typical common use case for the product has been stakeholder management; something we have doubled down on in product development. Any specific critique about how we can improve most welcome!
- benwr 10y ago
  Specific critiques about how you can improve your blog post: 1. Data is always necessary to back up claims like these. Almost _any_ kind of quantitative data will do - just a simple average! just give me something I can replicate on other data sets. Similarly, just saying "we made up these variables as a combination of these other variables and called them Flavorfulness and Musicality, look how nicely our circles line up!" is not useful to anyone - a formula or methodology would be. 2. As a software engineer, I came to this post expecting to find a way to improve myself. I invested time in reading it because I expected a payoff in the form of, for example, a metric I could apply to my own work. I suspect that the author of this post intentionally gave the impression that the post contained tools like this. I didn't find anything remotely like that. 3. More generally, this post does not show signs of being written with the reader in mind. You have not given me any new information that I can apply; instead you have given me a marketing pitch (we did this data analysis, we promise! Don't you want us to work with you?) dressed up like information.
- trevyn 10y ago
  Sure, specific critique: It appears that you are making fancy metrics that are more complex but fundamentally no better than a LOC metric. Is there a way that you could create metrics reflecting actual monetary business value created?
  - thebent 10y ago
    @trevyn We've got some things in that vein that are working in the app today — and are working toward even more. If you’d like, we could hop on a call and give you a tour of the app and show you where we’re headed? Seems like you've given this some thought on how this should be done right; would love to include them in our product development discussions.
- DenisM 10y ago
  > The axes are not labeled, but if you like we can set you up with a demo account and walk through your data with you. Really? Rather than going back and labeling you axes you are converting this into a sales call???
  - thebent 10y ago
    My actual suggestion was to hop on with the product team/co-founder. This article is a narrative about something we found pretty interesting during product development. Similarly, the offer here is to take a deeper look at what we're building and a (quite genuine) offer to incorporate any suggestions you might have into our roadmap.
    - bojo 10y ago
      Congratulations, you have completely missed the point.
- tedmiston 10y ago
  This post and the follow up comment "talk to sales" costs your company a lot of credibility. Your post gives prescriptive conclusions not supported by the data presented. Of the data that you did analyze, we're given so few numbers actually published that everyone is forced to question the fundamental methodology, even that is not clearly stated. The specific critique is to make well-founded claims.
focusgroup0 10y ago
On the one hand, I have this depressing vision of the future where a non-technical micromanager is imploring me to 'code smaller' because a tool the suits are paying $1250 / month for told them to. On the other hand, the irony of being told what to do by a tool coded by some 'out-of-touch know-it-all tech people' is not lost on me - some of my work has surely been used to inflict this sort of micromanagement on others.
- 0xdeadbeefbabe 10y ago
  Makes me wonder what qualifies a micromanager for micromanagement.

minimaxir 10y ago

This post is a good example of my current issues with modern data journalism as content marketing: you can say anything you want without evidence to back it up, but hey, there's a pretty chart, so it doesn't matter. (In this blog post, the data points don't correspond to actual data!) This is also the primary reason I have switched to Jupyter/R Notebooks for my blog posts: if I make ridiculous claims, people can check my work as evidence. This post doesn't even provide any quantifiable metrics, just "we analyzed millions of commits."

thebent 10y ago
Would love to better expose our data set. It’s a bit tricky however: we’re specifically interested in enterprise software engineering (the patterns of which differ radically from the open source world). In order to dig into enterprise data, we sort of need to have a ToS that only allows us to talking abstractly about aggregate data. Any thoughts on how we might navigate that?
- minimaxir 10y ago
  You don't have to expose the raw dataset explicitly, but you do need to describe your methodology (moreso than an arbitrary "impact" score; give a formula) and give actual numbers for the analysis, and not just argue a "strong correlation" with a highly arbitrary matrix of attributes.
  - arethuza 10y ago
    It's a marketing article - trying to explain their product to potential customers, not a scientific publication. I'm not saying that you are necessarily wrong but I do wonder if making an article like this more like a formal publication will actually make it better or worse at it's real goal which is presumably to sell more.
    - minimaxir 10y ago
      Yes, the standards of an marketing article are nonacademic, but you can't make a article containing a data driven argument and skimp on both the data and the argument.

dasil003 10y ago

I large agree with this, although with some provisos. First of all, sometimes it's most useful to take a step back and think about problems in a wider context. Often the biggest impact is from the code you don't write. There's really no way those kinds of contributions come out in any kind of metrics, but the team will sure remember them. More commonly, I prefer to commit often to aid my dev process but then rebase those commits into more cohesive units before merging. How chunky to make those final commits is somewhat a matter of taste, and probably shaped by the domain one is working in. Personally I like the finest grain possible without any build breakage, that way git-bisect still works, but hopefully there's still enough granularity to help with trickier merge/rebase scenarios around dependency upgrades and/or db migrations. But pardoning the digression, my point is the output seen by the rest of the team may not represent the original frequency of commits.

jimaccount 10y ago
I tend towards larger commits, large enough that the commit message can be more "why" than "what". That way git blame works better. (My issue tracker isn't coupled to my repo, and bisect is mostly useless for me because my builds take so long. So like you said, depends on the codebase.)

coldcode 10y ago

What are they measuring? Public git repositories? The article doesn't say anything about whatever data is being analyzed. If its public git that's hardly comparable to a large corporate entity.

traverseda 10y ago

Jesus that site was annoying. I go to read the article, and a popup beeps at me distracting me. I think "what the hell is this crap" and move my mouse towards the "about" page. A pop-up pops up (as they do) and distracts me from even that. Both times I tried to get information out of their site they found a way to interrupt me. Then I leave without reading the article.

sean_patel 10y ago
Heard of Adblocker much? I didn't have your experience on that page :)
- traverseda 10y ago
  I've got ublock installed under ff, and there weren't popups in the sense of a new window, but in the sense of an in page element.
- Graphon1 10y ago
  a non-sarcastic phrasing might be.... "Do you use an Ad blocker? I do, and didnt have that experience."

NumberSix 10y ago

Neither in the article or in the referenced article/blog post linked to "Impact" is impact defined. https://blog.gitprime.com/impact-a-better-way-to-measure-codebase-change https://blog.gitprime.com/impact-a-better-way-to-measure-cod... What I found is: Impact takes the following into account: The amount of code in the change What percentage of the work is edits to old code The surface area of the change (think ‘number of edit locations’) The number of files affected The severity of changes when old code is modified How this change compares to others from the project history No exact or detailed formula for "impact" is given. "takes the following into account" is extremely vague as it could indicate any relationship. Is impact higher with more files changed in the commit? Why would it be better if more files are changed? Is it lower? Why would it be better if fewer files are changed? Is it some totally unobvious non-linear function such as a trigonometric sine? Based on the vague description above, nothing in "impact" is directly related to the actual end user/paying customer experience or a reasonable proxy such as systematic end user testing by a QA team. This lack of a direct relationship to the desired end result is the same problem that lines of code (loc or LoC) and many other metrics of software engineer output have. The "impact" metric, whatever it precisely is, looks suspiciously like it would naturally be positively correlated with a large number of commits/high frequency of commits. Also the plot is labeled with "volume" on the horizontal axis and not the mysterious "impact" metric. The text implies this horizontal axis is the "impact" metric. Why is the horizontal axis not labeled impact? Even more peculiar, "impact" is claimed to measure cognitive load: Impact attempts to answer the question: “Roughly how much cognitive load did the engineer carry when implementing these changes?” A good engineer will attempt to find a low or no cognitive load solution to a problem! In general this will be faster and less error prone and cheaper! Reinventing the wheel has a very high cognitive load.

debaserab2 10y ago
Not to mention that's a pretty easy to game metric. By that rational, renaming a variable name across a few files is going to make me quite impactful. If my job were being judged by this metric, I'd sure be thinking a lot about that. This measurement also seems to favor overengineering, which is one of the biggest things I've learned to stay away from. When I was early on in my career, I thought I could implement anything myself, and so I often did. It wasn't until years later that I understand the implications of maintaining these implementations. A true measure of impact to me would be a ratio of the most concise (but still understandable) amount of code to the amount that it solves the requirement it's built for. It's impossible to measure that without the context of the problem you are trying to solve.

ninjakeyboard 10y ago

Can you make any claims about the number of commits? That's another metric that changes depending on tools and processes. If you're using a code review tool well (if you are more experienced with it) then you'll automatically be making lots of small commits vs people that may not be well versed in working that way. If you're working with large or prolific teams then you'll be committing all the time with eg feature toggles to ensure everyone is as close to the current code with their changes as possible. So making general claims about more commits without taking into consideration the ways that metric is bent and changes with tools and processes and different experiences seems to be dangerous.

deleted 10y ago

[deleted]

clifanatic 10y ago

There's a great, fun, programmer-centric website called thedailywtf.com (sorry, I just scheduled the rest of your afternoon for you). Developers can submit WTF's that they've found in other's code - as the site admin says, "curious perversions in information technology". One thing that strikes me about the majority of the submissions, as funny as they are, is that they mostly boil down to "so-and-so didn't know that such-and-such feature existed, so wrote reams of code to implement that feature in a complex way". It also strikes me that just this article's sort of analysis of "prolific" (aka "good") engineers/programmers drives this same sort of behavior. If every developer is supposed to be committing code all day, every day, there's no time left over to read the product documentation, try out a new feature, review a reference implementation, read a blog post: to be "good", you must be spending as much time as possible _typing_, because that's what you're paid to do. This (ubiquitous) management mentality is how we end up with roll-your-own crypto, or five competing Javascript frameworks, parsing using regular expressions... it's not so much that what they did was wrong - and trust me, if it works, it won't be removed - it's that it's pointless.

darkerside 10y ago
It can also work the opposite way. You can think you understand the requirements and go hole yourself away for a couple of days pumping out code. When you finally merge your work, another developer tells you, "Why didn't you just use function X or package Y?". If you're doing your work in small, sharp bursts, you actually end up with more time in between work for talking with other devs, reading up on technology, etc.
- Bartweiss 10y ago
  I think this is the better insight. A lot of DailyWTF posts are about people not knowing a function existed and then reimplementing it horribly. Many of them include a note like "the other 10,000 lines were similar". Ignorance is not embarrassing, it's the default state when all of our tools grow and change daily. But a lot of the worst wtf moments are clearly cases where something wasn't sanity checked by anyone until it was presented as a finished product - sometimes too late to keep out of production. That's the benefit of frequent commits, reviews, and research breaks; they might not prevent our ignorance, but they keep it under control.

bertr4nd 10y ago

This reminds me that one of the things I loved about working on server-side efficiency is that for any given diff, you can measure the performance improvement, multiply by hardware costs, and say, "That diff saved $X." Makes it really easy to measure impact and feel that my salary is justified.

scalesolved 10y ago
That is one side to the coin, however if you made a change that was a performance improvement yet the code was highly cryptic and hard for anyone else to understand then this wouldn't be a good thing. Essentially what I'm getting at is that peer review from team members is the best metric for what is good and isn't.
- bertr4nd 10y ago
  Absolutely true. Still, it helps when one side of the coin is precisely quantifiable, since it helps frame the more subjective questions like code complexity.

Dowwie 10y ago

Analyzing churn is tricky and can be easily misinterpreted by management. This reminds me of what was revealed from studies in behavioral sciences and presented by Dan Ariely: https://www.youtube.com/watch?v=Q92BqouxyX4 https://www.youtube.com/watch?v=Q92BqouxyX4

arnon 10y ago

Unfortunately know some bottom-right quadrant people. We got rid of some of those not too long ago - wouldn't want them on my team again. Super hard to manage and work with.

nano1237 10y ago

We tried this. Fast commits for small features gave us an unmaintainable code base that eventually didn't work anymore.

nano1237 10y ago

We tried this. It gave us an unmaintainable code base that our platform could no longer add features unless we threw so many people at it.

awinter-py 10y ago

concepts missing from the article: 'staging' and 'commit size'. People who have worked in code review shops tend to stage their commits, i.e. do a bunch of work but commit it with git commit -p. Article also doesn't look at deployment frequency, and 'merge' appears only once. We don't know if these 'high impact' devs are in their own branch for 6 weeks cooking up the PR from hell. That's one way to have a high impact.

kristianc 10y ago

Unless I'm missing something, how is 'Impact' derived here? Impact as a metric is fine, but you have to show what it is and how you arrived at that conclusion, and have verified that against a test set of data otherwise it's turtles all the way down. https://en.m.wikipedia.org/wiki/Turtles_all_the_way_down https://en.m.wikipedia.org/wiki/Turtles_all_the_way_down

ticktockten 10y ago

This is misleading, however I would like to point out that if Small Bites == Kaizen. Then, Prolific Engineers like any other prolific professionals may be Kizening the crap out of their codebases. No data here either to back the smart ones up though.

xt00 10y ago

Title of the article uses the word "Engineers" rather than software engineers, and if you lump together virtually anybody who makes changes to a code base (testers, sw architects, sw leads, etc), it seems like its easy to have the data obviously skewed by people who essentially spam the commit process. I think most people can look at a commit log and sort of eye-ball who are the people who really make shit happen on a project--and who is probably causing more grief than anybody else. I agree its hard to quantify, but to be honest I didn't take away much from this article. I like the goal of the article, just think it didn't really hit the mark.

ianstallings 10y ago

Huh, strange. My made up charts say something completely different.

rsp1984 10y ago

The title, well actually the entire article, is one of those things where A -> B is stated, well knowing (and almost expecting) that readers will understand it as B -> A or B <-> A. It's the developer version of the typical "10 Things Successful People Do" clickbait. Yes, a lot of (although far from all!) good coders have the habit of taking small bites. That doesn't mean though that by taking smaller bites you are (or are becoming) a good coder. I've had the past displeasure of dealing with code that hit all the superficial checkmarks (small commits, unit-tested, peer-reviewed, you name it...) yet completely stunk.

tedmiston 10y ago

Extrapolating a "prolific engineer" from one's commit log is no less absurd than from lines of code. Their methodology fails to account for so many things, commit squashing feature branches, for example. A fundamentally flawed "study".

mateo411 10y ago
The methodology also suggests a particular workflow is better. A workflow where you commit and merge, instead of commit, rebase, then merge.

keeptrying 10y ago

This article and company can be safely ignored.

z3t4 10y ago

How do you finish a project ? One step at a time !

ns8sl 10y ago

We have a hard rule that you do not commit code that doesn't pass unit tests. This leads to bad coders not being able to commit as frequently as good coders. However, this seems like a very, very loose heuristic.

alphanumeric0 10y ago

Well I guess I'd be labelled a poor programmer since I wait to commit until my code has passed a few core specification tests.

agentultra 10y ago

I'm curious what the general vehemence is to quantifying and understanding this information is? It's right there in your commit history. I've run my own analyses out of curiosity in the past... statistics just isn't my favourite subject. I think it's an interesting metric and I'd certainly like to know more about how it's calculated. (Although I'm sure that's part of the secret sauce).

overgard 10y ago
I think people get uncomfortable because people will run with the data and enact policies that are potentially detrimental, and then people will game it. (You see this happen all the time with "velocity" at agile shops). Data itself is great, it's just scary what happens with it when it falls into unwise hands.

deleted 10y ago

[deleted]