flavianh

Well, productivity measures how fast you deliver new value. Fixing a bug is about repairing value that you thought you had delivered but actually did not. Counting bugs as "value" would be double counting.

Interesting to note that two of your decision points are on "shipping product improvements at a regular cadence" or "shipping so slow that it's negatively impacting customers". Both relate to a productivity discussion, ie "how to define what it means to 'ship' as an engineering team". In that sense, we're aligned on why it's important to measure productivity. It would however be a mistake to try to optimize for maximum productivity in a vacuum, but note that this is not what this thread is about. This thread is about the unit of measurement that people use in their teams. In that sense it's purely a research / curiosity question

That’s very interesting, what is the score based on?

I agree 100%, you need to have a strong product foundation to turn good output into good business outcome. A productive team that delivers features no one wants is pointless. Both go hand in hand, but as far as engineering management goes, it is still a challenge to find a good productivity metric. What’s used in your organization @przeor and what do you think of it?

Your comment got me curious, so I've just asked one of the best developers at Google. If you want to tag along and make some noise: https://twitter.com/FlavianHautbois/status/15972300521436733... (he has not replied yet) [FYI, I sent this comment to another thread as well]

I'm actually curious about this, so I've just asked one of the best developers at Google. If you want to tag along and make some noise: https://twitter.com/FlavianHautbois/status/15972300521436733... (he has not replied yet)

Don't get me wrong, pairing has merits. Let me give you an example. I'm in the middle of going through type challenges in Typescript (https://github.com/type-challenges/type-challenges). If I knew absolutely nothing about types, pair-programming would have helped me get started. But some of these challenges teach me important insights about the Typescript typing system that take time to wrap my head around. You don't get this amount of system 2 focus when pair programming because pair programming is (to a large amount) communication.

1. Yes, that's the point. 10x doesn't say "compared to what", but hints at "compared to now" 2. For sure. My 3 former companies let people spike while working, and I've seen mediocre engineers (lots of bugs, rework) become ok (barely any rework, a few bugs from time to time)

Being independent or in a co-op, what would be your training system?

It looks like your company is ticking a lot of boxes, they're a keeper for sure. Would you share their name?

This. I genuinely think this is one of the best comments in this thread!

You're right in a way, but you're missing the "10x compared to what?". Consider the 1x baseline as being the median productivity of your development team (which is definitely hard to approximate, but for the sake of the exercise let's take 'value-added tickets per developer' [which excludes bugs/rework]). Then the goal is to do 10x on this median in a reasonable amount of time. Rince and repeat.

I assume some of the skills you're trained on are technical too. Your organization sounds like it does a lot to develop engineers, do you think it's paying off regarding competition or other tech companies?

I found it to be very challenging to deep-dive into harder subjects when doing pairing

Most don’t, I’m wondering if they should.

R really is the best language for data science. Was looking for such a tutorial to scale things up, thanks!

I give resources to debug JavaScript at the end of the article, did you miss them or are they not good enough?

Just one? I guess you found out about the methods default value this way, did you find the other one by eye?

That's an interesting try! I think the default assignment is done by reference as well, so when i changes in the loop the default value changes as well? Similarly to methods=[]. Can't say for sure though. The solution I give in the article is the only one I could come up with, I'm interested if you find another one :)

I'm glad I haven't been insulted yet

Article author here. I agree with your point, I shouldn't have been so cautious. I consistently observed people being faster when using debuggers and I wanted to give it a test on this problem. Most people don't see that they can get a significant speedup in using debuggers, so that sentence wanted to give a sense on how much quicker you can be. I'd be happy to hear of a better way to convince a non-debugger user that he could have debugged this code faster with a debugger!

This is such a good idea! I love the concept of an MVP to quickly test your business ideas. However it's usually painful to rapidly test an idea in the web world. The fact that I can run such a test so quickly is amazing. Keep it up!