> By triangulating these [...] numbers [...], I can tell if a software engineer is truly fast, or just simply slow. It seems that Mr. Casey Cobb is more intere

> By triangulating these [...] numbers [...], I can tell if a software engineer is truly fast, or just simply slow. It seems that Mr. Casey Cobb is more interested in micromanagement of his engineers and monitoring of their performance than value the experience of them. Yes, he talked about having a good understanding of the topic is crucial, but engineers that have 95% of the time a correct estimate rises a red flag. I guess the engineers have a quite narrow scope to implement things in so it's quite "easy" to estimate the cost of the feature in question. Let me tell you from my day-to-day work: I'm honest and transparent with my workload but because of the wide scope I have to operate in my estimates are more or less accurate. But that's ok! Because of the planning we're doing, the communication we're having and the transparency we live we can always explain why things go so fast or slow. We're adjusting the goals as required and that's it. No big management, no micromanagement, no one that sits on your shoulder just to ask if you're truly fast, or just simply slow. We have only engineers in our team that want to build good software so we can skip the fingerpointing and poisoning (not that project ricochet has that problem.). > ... if you're truly fast, or just simply slow oh man...