191–200 of 385 posts
Earlier quoted context omitted.
Man that is a whole lot of fluff to differentiate between being able to hire and fire. I wonder what Tim would do.
So your mind is made up that someone fictional who is not described in a blog post does not contribute to an org you know nothing about? Is your point that all management is useless? Or something else? And why are you certain, what is your experience running a team or a company? Maybe the sarcasm isn’t communicating your point effectively?
Earlier quoted context omitted.
I had a director that was obsessed with github enterprise stats. He forbid people from squashing commits and told people to commit every day, even if you're in the middle of something. This was so that he could see who was writing the most code. One of our interns was close to the end of his term and this director wanted to hire him. He thought the intern was amazing based on the amount of code he wrote. The problem…
Reminds me of a manager and a QA I once knew. QA was a nice guy, but a terrible QA. Would fail stories on the most arbitrary guidelines. Story is about changing the font size on the home page? He'd fail it because he wasn't able to log in (he tested while the auth service was undergoing planned maintenance). Manager loved this guy, and pushed him through several promotions. Eventually other employees got tired of bei…
Earlier quoted context omitted.
In a lot of companies the definition of senior engineer helping others develop technical skills.
In a few of those companies, so also is the job.
Honest Question: Are there any metrics around developer productivity that actually work? Reading stories like this and others over the years I've come to the conclusion that you simply can't measure developers productivity on a granular level, it's just about the final product. However, I would love to be proven wrong.
These sort of stories seem to be dime a dozen and weirdly celebrated around HN and the software engineering community. We’re told of the hero, who goes against their managers and executives and doesn’t deliver any stories as agreed in sprints. We’re told of the engineer who isn’t hired by Google because he can’t invert a binary tree. Everyone else piles on and decree that, yes indeed, you cannot measure developer eff…
People of a revolutionary (or "innovative") temperament are those who are going to say, "this system doesnt work, these processes are broken, the wrong outcomes arise" and ignore them. In doing so they just "do the right thing" in their judgement, and in so doing, develop the next iteration on the processes that others will follow. If these innovators are operating in a niche where innovation is required, they are so…
If I may latch on to your first paragraph, my point is that we are saying this first bit “this system is broken” and are happy to throw out the baby with the bath water and tear it all apart, on flimsy evidence and generalisations.
And yes, there’s definitely something to be said about the HN crowd having a temperament toward innovation, but I don’t think that’s in any way orthogonal to my point. In fact, this community is far more rational than most others, so I would sort of expect us to rationally look at company processes too, but for some reason we seem to have a blind spot when it comes to our managers and executives and the ‘horrors and hoops’ they make us jump through every day.
These sort of stories seem to be dime a dozen and weirdly celebrated around HN and the software engineering community. We’re told of the hero, who goes against their managers and executives and doesn’t deliver any stories as agreed in sprints. We’re told of the engineer who isn’t hired by Google because he can’t invert a binary tree. Everyone else piles on and decree that, yes indeed, you cannot measure developer eff…
> We’re told of the hero, who goes against their managers and executives and doesn’t deliver any stories > Meanwhile in the real world, hordes of awful engineers deliver no story points Do you think the point here is that not delivering on one specific metric is a good thing, or that not delivering one specific metric can't be assumed to be the whole picture?
The blog poster could’ve asked, why does the manager want me to deliver the story points? It’s because Jake is also delivering zero story points and he’s a terrible engineer and it’s a good canary metric.
Earlier quoted context omitted.
I had a director that was obsessed with github enterprise stats. He forbid people from squashing commits and told people to commit every day, even if you're in the middle of something. This was so that he could see who was writing the most code. One of our interns was close to the end of his term and this director wanted to hire him. He thought the intern was amazing based on the amount of code he wrote. The problem…
> who was writing the most code There's yer problem right there. Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. Measuring productivity by lines of code produced actively discourages writing clean, maintainable, bug-free code.
Earlier quoted context omitted.
Dev productivity is like quantum mechanics. The second you try to measure it, the wave function collapses, and you've fundamentally altered the thing you were trying to measure. That said, at every place I've worked you could get a starting point idea of who the top devs were by looking at overall code commits. This Tim sensei situation may be more common than I think, but I've never run into it.
> That said, at every place I've worked you could get a starting point idea of who the top devs were by looking at overall code commits Yea, in the current place I work at we do not measure coding performance metrics, but if you look at the top commiters to the repo — by number of commits — you will see all of the people who bring the most value to the company. Even at staff eng the best engineers are still the ones…
Earlier quoted context omitted.
> who was writing the most code There's yer problem right there. Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. Measuring productivity by lines of code produced actively discourages writing clean, maintainable, bug-free code.
> Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. ** "No Code" or Nihilist Software Engineering ** No code runs faster than no code. No code has fewer bugs than no code. No code uses less memory than no code. No code is easier to understand than no code. No code is the best way to have secure and reliable applications. Write…
It's is exactly what I was needing for this slide deck on I'm writing how to improve our code.
Earlier quoted context omitted.
> because that's an unacceptable level of blockage. You shound like a manager. Let me know when you identify and quickly solve all the reasons that the team frequently gets blocked. Until then, we have Tim.
> You sound like a manager. Yeah, I think that's a good read. Give management credit for being smart. They mostly do manage only to promote the most egregiously avid Taylorites from among us.
Respectfully, this is being the exact opposite of smart. Pay attention to the fact that by all accounts the Tim role is actually a force multiplier and output booster for the team. Pay also attention to the fact that you're arguing that Tim should be fired as should the whole team just because... Your Jira metrics are off? This is not what I would call being smart, by far.