9 ms·
It's very convenient to think it's a myth or to think that the only way you get to extreme productivity is to be a cowboy, but I have personally seen that it's
by seanhunter 7y ago
It's very convenient to think it's a myth or to think that the only way you get to extreme productivity is to be a cowboy, but I have personally seen that it's not the case. Obviously this is just an anecdote, but I have worked with at least one freak productivity monster so I know they can be real.
At one of my employers we had a very large and highly skilled dev community and being quant-biased, we tracked code checkins over time, number of tests written, number of pushes to production etc. I was very proud to be about number 3 or 4 out of about 1000 devs on these productivity metrics consistently over a period of 8 years there.
There was one guy however who literally dominated. Not only was he number 1 on any metric, but he did more checkins than the number 2, 3 and 4 devs combined. He had so many checkins that eventually our glimpse code search index whitelisted his userid because it thought it was a keyword in the language.
And it wasn't that he was a cowboy, he was obsessive about code quality, fixing bugs etc and also was top if you looked at test coverage etc. He was just a flat out machine - every day he would just come in and code all day whereas I have spurts of productivity with downtime etc. He didn't seem to need to be intellectually fascinated by a project and was just as productive at the beginning as at the end of a project - one of my colleagues joked that this guy's interest level in any project was always 83% ("Almost but not quite very interested") no matter what it was. He was very skilled and just churned out massive amounts of code all day every day. He never fell into the classic engineer's trap of overcomplicating things - in fact a lot of what he wrote was very simple when you looked at it (and I think that's part of what made him so good - he had a brilliance for finding really obvious, simple ways of solving hard problems) and because he wrote tests for everything he didn't really need to go back and or refactor things much.
- EdwardDiego 7y ago> At one of my employers we had a very large and highly skilled dev community and being quant-biased, we tracked code checkins over time, number of tests written, number of pushes to production etc. Why are those objectively useful metrics for productivity though? I can think of a dozen reasons why they aren't, as opposed to why they might be. Which, I guess, makes their objective usefulness subjective. Some people will be working on longer lived feature branches because they're more complex, so they end up with one merge to master in the time it took the dev updating REST APIs to accommodate a new optional parameter to merge four branches. Someone writes four tests that another dev might cover in one because the four assertions were all closely related to the same invariants and code paths. Who was actually more productive? One developer pushes to production three times in one day because they typoed a property name twice... ...etc. etc. ad nauseum. If you seriously believe that these metrics are objective methods of measuring developer productivity, I strongly suggest you spin off a business, because you're about to make millions.
- Shaanie 7y agoNo developer metrics are great, especially not if devs are incentivized to game them. However, I wouldn't be surprised at all if there's a correlation between good developers and those metrics.
- swagasaurus-rex 7y agoIf you incentivize the metrics, I would be surprised if the correlation held.
- bryanrasmussen 7y agoWell I suppose the correlation would still hold for the good developers but it would then also hold for the not as good developers. Over time maybe the bad developers would show a higher correlation than the good developers, but maybe not.
- tigershark 7y agoNumber of check-ins, if the check-ins are high quality as he implied, are a pretty good rule of thumb to measure the productivity. The guy working on the most complex feature with only one merge to master should check-in even more often than the guys working on the simple features.
- anarazel 7y agoI don't understand that logic - the complex piece might require tons of research, experimenting with different approaches, benchmarking etc, before getting to something committable. And the successful result might only be a small number of lines.
- watwut 7y agoI worked on project where I had dozens of commits every day. Now I work on project where I have one commit per few days. Sometimes I need to research for a week just to create one small commit. And I am still the same person - only my position changed.
- onion2k 7y agoPresumably someone, or some group, was writing all the requirements and acceptance criteria necessary for him to code all day, and they were managing the changes to those criteria as users gave feedback on what he was doing. And then there were the other devs peer reviewing his code, happily accepting his PRs without needing to add comments or request changes. And then there was the QA team doing the integration and end-to-end tests, user testing, training, etc. He couldn't have been quite so productive without those all those people. That's not to put his amazing work down. No doubt he was brilliant. It's just that we shouldn't ignore the efforts of the people who enable developers like him to get on with what they're good at. Development is a team sport.
- zeroonetwothree 7y agoYou’d be surprised. Sometimes the level of support from others is basically zero but you still make it happen. That’s the real sign of 10x
- splittingTimes 7y agoHow did it work out practice? After each Sprint the numbers got revealed? Did that not lead to a super competitive workplace? I cannot imagine that this was very motivating to the remaining 990 devs... Or was it?
- WalterBright 7y ago> in fact a lot of what he wrote was very simple when you looked at it (and I think that's part of what made him so good Genius is when you write a piece of code that's so simple everyone else thinks they could have done it. And yet they didn't.
- blub 7y agoThe only relevant question is whether that person has a life outside programming and work. If yes, then it's truly a case of remarkable talent. If not, it's a case of sacrificing something in exchange for something else.
- andreilys 7y agoModeration is not for everyone. The world would be a much less vibrant place if not for the obsessives among us who devote themselves religiously to their craft. Whether that be programming, writing, art, or otherwise.
- bitwize 7y agoIf you have someone who is so obsessed with programming that they have time for little else, the lack of social contact has the potential to turn that person into a problem later on. Case in point: Richard Stallman. Inappropriate behavior may have been well tolerated in the patriarchal past, but in 2020 we are expected to do better and our institutions can ill tolerate the risks presented by asocial white men.
- satyrnein 7y agoI think blub was just trying to distinguish whether the person delivered more value per hour, or just more hours. The outcome may be the same, but the former sounds more like "10x" than the latter.
- thdespou 7y agoWhat you are describing here is a code monkey. Did he had any opinions or took any design decisions or he was just paid to simplify things?
- asjw 7y agoI know the type Used to be like that when I was young I also know that there's the guy that never writes tests, is incapable of writing non reduntant-code, pushes everything to master as a blob of unrelated changes, using git as the backup server, comments are sparse and mostly useless, code is a mess and 'deploy to production' means starting a Jupiter notebook on the Dev machine. The same guy saves to the company millions in expenses and gets the promotion. 10-20-100x Devs are just very good Devs, nothing that automatically changes the fate of a company You can have the best guitar player in the World and your band goes nowhere or you could be the Ramones...
- acroback 7y agoI call BS, that's not even possible. Even the legendary "tourist" cannot do it, in his own words. He programs like 2-4 hours on good days.