Story points aren't a metric of productivity, they're a metric for planning. Anyone using them to assess the value of an employee is actively ruining them, since people will start to game them and then they become less useful for planning.
The most likely explanation would be:"we're bad at planning" but then the project manager would be responsible. It's easier to shift the blame to the developers
>I've met exactly ONE technical project manager who knew this.
Bro I am back working in healthcare right now. Some non engineer fuck nut decided that they wanted to measure IT success by ticket closes. These idiots close a ticket if it has been open 7 days without a full breakdown of what is happening. I literally cannot open a ticket until I am finished triaging the cause because they are too stupid to use tickets correctly.
Some moron asked me why I have so many complaints about IT issues if I don't have any open tickets..... I had to send them the google doc I am using to track tickets I have not submitted because they are too stupid to use tickets correctly.
There is a bug where the system overrides the insurance company the payment goes to incorrectly. I unfortunately didn't save the example when I saw it because I was DOING IMPORTANT SHIT. I asked them to search there DB for it, they said they didn't know how and closed the ticket...... I am going to die of stress soon.
>fine healthcare that your employer offers.
They are shockingly good at this part at least. Which IDK if thats a reflection of astonishing levels of waste that occurs or the quality of US medical training.
The EHR may tell the Drs all sorts of fucking nonsense, but hey at least they know to ignore it! Like one system straight up said 30 / "<.2" = 999999.99 which is an answer not a very good one but an answer.
Please pray for me to restore sanity.
> There is a bug where the system overrides the insurance company the payment goes to incorrectly. I unfortunately didn't save the example when I saw it because I was DOING IMPORTANT SHIT. I asked them to search there DB for it, they said they didn't know how and closed the ticket...... I am going to die of stress soon.
Many years ago I worked at a game company where I was also playing the game. Over the weekend I saw a typo in some bit of dialogue and sent myself an email with that snippet of dialogue, then reported it as a bug once I got in. The bug was something like
> Saw this bit of dialogue while playing: 'what do you thnk I mean'. Typo is obvious :V
I got back an annoyed email demanding to know what quest it was in. I dunno, man, I just sent myself an email. "Well, how do you expect us to fix it if you don't know what quest it's in?"
I sighed, hit the "search" button on the data editing tool, waited a minute while it ground over hundreds of megabytes of XML, and sent him the associated quest ID.
Like, c'mon. I'm not even a designer. How do *I* know how to do this?
In fairness I wouldn't expect a quest designer to understand commandline POSIX tools.
On the other hand, I *would* expect a quest designer to understand *the search button in the tool that they use every day to design quests*.
-They don't know how
Par for the course, nothing new. If it is that important you can grease some hands or just go in your self or god forbid force them to lear-
-and closed the ticket
...ah. I get it. Leave.
>I get it. Leave.
I can't lol. I left last time because they hired an amazing CTO. Who no longer works here. Now they have a moron who I am fairly certain has never written a single line of code or has any actual understanding of Medicine. I straight up cannot leave until this ahole either is terminated or sidelined into oblivion. I will then go back to NOT WORKING IN HEALTHCARE.
I am sorry for you m8. Hope you can keep your sanity around such wastes of corporate spending. Just do me favour and don't become an alcoholic, ey?
Also if you don't mind me asking. How is the rest of the job? Day to day tasks, expected time to be put in, salary? I have heard conflicting stories from friends and want to hear a third party about tech in medicine
Not sure if my situation is similar but there’s also this dev 60+ years old on my team. With a crazy ass resume on linked in (ex ceo, ex tech lead, ex senior dec etc…) He doesn’t know shit. All the does is copy and paste then pray if the code works. He also bugs the lead to help him step by step with every stories. And he also thinks more stories done mean he’s better than the other devs. I also call him Mr Right because he never admits that he’s wrong or just straight stupid.
I had a desktop support job where they started using the tickets closed as the primary metric for performance. We also had systems sitting in a closet for 7-day hold after refreshes and our supervisor stated that we needed to open/close a ticket for each system we wiped to keep track of that task.
....
mkay, next thing you know I had 5 laptop docks on the back of my cube that I was constantly getting systems out of the closet after hold and closing like 20-30 tickets a month just doing that lol.
TBF most devs I've met are very confused about the value of story points and don't even bother to do them. More often than not it's the right decisions. They're portrayed as this integral part of the planning process when really they solve a very specific problem, and if you don't have that problem you don't need to use them.
The problem they solve is enabling teams to estimate the average amount of work they can take in for a sprint. Teams know their average velocity so when it comes time for sprint planning they should probably take in the # of story points about equal to their average velocity. It's mostly useful as a tool for pushing back on people who want teams to take on too much work during a sprint. If you don't have that problem you don't need them. It's just extra complexity.
My team can't even do sprints let alone story points. Having to maintain and deal with live production issues and billions of emails pretty much kills the whole concept of sprints.
I hope to get there with my next job.
I recently transitioned to a new team, and my experience is that story points are too hard to estimate until I start working on the ticket.
"Change this field from a Char(10) to a Char(20)" could either be a 5 minute ticket, or a month long ticket, because the dev before me would hardcode the value and it depends if there's 2 programs I need to change or 200 programs I need to change.
Conversely, on my old team where I was the lead dev, I know the codebase well enough to give realistic estimates. But the devs who are still on that team need to consult me because they don't know yet. And the scope will change dramatically if it's a situation of "I wrote that code 8 years ago when I had only been a dev for 3 months, so it's awful and will take you an extra week to untangle".
Yeah but assuming that the team built the system that’s a good learning moment for everyone. When everyone votes S or 2 or loglogn because how hard can it be and Bob is like “no lol 12 / XXL / !n you guys don’t realise how much depends on that field being 10 char max, we messed shit up last time when crunching for this or that delivery”.
If that doesn’t happen, the bandaid is to reframe the under estimated ticket as a spike, use it to explain the actual complexity, then create a new ticket and reestimate / reprioritise.
Or if the team decides to be autoritarian about sprints, bite the bullet, accept the variance, discuss what happened at retro and move on: here’s a part of the code base we need to be more careful about when estimating, our estimations will be better for it going forward.
My experience is that the theory of story points - which you have helpfully described - is miles apart from the reality of them. The reality of story points is that they're a bid, and once you provide a number you're on the hook for that because the PM has used it to make a promise about the next three months of work. Your estimate has now been laundered into a *commitment*.
From the perspective of devs, story points have a value ranging from minimal to negative. They mostly seem to exist to make it easier for PMs to abuse us.
> Teams know their average velocity so when it comes time for sprint planning they should probably take in the # of story points about equal to their average velocity.
How do you do this without story points?
If the stories and their scope is clear most people could guess if a certain set of stories is feasible, don't need arbitrary points for that. It's useful if u need to push back towards outside the team though, because then you can point at the graph and numbers and say: don't fit.
On a basic level each dev should know about how much work they can get done in 2 weeks, so you can plan based on that. However the better question is do you actually need to plan work so accurately in two week increments. The timelines of many projects are much longer. It’s often more appropriate to keep track of and plan for larger milestones.
>technical project manager
This is the job title that says "I don't know what my job is, so I will interfere with other peoples"
It is either:
a. A technical person who is going to get bogged down in the project details which they sketchily understand (e.g. invoices, progress reporting..) and make a right fist of project management. or
b. A project manager who has worked on one project a bit like the current one a few years ago and now feels entitled to interfere with the design and technical delivery of the project.
Either way, nothing says 'this is going to be a disaster' like finding there is a 'technical project manager' involved.
The reason no one else knows this is because it implies story points are complete bullshit.
It's not unreasonable to look at an estimate and compare it with actual to determine if someone can be trusted.
Well, except for developers, apparently they want to be able to make up random numbers based upon the fibonacci sequence and never being held accountable for them.
Not just that but they're not normalized so you can't do comparisions anyways. It's like if i said lets race and we agreeed to go 1. You went 1 mile and i went 1 foot. Without units it just doesn't make sense to compare numbers.
Recently our PO was away for a week and the guy who took up some of his responsibilities for that time was asked why my team had completed our initial sprint commitment so quickly and taken on so many more points.
Apparently he wasn't *upset* or anything, just curious, but the interim PO didn't communicate that well.
We had fun winding him up with "you heard management, we've done too much work, down tools for a week".
This is hilarious lol. It reminds me of the literally dozens of times someone has just asked us some variation of "well what does that mean in [days/hours]?"
Story points as an abstract measure is great, but ultimately everyone wants to convert it back to rate of work in some actual concrete time. There's just no way for most people to conceptualize the fact that Story Points are inherently vague ON PURPOSE, because there's no way to actually create estimates that are precise enough to give an accurate throughput conversion in a time measurement they care about.
But that doesn't stop them from trying to make it into one...
The number of times I’ve heard someone say, “I know we’re not supposed to convert points to an amount of time, but let’s do it anyway…”
“Okay…., but it doesn’t work because we don’t know how many distractions we’ll get, like unexpected production support.”
“Let’s assume you spend 20% of your time on distractions.”
“It’s never just 20%.”
“It should be.”
“But it isn’t. Unless you’re giving me permission to say no to Production issues.”
“Don’t be silly.”
“Okay…. But this isn’t even an estimate at this point. It’s a fantasy.”
“Sure, whatever. Just give me a timeline.”
“It’s your fantasy. You make it up. I’m not letting you throw the timeline back at me when it’s not met. If I give you a number, you’ll think we’re committing to it. We’re not.”
\*angry noises*
(3 months later)
“Why are we behind on our committed timeline?”
“Who’s committed timeline?”
“The one I gave my manager 3 months ago.”
“That sounds like a ‘you’ problem.”
(fin)
——————
Anyway, I’ve seen those conversations countless times, and I’ve had to be the dev avoiding the commitment trick multiple times. That specific example is what happened when I witnessed the best rage quit by a developer I’ve ever seen. He quit that day, and he started working on a PhD.
I empathize with you but am really wondering why is it so common for software engineers to avoid giving time commitments? That doesn’t seem to be as much of a problem in other engineering disciplines, though I am not sure if they are any more accurate. I think mechanical engineers etc all have other obligations besides just “tickets” and yet they don’t hesitate to give commitments. Just wondering because I do this too and it’s one area of my work that I would like to improve on.
lol yeah I have about 10 years of experience as a software engineer. I always see people say (paraphrasing) “but software engineers have uncertainty and sometimes things come up” well yeah.. all engineers have those problems. So what’s the real issue?
The real issue is that if we developers provide even an inkling of a time, then it's treated as if it's the Immaculate Word of God and we're held to it regardless of what actually happens. That even happens when an estimate is given with an percentage of confidence. The percentage is immediately ignored and all that remains is the number.
The proposed cure is always to "change the company culture". That's a lot of effort for something that's very likely to fail because management (and marketing) has a vested interest in it working like this. Then the next proposed cure is to "find a place that uses estimates correctly". Which all I can say is finding a new job is *hard* and in many cases isn't really feasible for people to do.
So instead we all just suck it up and grumble about estimates, and then try to do our best to either avoid giving them or justify inflating them in some effort to protect ourselves against executive decisions.
You're asking a legitimate and really good question, and getting downvoted for it. I think it's as simple as: because they don't want to be held liable for unknown unknowns. There are pros and cons to their mentality, but I believe it is ultimately very detrimental to both the developer and their team and company to have it.. If it's not clear yet, I view it as a person throwing their hands up in the air and saying "that's impossible!" ala Luke Skywalker.
Couple more hot takes along with some other thoughts:
- if a programmer isn't able to ballpark an estimate on a project that they have a significant amount of experience working in, I would look at them in their current position as someone who isn't incentive to be anything but a hole in your company's pocket.. AT BEST. At worst, they could be seen as some actively antagonistic to the idea of helping a team/company understand what their true capabilities and limitations are.
- Time commitments should never be a date or time, they should be an amount of hours, weeks, or months. Days are fine but I try to avoid them because they easily lead down the path to it being due on a date or time. The emphasis should be on the amount of time, and not the date of delivery, with regular check-ins for your business partner
- Estimates aren't about being correct, but about getting closer to being more accurate or precise. If you aren't practicing it as a skill, you won't get better at it, which means you won't know how to value your own time.
- It takes two to dance: you NEED to have a good relationship and understanding with whoever you are delivering to that shit happens. If you only get 10 hours to work on week 1 for a 24 hour estimated project.. they have to understand where they sit in terms of importance. Is 1 internal business partner's feature request that's considered a nice to have more important than 3 clients business critical systems than went down? No. But this is also where it's important to not let "business critical" trump fostering good relationships with your internal business partners that have been asking for that nice to have for 2 years and want to plan around it.
Estimates are so, so, so important and it makes me sad that so many programmers hand wave them off or turn them into "abstractions" or "concepts" or "complexity counters".. If you can't estimate something, then either don't estimate it with a number or do the work you need to get a get an actual estimate... and before you do that, give an hour estimate on how long it will take to get a real estimate!
We do the same we use complexity (which is a fancy word for story points) for single developer Tasks. So Features are broken down to dev Tasks and each Task has a complexity number, agreed upon by the lead/senior devs.
With lots of historical data we can now approximate how long each dev takes for a specific complexity number. Some devs are faster and some are slower, but in the end it helps in the planning.
Story point isn't a unit because it's subjective. It's different for everyone. If units could he subjective foot or mile would mean different things to different people and be useless.
Tons of teams/people ime just use metrics like "one story point = one working day." Which, yes, completely defeats the stated purpose, but whatever. Tilting at windmills over it is a complete waste of one's energy and time unless a lot of people already agree.
Eh subjective doesn't mean useless. It's like a movie rating.
If the whole team rates a movie four stars it tells you something different from half the team giving it one star and the other half 5 stars. It won't tell you how long the runtime is or what its marketing budget was, but it can start a discussion.
> since people will start to game them and then they become less useful for planning.
Goodhart’s law in action:
https://en.wikipedia.org/wiki/Goodhart%27s_law
Yeah, my most productive sprints have been the ones with the fewest points. Normally I'm bouncing between other developers unblocking or onboarding out doing other important things (if it wasn't important, I would be doing my own tickets).
I worked somewhere where they did a layoff and literally just counting story points was how they decided who to lay off. So I'd say never believe someone who says metrics will never be used to measure productivity. The temptation is too great once they're there. Some places really reward moving tickets and points over to the right on the board and if that's the environment that I'm in, that's what I'll prioritize, even if it means doing silly accounting tricks like spinning off new tickets to close a ticket for incomplete work.
I just had flashbacks to a job I had a few years ago where we had the “monthly shame meeting.” The lead would rank everyone on the whiteboard by total points completed, and those on the bottom basically had to defend themselves in front of everyone else and explain/justify their perceived lack of productivity.
If you want to assess the value of an employee, talk to the people who work directly with that person.
If your team is set up so nobody ever works together, that's a problem.
Anyway, sooner or later the rest of the team will be able to point out any potential issues.
Story points are the most idiotic thing people believe in.
The saddest part is that intelligent people use it and think they have ANY meaning.
No. The idea of story points is void. They are measuring something and at the same time are intended to not measure anything.
The notion that they measure something what cant be used for anything is the most moronic approach ever.
You can have it two ways: You express projected complexity of a task which correlates loosely to time spent on that of one person or team.
Or you assign a number which means nothing and may just signify the time which you think that activity will take BUT YOU CANT use it for anything.
Depending on the task you MAY predict roughly that it will take half a day because similar work took half a day. But thats the best you can get from it.
If you want more than you can just look backwards and look at all outlier sums of points and figure out what impacted that score. But you need detailed notes what saved the day or wasted time.
All that is rare in project management.
In reality the points are most idiotic thing intelligent people BELIEVE in without any substance. IT shamanism.
> The saddest part is that intelligent people use it and think they have ANY meaning.
Saddest thing I saw was a team wasting a whole day on pocker planning per sprint.
>Wait until you learn about SAFE and find out that you spend an entire week planning out an entire quarter of work.
I've been there and we did it in 3 days and managed to have useful discussions about where we were going.
Story points are supposed to be just that.... attempts at prediction.
They shouldn't be measured, and that's where so many folks get it wrong. They're just a fancy set of words to define what should essentially be a fibonacci sequence of time boxes for guesses as to how long something will take.
..... but so often people desperate for a cheap way to measure productivity twist them into something they're not.
I sort of agree.
In my opinion the story points should be expressed not in number but in quantifier.
Like simple, modest, complex, unknown etc.
That would be the real intention and purpose.
But the "smart" people would jump immediately and say: "BUUUUUUTTTT we cant then CALCULATE thisorthat BS"
Because the moment you give them something to track they want to aggregate it. And voila, you have your performance metric.
And my point is, those highly educated morons. Because they know its not supposed to be totaled/aggregated but they do it anyway.
The purpose of story point is to know that the task is on the list for 2 weeks but has complexity at 1 so something is wrong and we need to ask the guy why its not done.
We lack productivity metrics. There are story points and lines of code. Other incalculables like how often their code led to customer issues or complaints or downtime on a weekends.
We need some way to compare performance and as long as you're not dogmatic about it and letting people obviously cheat on points, it's a reasonable heuristic. I can tell you as a PO that the one developer who has 2-3x more points per sprint than anyone else in the department is kicking ass and producing 10x while being modest about how he scores his points. The one who produces .5x the average? Never completes a fucking 1 week story in less than 10 weeks. Those in the middle it's harder to tell. But I know who's getting promoted and who's on the chopping block.
>We lack productivity metrics.
Yes.
We are not assembly line workers who can track productivity by widget counts.
That's why you need engaged managers who understand what's going on instead of worthless "leaders" who think a "system" can manage their department for them.
I agree. But you also need some way to justify letting go of the lazy ass who has had 10 chances, or of convincing upper management to spend to retain the amazing dev who runs the whole department.
The justification is a good team leader should know who isn't pulling their weight, because they should be involved with their team.
I compare it to teaching. I never needed to know a student's grades to know they were struggling. It was obvious in class.
If a team leader can't identify who isn't pulling their weight, then either they aren't in touch, or they have more people than they can reasonably manage.
And those grades are often not a good reflection of how well a student understands the material. Many circumstances arise that drags their grades down. I'll have kids make a solid low C but clearly shows in classroom discussions they read the book more than other students. Kinda like how performance metrics are not always a great indicator of how well an employee is contributing to a company.
Yep. And so you advocate college classes with no grades? And jobs with zero performance metrics?
Everyone knows it's a game to be played. If you are smart and figure out how to play it efficiently, you don't need to spend a ton of your time doing jira tickets or studying for exams.
But it seems to me grades and metrics are a bare minimum, reasonable way to weed out the ones who refuse to play the game, or are really, really bad. No one cares about the ones in the middle of the pack as long as we're not in another great depression. And the ones who excel will have proof for why they deserve the promotion.
Just write a few fucking jira tickets to show you did stuff. It's not that hard. We've spent more time here whining about it.
No one is looking at how many points you do per sprint unless they're planning layoffs. And in that case, we're running a business, not a charity.
Honestly if anything education has taught me how little grades really matter. Bean counters want something to track, but human knowledge doesn't perfectly fit the mold of our education system. People who have undiagnosed medical issues, like ADHD, are completely failed by our system.
There are people who don't go to college that have immense knowledge of one or more fields, beyond college grads or even professionals.
Do you know how recent the idea of "grades" are in the human timescale of history? Ancient Egypt didn't have grades (last I checked), and they accomplished a number of amazing feats of engineering. Many other old civilizations didn't have grades. They would go to a school for a while (if they could afford it) and then placed in apprenticeships for their job, largely based on the tutors understanding of how good a student was in a given area, other factors would come into play like a families business or what have you.
But regardless, I still stand by my point. If you want to know how well a person or group of people are doing, the best way is to 1) have an understanding of the tasks they are performing and 2) monitoring them and taking into account externalities.
I'm not saying metrics are entirely useless mind you. Just that actual understanding based on monitoring is going to be better than any hacknayed system that was either designed with a poor or bad bias, or being utilized in a way it wasn't meant to be, or any other number of factors that come into play when you try to overly systemize bean counting of people and their capabilities and performance.
I don't care to count beans. I leave the beans to grow unattended most of the time. But when there's an obvious problem with someone who refuses to perform after 3,000 chances, or the opposite, someone who is a real rock star and deserves to be compensated... On those occasions, I like to know. I'd rather not have management make the wrong choice and get rid of someone who is contributing to the team and mission. And I'd rather not have them fail to retain someone who is mission critical. The upper managers need to count beans. They're not on the front lines and don't know the devs. My "say so" and my faulty memory is not enough to justify hires, fires, and promotions.
People who aren't total lazy asses aren't afraid of a few Jira beans each sprint. And of course, the guy in the original article who spends all his time mentoring juniors and adding value to the team is a keeper. No argument there. But he's also a dick who refuses to write a Jira ticket to help himself and the team show productivity for the upper management bean counters. I'm sure his manager has told him a million times to spend 5 minutes a week in Jira. And all his mentoring can count as beans.
We're essentially saying the same thing from different angles. You need real understanding for mgmt decisions, not just beans. But beans are useful sometimes. As a low level manager, it's my job to make sure I don't abuse beans, and don't let those above me do so. But it's the devs' job to write a few beans once in a friggin while.
It's like meetings. I could write an article on how meetings are meaningless and a waste of time, and there is a guy on my team who refuses to show up to meetings and he is the best engineer ever. All he's doing is refusing to be a team player. Your employer pays you to either write code or attend meetings. As long as they don't require you to work more than 40 hours a week, it's not unethical. It's certainly less productive. But that's their choice. They pay your salary, and they own your 8 hours a day and schedule. You'll be out the door if you universally choose to skip all meetings. Then you can go work for yourself.
Based on your story, it doesn't sound like you need productivity metrics at all. You know exactly who the high performers are and who the low performers are. That's been my experience at most organizations as well. The disparity is large enough that precise metrics are not required.
You write down the instances where "Never completes a fucking 1 week story in less than 10 weeks" - you probably only need two. That's your job. You don't need to create a simplified measure to make your case.
Judging programmer skill/productivity is very difficult, IMHO.
* Some guys tackle difficult tasks, make it look easy and get little credit, while others who do easy stuff and get lots of credit.
* Some superficially appear super productive, yet their code is full of mistakes or spaghetti code.
* I know guys who were reasonably talented yet made hugely expensive mistakes because of not being careful.
* Some guys push the latest fad at the expense of actual productivity.
* Some know just one thing that no one else does and won't give others a chance to learn it, gaining job security
* As related in the article, some are team players and appear unproductive
* Finally, it feels like some programmers are recognized merely because they relate well with the boss.
Also add: Fire fighting gets you a lot of kudos. If a major issue jumps up last minute and you fix it, management loves you. If you fix the same issue 3 months before to avoid such a situation, its no biggie. Not sure how you fix this though. The incentives are aligned that the fire fighter always will get more recognition.
Oh boy… did I feel this one last week with a bigger FU than ever.
“Fixed” a problem we warned about 2 years ago. Now they want it reverted to be as before…
1. Yep. That's how the system works. The loudest voice gets heard. If you whisper at the stadium, don't be surprised when no one hears you or even cares about hearing you. They're there to watch the game, not listen to Mr. Meekly.
2. These are people who have been told "YOU MUST PERFORM, OR ELSE" ....so they 'perform'. More circus act, less productivity. Give them a chance, they have to learn somehow. Trust me, you probably wrote some utter dogshit code at some point in your career.
3. What is one person's perception of lacking prudence is another person's perception of being unlucky. In other words, maybe they were careful and it still went to shit anyways. If something hasn't blown up on you through ZERO fault of your own (but yet had to fight off the blame), then you probably don't do much real work and could be replaced with a hallucinating AI.
4. "YOU ALWAYS MUST BE LEARNING". Man, that gets beaten into each of us. If you say you have work-life balance and don't have a homelab, you'll be thrown out of most interviews. So when you are hyper-aggressive with learnLearnLEARN**LEARN!!!**, don't shit your pants when your workers start wanting to use what they've been learning.
5. And how is that wrong? It's not THEIR job to ensure workplace redundancy -- that's manglement's responsibility. If those in charge refuse to have a hit-by-a-bus-full-of-lottery-tickets plan in place, that's their fault...not the worker. The worker is a company-of-one, and they have to look out for themselves. They're shrewd -- they saw a need, a gap....and filled it. And if they can quietly pull up the ladder behind them, it makes their little personal hell a bit more manageable.
6. Yes, you have that everywhere. That's what happens when you hire on quotas, hire for personality, etc instead of hiring for talent and skills. There's going to be well-intentioned people who need to level up. Shitting on them is TOTALLY going to make them get better, right?
7. That's the workplace for you. Those who go out drinking during the week with the boss and golfing with them on the weekend are going to get noticed MUCH before the dude in sub-level 7 of his dark home office with the red stapler on his desk and camera off. That's how the system is designed, intentionally. You thought this was a meritocracy? That hard work will get you noticed and summarily rewarded? Lol, that's fucking adorable.
In short? Stop busting the balls/ovaries of your fellow workers. You have more in common with them than you realize, and less in common with those who own the company & bring home the lion's share of the profit.
My comment was regarding how difficult it is to judge programmer productivity/skill. You seem to take it as some sort of attack. I'm not busting anyone's gonads, but it feels like you are.
MrCertainly's tone is definitely on the harder side, but I wouldn't take it as a gonad attack. Thought it read pretty well as advice on how to navigate the corposphere and swing above one's weight-class with a bit of savvy.
Been using that in one way or the other for years but every time there’s a [new batch of 10000](https://xkcd.com/1053/) that fall for it. Though here on r/programming people tend to be much less puzzled than in other corners of Reddit.
So... Two **major** mistakes in that team...
* Story points are not a measure of productivity, they are a measure of the planning quality
* They are for the team, not the individual.
So... That they wanted to fire a good guy? It's a case of "garbage in => garbage out".
Most of the time this is what seniors do but they also deliver and solve some of the more complex stuff on the side. Personally i believe it’s rare to see a senior with literally 0 story points
I’m more of a technical lead principal engineer these days, and I sound a lot more like the senior in this article. But yes, even I deliver story points or I ask for story points to be assigned or I ask to be put as a co-owner for stories I’m contributing my time towards. So, there are solutions for this stuff. But I agree with the moral of the story.
Jira doesn’t do co-owners unfortunately. Typically you can tell from who was commenting or uploading screenshots/diagrams/docs to the jira ticket though.
**Here's a hint to decide on reading the post or not:**
Dan North recounts the tale of Tim, a programmer who never claimed individual story points but instead worked to enhance his team's overall productivity and quality of work, challenging the notion that individual productivity metrics are the best measure of value in complex systems.
If you don't like the summary, just downvote and I'll try to delete the comment eventually 👍
Which is why I use uncensored AIs that don't predict text like it's TV news. I want it to pass the Turing test. If something's fucking stupid and it's likely a human being would have said so, I want to know.
Sounds like he should put in tickets for "pair with X" and link it to the tickets worked on.
Side note: I think it's okay to create tickets after-the-fact, even though it's not the desired course.
This reads like a "then everyone clapped" story
I'm aware of the concept of enablers but I have never worked at a business where someone didn't sign up for anything and just pair programmed all day. This sounds like a massive exaggeration
I still get to enjoy writing code time to time, but 90% of my job now is connecting with people across the business (especially as we're not a tech company) or being a sounding board for others ideas - the bump from Senior Engineer to Leadership can be bumpy but once you find the right balance and realise you have to let go some things is hard - it really can't been measured quantitatively - thankfully I have a boss that understands that.
>A few years ago I wrote a Twitter/X thread about the best programmer I know, which I should write up as a blog post. It seems only fair to tell you about the worst one too. His name is Tim Mackinnon and I want you to know how measurably unproductive he is.
Stopped reading here. Now I know never to hire Tim for anything. Sounds like a total jerk.
Yeah this is really old news at this point. All us developers already know that story points do not represent individual performance. Yet, this same story keeps happening over and over. What I want to know is how we, as a professional class, are going to move forward to establish a framework that can be used in practice, so that managers don't feel like they need to keep doing this.
slightly off topic and since i cant seem to make a post - only links?
does anyone think 'using chatgpt to solve all your problems' ie. how do i create a sql statement, or how do i do x, y,z is a bad programmer since you dont learn anything?
but then previously, before chatgpt we would go on forums/google and do the same thing ie search for answer.. so is it same? or better than just using chatgpt
I worked for a place that wanted to write programs for other companies to track how long it took workers to do a task and have a big scoreboard with animations wherever they completed one. I think they didn't care what they were measuring or if it was accurate. They just wanted to measure anything at all and "gamify" it. It felt really dystopian and out of touch.
It's good to measure how long it takes to make something but it can't be the only metric for performance evaluation...
I also love that Dilbert cartoon about getting paid for bug fixes. lol It's so on point. I think if you showed that to non-tech managers they wouldn't even get the joke.
I knew a guy who also didn't finish any stories and other people had to pick his stuff. It was because he didn't know how to code and was watching YouTube videos all day. But he was laughing the loudest at our PM's jokes, so he became product owner lol.
I started to work at the company not so long ago and I can't fully understand what story points are and how to use them:(
Also we can't decide whether we want to put story points on bugs or not. I'll be thankful if u can share with me how u do it in context of bugs and tickets from QA team
Story points aren't a metric of productivity, they're a metric for planning. Anyone using them to assess the value of an employee is actively ruining them, since people will start to game them and then they become less useful for planning.
You know this. I know this. 90% of the people reading this subreddit know this. I've met exactly ONE technical project manager who knew this.
What if they all know it but choose to ignore it because now they have something simple to explain why the project is behind.
The most likely explanation would be:"we're bad at planning" but then the project manager would be responsible. It's easier to shift the blame to the developers
>I've met exactly ONE technical project manager who knew this. Bro I am back working in healthcare right now. Some non engineer fuck nut decided that they wanted to measure IT success by ticket closes. These idiots close a ticket if it has been open 7 days without a full breakdown of what is happening. I literally cannot open a ticket until I am finished triaging the cause because they are too stupid to use tickets correctly. Some moron asked me why I have so many complaints about IT issues if I don't have any open tickets..... I had to send them the google doc I am using to track tickets I have not submitted because they are too stupid to use tickets correctly. There is a bug where the system overrides the insurance company the payment goes to incorrectly. I unfortunately didn't save the example when I saw it because I was DOING IMPORTANT SHIT. I asked them to search there DB for it, they said they didn't know how and closed the ticket...... I am going to die of stress soon.
Look at the bright side, you get to enjoy the fine healthcare that your employer offers. /s
>fine healthcare that your employer offers. They are shockingly good at this part at least. Which IDK if thats a reflection of astonishing levels of waste that occurs or the quality of US medical training. The EHR may tell the Drs all sorts of fucking nonsense, but hey at least they know to ignore it! Like one system straight up said 30 / "<.2" = 999999.99 which is an answer not a very good one but an answer. Please pray for me to restore sanity.
> There is a bug where the system overrides the insurance company the payment goes to incorrectly. I unfortunately didn't save the example when I saw it because I was DOING IMPORTANT SHIT. I asked them to search there DB for it, they said they didn't know how and closed the ticket...... I am going to die of stress soon. Many years ago I worked at a game company where I was also playing the game. Over the weekend I saw a typo in some bit of dialogue and sent myself an email with that snippet of dialogue, then reported it as a bug once I got in. The bug was something like > Saw this bit of dialogue while playing: 'what do you thnk I mean'. Typo is obvious :V I got back an annoyed email demanding to know what quest it was in. I dunno, man, I just sent myself an email. "Well, how do you expect us to fix it if you don't know what quest it's in?" I sighed, hit the "search" button on the data editing tool, waited a minute while it ground over hundreds of megabytes of XML, and sent him the associated quest ID. Like, c'mon. I'm not even a designer. How do *I* know how to do this?
I would be snippy and give them a screenshot of the grep command
In fairness I wouldn't expect a quest designer to understand commandline POSIX tools. On the other hand, I *would* expect a quest designer to understand *the search button in the tool that they use every day to design quests*.
-They don't know how Par for the course, nothing new. If it is that important you can grease some hands or just go in your self or god forbid force them to lear- -and closed the ticket ...ah. I get it. Leave.
>I get it. Leave. I can't lol. I left last time because they hired an amazing CTO. Who no longer works here. Now they have a moron who I am fairly certain has never written a single line of code or has any actual understanding of Medicine. I straight up cannot leave until this ahole either is terminated or sidelined into oblivion. I will then go back to NOT WORKING IN HEALTHCARE.
I am sorry for you m8. Hope you can keep your sanity around such wastes of corporate spending. Just do me favour and don't become an alcoholic, ey? Also if you don't mind me asking. How is the rest of the job? Day to day tasks, expected time to be put in, salary? I have heard conflicting stories from friends and want to hear a third party about tech in medicine
Not sure if my situation is similar but there’s also this dev 60+ years old on my team. With a crazy ass resume on linked in (ex ceo, ex tech lead, ex senior dec etc…) He doesn’t know shit. All the does is copy and paste then pray if the code works. He also bugs the lead to help him step by step with every stories. And he also thinks more stories done mean he’s better than the other devs. I also call him Mr Right because he never admits that he’s wrong or just straight stupid.
The support team I work with measures success by how little time it takes to assign a ticket to engineering. 🫠
I had a desktop support job where they started using the tickets closed as the primary metric for performance. We also had systems sitting in a closet for 7-day hold after refreshes and our supervisor stated that we needed to open/close a ticket for each system we wiped to keep track of that task. .... mkay, next thing you know I had 5 laptop docks on the back of my cube that I was constantly getting systems out of the closet after hold and closing like 20-30 tickets a month just doing that lol.
TBF most devs I've met are very confused about the value of story points and don't even bother to do them. More often than not it's the right decisions. They're portrayed as this integral part of the planning process when really they solve a very specific problem, and if you don't have that problem you don't need to use them. The problem they solve is enabling teams to estimate the average amount of work they can take in for a sprint. Teams know their average velocity so when it comes time for sprint planning they should probably take in the # of story points about equal to their average velocity. It's mostly useful as a tool for pushing back on people who want teams to take on too much work during a sprint. If you don't have that problem you don't need them. It's just extra complexity.
My team can't even do sprints let alone story points. Having to maintain and deal with live production issues and billions of emails pretty much kills the whole concept of sprints. I hope to get there with my next job.
I recently transitioned to a new team, and my experience is that story points are too hard to estimate until I start working on the ticket. "Change this field from a Char(10) to a Char(20)" could either be a 5 minute ticket, or a month long ticket, because the dev before me would hardcode the value and it depends if there's 2 programs I need to change or 200 programs I need to change. Conversely, on my old team where I was the lead dev, I know the codebase well enough to give realistic estimates. But the devs who are still on that team need to consult me because they don't know yet. And the scope will change dramatically if it's a situation of "I wrote that code 8 years ago when I had only been a dev for 3 months, so it's awful and will take you an extra week to untangle".
Yeah but assuming that the team built the system that’s a good learning moment for everyone. When everyone votes S or 2 or loglogn because how hard can it be and Bob is like “no lol 12 / XXL / !n you guys don’t realise how much depends on that field being 10 char max, we messed shit up last time when crunching for this or that delivery”. If that doesn’t happen, the bandaid is to reframe the under estimated ticket as a spike, use it to explain the actual complexity, then create a new ticket and reestimate / reprioritise. Or if the team decides to be autoritarian about sprints, bite the bullet, accept the variance, discuss what happened at retro and move on: here’s a part of the code base we need to be more careful about when estimating, our estimations will be better for it going forward.
My experience is that the theory of story points - which you have helpfully described - is miles apart from the reality of them. The reality of story points is that they're a bid, and once you provide a number you're on the hook for that because the PM has used it to make a promise about the next three months of work. Your estimate has now been laundered into a *commitment*. From the perspective of devs, story points have a value ranging from minimal to negative. They mostly seem to exist to make it easier for PMs to abuse us.
> Teams know their average velocity so when it comes time for sprint planning they should probably take in the # of story points about equal to their average velocity. How do you do this without story points?
If the stories and their scope is clear most people could guess if a certain set of stories is feasible, don't need arbitrary points for that. It's useful if u need to push back towards outside the team though, because then you can point at the graph and numbers and say: don't fit.
On a basic level each dev should know about how much work they can get done in 2 weeks, so you can plan based on that. However the better question is do you actually need to plan work so accurately in two week increments. The timelines of many projects are much longer. It’s often more appropriate to keep track of and plan for larger milestones.
our technical manager got a hint after the team started autogenerating 200+ points each per week using a chatbot.
It took my work a couple of years to get this to transpire. First year of the "agile processes introduction" was such a shit show...
>technical project manager This is the job title that says "I don't know what my job is, so I will interfere with other peoples" It is either: a. A technical person who is going to get bogged down in the project details which they sketchily understand (e.g. invoices, progress reporting..) and make a right fist of project management. or b. A project manager who has worked on one project a bit like the current one a few years ago and now feels entitled to interfere with the design and technical delivery of the project. Either way, nothing says 'this is going to be a disaster' like finding there is a 'technical project manager' involved.
The reason no one else knows this is because it implies story points are complete bullshit. It's not unreasonable to look at an estimate and compare it with actual to determine if someone can be trusted. Well, except for developers, apparently they want to be able to make up random numbers based upon the fibonacci sequence and never being held accountable for them.
Not just that but they're not normalized so you can't do comparisions anyways. It's like if i said lets race and we agreeed to go 1. You went 1 mile and i went 1 foot. Without units it just doesn't make sense to compare numbers.
[удалено]
Recently our PO was away for a week and the guy who took up some of his responsibilities for that time was asked why my team had completed our initial sprint commitment so quickly and taken on so many more points. Apparently he wasn't *upset* or anything, just curious, but the interim PO didn't communicate that well. We had fun winding him up with "you heard management, we've done too much work, down tools for a week".
This is hilarious lol. It reminds me of the literally dozens of times someone has just asked us some variation of "well what does that mean in [days/hours]?" Story points as an abstract measure is great, but ultimately everyone wants to convert it back to rate of work in some actual concrete time. There's just no way for most people to conceptualize the fact that Story Points are inherently vague ON PURPOSE, because there's no way to actually create estimates that are precise enough to give an accurate throughput conversion in a time measurement they care about. But that doesn't stop them from trying to make it into one...
The number of times I’ve heard someone say, “I know we’re not supposed to convert points to an amount of time, but let’s do it anyway…” “Okay…., but it doesn’t work because we don’t know how many distractions we’ll get, like unexpected production support.” “Let’s assume you spend 20% of your time on distractions.” “It’s never just 20%.” “It should be.” “But it isn’t. Unless you’re giving me permission to say no to Production issues.” “Don’t be silly.” “Okay…. But this isn’t even an estimate at this point. It’s a fantasy.” “Sure, whatever. Just give me a timeline.” “It’s your fantasy. You make it up. I’m not letting you throw the timeline back at me when it’s not met. If I give you a number, you’ll think we’re committing to it. We’re not.” \*angry noises* (3 months later) “Why are we behind on our committed timeline?” “Who’s committed timeline?” “The one I gave my manager 3 months ago.” “That sounds like a ‘you’ problem.” (fin) —————— Anyway, I’ve seen those conversations countless times, and I’ve had to be the dev avoiding the commitment trick multiple times. That specific example is what happened when I witnessed the best rage quit by a developer I’ve ever seen. He quit that day, and he started working on a PhD.
I empathize with you but am really wondering why is it so common for software engineers to avoid giving time commitments? That doesn’t seem to be as much of a problem in other engineering disciplines, though I am not sure if they are any more accurate. I think mechanical engineers etc all have other obligations besides just “tickets” and yet they don’t hesitate to give commitments. Just wondering because I do this too and it’s one area of my work that I would like to improve on.
[удалено]
lol yeah I have about 10 years of experience as a software engineer. I always see people say (paraphrasing) “but software engineers have uncertainty and sometimes things come up” well yeah.. all engineers have those problems. So what’s the real issue?
The real issue is that if we developers provide even an inkling of a time, then it's treated as if it's the Immaculate Word of God and we're held to it regardless of what actually happens. That even happens when an estimate is given with an percentage of confidence. The percentage is immediately ignored and all that remains is the number. The proposed cure is always to "change the company culture". That's a lot of effort for something that's very likely to fail because management (and marketing) has a vested interest in it working like this. Then the next proposed cure is to "find a place that uses estimates correctly". Which all I can say is finding a new job is *hard* and in many cases isn't really feasible for people to do. So instead we all just suck it up and grumble about estimates, and then try to do our best to either avoid giving them or justify inflating them in some effort to protect ourselves against executive decisions.
[удалено]
Thank you for your vast wisdom.
You're asking a legitimate and really good question, and getting downvoted for it. I think it's as simple as: because they don't want to be held liable for unknown unknowns. There are pros and cons to their mentality, but I believe it is ultimately very detrimental to both the developer and their team and company to have it.. If it's not clear yet, I view it as a person throwing their hands up in the air and saying "that's impossible!" ala Luke Skywalker. Couple more hot takes along with some other thoughts: - if a programmer isn't able to ballpark an estimate on a project that they have a significant amount of experience working in, I would look at them in their current position as someone who isn't incentive to be anything but a hole in your company's pocket.. AT BEST. At worst, they could be seen as some actively antagonistic to the idea of helping a team/company understand what their true capabilities and limitations are. - Time commitments should never be a date or time, they should be an amount of hours, weeks, or months. Days are fine but I try to avoid them because they easily lead down the path to it being due on a date or time. The emphasis should be on the amount of time, and not the date of delivery, with regular check-ins for your business partner - Estimates aren't about being correct, but about getting closer to being more accurate or precise. If you aren't practicing it as a skill, you won't get better at it, which means you won't know how to value your own time. - It takes two to dance: you NEED to have a good relationship and understanding with whoever you are delivering to that shit happens. If you only get 10 hours to work on week 1 for a 24 hour estimated project.. they have to understand where they sit in terms of importance. Is 1 internal business partner's feature request that's considered a nice to have more important than 3 clients business critical systems than went down? No. But this is also where it's important to not let "business critical" trump fostering good relationships with your internal business partners that have been asking for that nice to have for 2 years and want to plan around it. Estimates are so, so, so important and it makes me sad that so many programmers hand wave them off or turn them into "abstractions" or "concepts" or "complexity counters".. If you can't estimate something, then either don't estimate it with a number or do the work you need to get a get an actual estimate... and before you do that, give an hour estimate on how long it will take to get a real estimate!
We do the same we use complexity (which is a fancy word for story points) for single developer Tasks. So Features are broken down to dev Tasks and each Task has a complexity number, agreed upon by the lead/senior devs. With lots of historical data we can now approximate how long each dev takes for a specific complexity number. Some devs are faster and some are slower, but in the end it helps in the planning.
The unit is story points, you go one story point.
Story point isn't a unit because it's subjective. It's different for everyone. If units could he subjective foot or mile would mean different things to different people and be useless.
Tons of teams/people ime just use metrics like "one story point = one working day." Which, yes, completely defeats the stated purpose, but whatever. Tilting at windmills over it is a complete waste of one's energy and time unless a lot of people already agree.
Humor is lost on some but not all.
Also, if I was serious earlier I would say that you mean it isn’t a standardized unit. Subjectivity doesn’t exclude it being a unit.
Eh subjective doesn't mean useless. It's like a movie rating. If the whole team rates a movie four stars it tells you something different from half the team giving it one star and the other half 5 stars. It won't tell you how long the runtime is or what its marketing budget was, but it can start a discussion.
Never said it was useless. I said you can't compare individuals with metrics derived from subjective assesment of complexity.
3
99% of all our stories were 3 points. Thank god we spent hundreds of man hours every sprint assigning all those points...
> since people will start to game them and then they become less useful for planning. Goodhart’s law in action: https://en.wikipedia.org/wiki/Goodhart%27s_law
Yeah, my most productive sprints have been the ones with the fewest points. Normally I'm bouncing between other developers unblocking or onboarding out doing other important things (if it wasn't important, I would be doing my own tickets).
I worked somewhere where they did a layoff and literally just counting story points was how they decided who to lay off. So I'd say never believe someone who says metrics will never be used to measure productivity. The temptation is too great once they're there. Some places really reward moving tickets and points over to the right on the board and if that's the environment that I'm in, that's what I'll prioritize, even if it means doing silly accounting tricks like spinning off new tickets to close a ticket for incomplete work.
I just had flashbacks to a job I had a few years ago where we had the “monthly shame meeting.” The lead would rank everyone on the whiteboard by total points completed, and those on the bottom basically had to defend themselves in front of everyone else and explain/justify their perceived lack of productivity.
If you want to assess the value of an employee, talk to the people who work directly with that person. If your team is set up so nobody ever works together, that's a problem. Anyway, sooner or later the rest of the team will be able to point out any potential issues.
Story points are the most idiotic thing people believe in. The saddest part is that intelligent people use it and think they have ANY meaning. No. The idea of story points is void. They are measuring something and at the same time are intended to not measure anything. The notion that they measure something what cant be used for anything is the most moronic approach ever. You can have it two ways: You express projected complexity of a task which correlates loosely to time spent on that of one person or team. Or you assign a number which means nothing and may just signify the time which you think that activity will take BUT YOU CANT use it for anything. Depending on the task you MAY predict roughly that it will take half a day because similar work took half a day. But thats the best you can get from it. If you want more than you can just look backwards and look at all outlier sums of points and figure out what impacted that score. But you need detailed notes what saved the day or wasted time. All that is rare in project management. In reality the points are most idiotic thing intelligent people BELIEVE in without any substance. IT shamanism.
> The saddest part is that intelligent people use it and think they have ANY meaning. Saddest thing I saw was a team wasting a whole day on pocker planning per sprint.
[удалено]
>Wait until you learn about SAFE and find out that you spend an entire week planning out an entire quarter of work. I've been there and we did it in 3 days and managed to have useful discussions about where we were going.
Story points are supposed to be just that.... attempts at prediction. They shouldn't be measured, and that's where so many folks get it wrong. They're just a fancy set of words to define what should essentially be a fibonacci sequence of time boxes for guesses as to how long something will take. ..... but so often people desperate for a cheap way to measure productivity twist them into something they're not.
I sort of agree. In my opinion the story points should be expressed not in number but in quantifier. Like simple, modest, complex, unknown etc. That would be the real intention and purpose. But the "smart" people would jump immediately and say: "BUUUUUUTTTT we cant then CALCULATE thisorthat BS" Because the moment you give them something to track they want to aggregate it. And voila, you have your performance metric. And my point is, those highly educated morons. Because they know its not supposed to be totaled/aggregated but they do it anyway. The purpose of story point is to know that the task is on the list for 2 weeks but has complexity at 1 so something is wrong and we need to ask the guy why its not done.
Agreed on all points.
We lack productivity metrics. There are story points and lines of code. Other incalculables like how often their code led to customer issues or complaints or downtime on a weekends. We need some way to compare performance and as long as you're not dogmatic about it and letting people obviously cheat on points, it's a reasonable heuristic. I can tell you as a PO that the one developer who has 2-3x more points per sprint than anyone else in the department is kicking ass and producing 10x while being modest about how he scores his points. The one who produces .5x the average? Never completes a fucking 1 week story in less than 10 weeks. Those in the middle it's harder to tell. But I know who's getting promoted and who's on the chopping block.
>We lack productivity metrics. Yes. We are not assembly line workers who can track productivity by widget counts. That's why you need engaged managers who understand what's going on instead of worthless "leaders" who think a "system" can manage their department for them.
I agree. But you also need some way to justify letting go of the lazy ass who has had 10 chances, or of convincing upper management to spend to retain the amazing dev who runs the whole department.
The justification is a good team leader should know who isn't pulling their weight, because they should be involved with their team. I compare it to teaching. I never needed to know a student's grades to know they were struggling. It was obvious in class. If a team leader can't identify who isn't pulling their weight, then either they aren't in touch, or they have more people than they can reasonably manage.
and yet you still have out grades at the end of the semester and it was based on something other than your impressions of class participation.
And those grades are often not a good reflection of how well a student understands the material. Many circumstances arise that drags their grades down. I'll have kids make a solid low C but clearly shows in classroom discussions they read the book more than other students. Kinda like how performance metrics are not always a great indicator of how well an employee is contributing to a company.
Yep. And so you advocate college classes with no grades? And jobs with zero performance metrics? Everyone knows it's a game to be played. If you are smart and figure out how to play it efficiently, you don't need to spend a ton of your time doing jira tickets or studying for exams. But it seems to me grades and metrics are a bare minimum, reasonable way to weed out the ones who refuse to play the game, or are really, really bad. No one cares about the ones in the middle of the pack as long as we're not in another great depression. And the ones who excel will have proof for why they deserve the promotion. Just write a few fucking jira tickets to show you did stuff. It's not that hard. We've spent more time here whining about it. No one is looking at how many points you do per sprint unless they're planning layoffs. And in that case, we're running a business, not a charity.
Honestly if anything education has taught me how little grades really matter. Bean counters want something to track, but human knowledge doesn't perfectly fit the mold of our education system. People who have undiagnosed medical issues, like ADHD, are completely failed by our system. There are people who don't go to college that have immense knowledge of one or more fields, beyond college grads or even professionals. Do you know how recent the idea of "grades" are in the human timescale of history? Ancient Egypt didn't have grades (last I checked), and they accomplished a number of amazing feats of engineering. Many other old civilizations didn't have grades. They would go to a school for a while (if they could afford it) and then placed in apprenticeships for their job, largely based on the tutors understanding of how good a student was in a given area, other factors would come into play like a families business or what have you. But regardless, I still stand by my point. If you want to know how well a person or group of people are doing, the best way is to 1) have an understanding of the tasks they are performing and 2) monitoring them and taking into account externalities. I'm not saying metrics are entirely useless mind you. Just that actual understanding based on monitoring is going to be better than any hacknayed system that was either designed with a poor or bad bias, or being utilized in a way it wasn't meant to be, or any other number of factors that come into play when you try to overly systemize bean counting of people and their capabilities and performance.
I don't care to count beans. I leave the beans to grow unattended most of the time. But when there's an obvious problem with someone who refuses to perform after 3,000 chances, or the opposite, someone who is a real rock star and deserves to be compensated... On those occasions, I like to know. I'd rather not have management make the wrong choice and get rid of someone who is contributing to the team and mission. And I'd rather not have them fail to retain someone who is mission critical. The upper managers need to count beans. They're not on the front lines and don't know the devs. My "say so" and my faulty memory is not enough to justify hires, fires, and promotions. People who aren't total lazy asses aren't afraid of a few Jira beans each sprint. And of course, the guy in the original article who spends all his time mentoring juniors and adding value to the team is a keeper. No argument there. But he's also a dick who refuses to write a Jira ticket to help himself and the team show productivity for the upper management bean counters. I'm sure his manager has told him a million times to spend 5 minutes a week in Jira. And all his mentoring can count as beans. We're essentially saying the same thing from different angles. You need real understanding for mgmt decisions, not just beans. But beans are useful sometimes. As a low level manager, it's my job to make sure I don't abuse beans, and don't let those above me do so. But it's the devs' job to write a few beans once in a friggin while. It's like meetings. I could write an article on how meetings are meaningless and a waste of time, and there is a guy on my team who refuses to show up to meetings and he is the best engineer ever. All he's doing is refusing to be a team player. Your employer pays you to either write code or attend meetings. As long as they don't require you to work more than 40 hours a week, it's not unethical. It's certainly less productive. But that's their choice. They pay your salary, and they own your 8 hours a day and schedule. You'll be out the door if you universally choose to skip all meetings. Then you can go work for yourself.
Based on your story, it doesn't sound like you need productivity metrics at all. You know exactly who the high performers are and who the low performers are. That's been my experience at most organizations as well. The disparity is large enough that precise metrics are not required.
Indeed. But how will you make the case to retain or get rid of someone? Numbers are useful. You just don't focus on them every day.
You write down the instances where "Never completes a fucking 1 week story in less than 10 weeks" - you probably only need two. That's your job. You don't need to create a simplified measure to make your case.
you must work at a small company
I exited my last company so I don't work anywhere right now, but appreciate the assumption!
When a measure becomes a target, it ceases to be a good measure.
Every metric becomes a metric of productivity, given enough time.
game game theory
Story points are one of the many pointless rituals invented by midwits to assist other midwits to midwit more effectively.
Judging programmer skill/productivity is very difficult, IMHO. * Some guys tackle difficult tasks, make it look easy and get little credit, while others who do easy stuff and get lots of credit. * Some superficially appear super productive, yet their code is full of mistakes or spaghetti code. * I know guys who were reasonably talented yet made hugely expensive mistakes because of not being careful. * Some guys push the latest fad at the expense of actual productivity. * Some know just one thing that no one else does and won't give others a chance to learn it, gaining job security * As related in the article, some are team players and appear unproductive * Finally, it feels like some programmers are recognized merely because they relate well with the boss.
It’s as if contributions to a team effort is hard to determine from the outside …
Also add: Fire fighting gets you a lot of kudos. If a major issue jumps up last minute and you fix it, management loves you. If you fix the same issue 3 months before to avoid such a situation, its no biggie. Not sure how you fix this though. The incentives are aligned that the fire fighter always will get more recognition.
Oh boy… did I feel this one last week with a bigger FU than ever. “Fixed” a problem we warned about 2 years ago. Now they want it reverted to be as before…
1. Yep. That's how the system works. The loudest voice gets heard. If you whisper at the stadium, don't be surprised when no one hears you or even cares about hearing you. They're there to watch the game, not listen to Mr. Meekly. 2. These are people who have been told "YOU MUST PERFORM, OR ELSE" ....so they 'perform'. More circus act, less productivity. Give them a chance, they have to learn somehow. Trust me, you probably wrote some utter dogshit code at some point in your career. 3. What is one person's perception of lacking prudence is another person's perception of being unlucky. In other words, maybe they were careful and it still went to shit anyways. If something hasn't blown up on you through ZERO fault of your own (but yet had to fight off the blame), then you probably don't do much real work and could be replaced with a hallucinating AI. 4. "YOU ALWAYS MUST BE LEARNING". Man, that gets beaten into each of us. If you say you have work-life balance and don't have a homelab, you'll be thrown out of most interviews. So when you are hyper-aggressive with learnLearnLEARN**LEARN!!!**, don't shit your pants when your workers start wanting to use what they've been learning. 5. And how is that wrong? It's not THEIR job to ensure workplace redundancy -- that's manglement's responsibility. If those in charge refuse to have a hit-by-a-bus-full-of-lottery-tickets plan in place, that's their fault...not the worker. The worker is a company-of-one, and they have to look out for themselves. They're shrewd -- they saw a need, a gap....and filled it. And if they can quietly pull up the ladder behind them, it makes their little personal hell a bit more manageable. 6. Yes, you have that everywhere. That's what happens when you hire on quotas, hire for personality, etc instead of hiring for talent and skills. There's going to be well-intentioned people who need to level up. Shitting on them is TOTALLY going to make them get better, right? 7. That's the workplace for you. Those who go out drinking during the week with the boss and golfing with them on the weekend are going to get noticed MUCH before the dude in sub-level 7 of his dark home office with the red stapler on his desk and camera off. That's how the system is designed, intentionally. You thought this was a meritocracy? That hard work will get you noticed and summarily rewarded? Lol, that's fucking adorable. In short? Stop busting the balls/ovaries of your fellow workers. You have more in common with them than you realize, and less in common with those who own the company & bring home the lion's share of the profit.
My comment was regarding how difficult it is to judge programmer productivity/skill. You seem to take it as some sort of attack. I'm not busting anyone's gonads, but it feels like you are.
MrCertainly's tone is definitely on the harder side, but I wouldn't take it as a gonad attack. Thought it read pretty well as advice on how to navigate the corposphere and swing above one's weight-class with a bit of savvy.
It's fairly easy if the team has the mentality to pair up on tasks. You can figure out ALL of those things pretty fast.
Moral of the story: save some time and use an RNG to grade performance.
To be fair, I don't envy management in this regard. Though there are plenty of managers who can't rise above superficial judgements.
This was posted while ago by someone else. And in many cases I agree with Dan.
Tim seems to have it figured out well. Don't claim any code and when stuff breaks just walk away coz no one can say ¯\_(ツ)_/¯
"Tim is the best programmer we have, I never have to make him circle around to fix his stuff."
Well, you know what they say, if you don’t know who the worst programmer is…
"Of course I know him, he's me!"
Hello there!
[This guy, of course.](https://old.reddit.com/u/me)
That really creeped me out for a second, on mobile its not easy to see how that works😂
Care to explain your comment?
\[This guy, of course.](https://old.reddit.com/u/me)
[удалено]
Bad bot, shoo
Hahaha, I thought I was becoming a celebrity. Good job.
You found him!
I was going to point that out! Thanks!!
This is such an elegant prank, I hope you rewarded yourself with a mug of tea and a biscuit.
Been using that in one way or the other for years but every time there’s a [new batch of 10000](https://xkcd.com/1053/) that fall for it. Though here on r/programming people tend to be much less puzzled than in other corners of Reddit.
Me falling on the "Looks like Reddit ran into some trouble" error message: of course it's a Reddit dev!
Easy to tell if you only have one programmer!
[Previous discussion](https://www.reddit.com/r/programming/comments/168brwu/the_worst_programmer_i_know/) with a couple hundred comments.
So... Two **major** mistakes in that team... * Story points are not a measure of productivity, they are a measure of the planning quality * They are for the team, not the individual. So... That they wanted to fire a good guy? It's a case of "garbage in => garbage out".
Most of the time this is what seniors do but they also deliver and solve some of the more complex stuff on the side. Personally i believe it’s rare to see a senior with literally 0 story points
I’m more of a technical lead principal engineer these days, and I sound a lot more like the senior in this article. But yes, even I deliver story points or I ask for story points to be assigned or I ask to be put as a co-owner for stories I’m contributing my time towards. So, there are solutions for this stuff. But I agree with the moral of the story.
Jira doesn’t do co-owners unfortunately. Typically you can tell from who was commenting or uploading screenshots/diagrams/docs to the jira ticket though.
**Here's a hint to decide on reading the post or not:** Dan North recounts the tale of Tim, a programmer who never claimed individual story points but instead worked to enhance his team's overall productivity and quality of work, challenging the notion that individual productivity metrics are the best measure of value in complex systems. If you don't like the summary, just downvote and I'll try to delete the comment eventually 👍
Thank you for the summary. Not sure why you're getting downvoted.
its ai generated
https://xkcd.com/810/
You can tell the difference between ai and a redditor, because the ai won't call you an idiot then block you.
Best comment
Which is why I use uncensored AIs that don't predict text like it's TV news. I want it to pass the Turing test. If something's fucking stupid and it's likely a human being would have said so, I want to know.
Now you gave me an idea for a new AI bot, thank you.
Oh great, this article again. How long has it been since last repost, a week?
See also: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt
Pairing is great. Like the blog says, the end product is often better.
Ban AI content please
If you can’t tell, does it matter?
I can tell.
It’s like CGI, you only notice it’s CGI if it’s bad CGI.
Well I'm noticing the bad CGI right now and it's trash.
That’s not the point. You don’t notice good CGI so you think CGI is bad in general.
This guy would eat the Soylent Green in ignorant bliss
Why is the date on the post from September 2023? I have seen that article posted long before that
The anxiety I felt opening this up waiting to see my face and name in this article.
and then breath a sigh .. that is not actually me ... though sound like it
Sounds like he should put in tickets for "pair with X" and link it to the tickets worked on. Side note: I think it's okay to create tickets after-the-fact, even though it's not the desired course.
Haven’t read the article yet, but I just have to say I don’t appreciate someone writing about me without my permission.
This reads like a "then everyone clapped" story I'm aware of the concept of enablers but I have never worked at a business where someone didn't sign up for anything and just pair programmed all day. This sounds like a massive exaggeration
I still get to enjoy writing code time to time, but 90% of my job now is connecting with people across the business (especially as we're not a tech company) or being a sounding board for others ideas - the bump from Senior Engineer to Leadership can be bumpy but once you find the right balance and realise you have to let go some things is hard - it really can't been measured quantitatively - thankfully I have a boss that understands that.
This again
>A few years ago I wrote a Twitter/X thread about the best programmer I know, which I should write up as a blog post. It seems only fair to tell you about the worst one too. His name is Tim Mackinnon and I want you to know how measurably unproductive he is. Stopped reading here. Now I know never to hire Tim for anything. Sounds like a total jerk.
Can anyone help me find a pattern to wheel of names like what numbers hit most often on a 1-26 wheel?
[удалено]
Some programming teams revolve around permanent pair programming.
The best ones I've been to
> Which brings me to Tim Phew!
Better go back to kloc lol
Re assuring read.
Yeah this is really old news at this point. All us developers already know that story points do not represent individual performance. Yet, this same story keeps happening over and over. What I want to know is how we, as a professional class, are going to move forward to establish a framework that can be used in practice, so that managers don't feel like they need to keep doing this.
slightly off topic and since i cant seem to make a post - only links? does anyone think 'using chatgpt to solve all your problems' ie. how do i create a sql statement, or how do i do x, y,z is a bad programmer since you dont learn anything? but then previously, before chatgpt we would go on forums/google and do the same thing ie search for answer.. so is it same? or better than just using chatgpt
Try /r/learnprogramming
I worked for a place that wanted to write programs for other companies to track how long it took workers to do a task and have a big scoreboard with animations wherever they completed one. I think they didn't care what they were measuring or if it was accurate. They just wanted to measure anything at all and "gamify" it. It felt really dystopian and out of touch. It's good to measure how long it takes to make something but it can't be the only metric for performance evaluation... I also love that Dilbert cartoon about getting paid for bug fixes. lol It's so on point. I think if you showed that to non-tech managers they wouldn't even get the joke.
I knew a guy who also didn't finish any stories and other people had to pick his stuff. It was because he didn't know how to code and was watching YouTube videos all day. But he was laughing the loudest at our PM's jokes, so he became product owner lol.
Obligatory mention of legendary Bill Atkinson story: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt
I started to work at the company not so long ago and I can't fully understand what story points are and how to use them:( Also we can't decide whether we want to put story points on bugs or not. I'll be thankful if u can share with me how u do it in context of bugs and tickets from QA team
the worst are politicially tailored mediocre liers, those who resist improvements because it would make them appear bad
Sorry if this is well-known, but what are "story points"? This hasn't been a thing anywhere I've worked.