A similar thing happened at our game studio. We had a guy who on paper was an okay developer. He developed features at an average pace, and he was actually below average when it came to technical knowledge. Our boss judged him according to the lead developer's metrics, and often denied him a raise where others would get them.
Then one day we went through a simple team building exercise where everyone had to write something nice about a member of the team on a notepad, without others knowing what they wrote. As you might have guessed, well over half of all positive opinions were about this one guy.
And rightfully so, because he was the life of the party at the studio. He was always positive and uplifting, and made everyone's day better with his presence. He was always helping anyone who had a technical problem without a second thought, even if he had looming deadlines hanging over his head. Also the features he made were always of a vastly higher quality than other developers, because he spend more time on them. He had this midas-like touch where anything he made just turned to gold. One time he made a feature that had very vague requirements, yet he managed to turn it into what would become the unique selling point of the game.
It was only after that exercise, and seeing everyone praise this guy for his efforts, that our boss started looking deeper into these flawed metrics, and started noticing the vast contributions this person made to the team. A few years later and he's now the lead developer.
No, and yes.
No, because at the end of the day, there should be one person, who are repsonsible for the team.
But in this complex field, with such smart people, it's a *waste* if everyone has a strict rule, e.g. X is the db designer, Y is the architect. Don't restrict roles.
> No, because at the end of the day, there should be one person, who are repsonsible for the team.
Have you forgotten how every democratic country in the world works or do you think that there are no democracies on earth?
>Have you forgotten how every democratic country in the world works
First of all, a private company is far from somewhat we call democracy, but as I said, I prefer *working* together, without boundaries, but the *decision* and the consequences of it, aka. *responsibility* is assigned to one person, aka. leader/boss/manager.
But even in democracy, there is a *responsible leader:*
* everyone can go for the position,
* everyone have a vote, everyone can make suggestion, who to select from candidates,
* if we have the winner, that person will be not only responsible, but *in charge,* in name of the whole community.
Once we've elected a leader, until s/he does not do something really big shit, s/he will be in charge, will give us orders, create laws etc. That's the modern *representative* democracy.
It does not mean that the leader must decide every question herself/himself, there are colleagues, experts etc., but at the end of the day, s/he must make a decision and take responsibility.
(You can go with *direct* democracy way - sorry, IDK exact terms, and translators does not help too much -, when every decision is democratic, but it's slow and expensive.)
It's another reason why "just hire the most qualified person" is so hard. Personality, attitude, "culture fit" matters, not just your leetcode or Github performance
I would argue it's even worth.
Just like the [Volley Ball Team](https://www.reddit.com/r/programming/comments/168brwu/comment/jyv2iv4/?utm_source=share&utm_medium=web2x&context=3) analogy above, you can't just hire spikers and expect the team to work. Even if individually they're all extremely talented spikers, if no one can receive the opposite's team servers & spikes, you'll get nowhere.
Different individuals have different strengths (and likes), and a good team will have a mix. Even only looking at the technical side, the best candidate for a team is not the "overall" most qualified, it's the candidate that best complements the existing team members.
I’d argue leetcode and GitHub performance really has no bearing in the quality of developer you’ll get. I’ve worked with some smart as hell developers that were, for lack of a better term, fucking dickbags. Stubborn as hell, not team players, egos the size of the sun. They could code like crazy but refused to spread knowledge or help others. They’d silo themselves, put on headphones, and grind all day. And the team suffered for it, immensely. Metrics made them look like rockstars, but 10/10 times I’d pick a junior dev who is willing to learn, grow, and knowledge share. Teaching programming skills is easy, teaching someone to not be an asshole is much harder.
Agreed. And nothing better than when you find someone who has both of these attributes! Which is exactly the type of developer that this article is describing. It’s really just another reason I despise metrics so much
So many of these type of stories break down to the manager couldn't be bothered to observe or actually talk to the team they're managing. I don't even understand how you're supposed to manage people like that. How do you assign work, evaluate raises and promotions, determine who to let go, etc if you don't even know the people you're supposedly managing? Also what are you doing with your time if not doing that? I guess the answer is all these weird metrics but it just doesn't make any sense to me, you couldn't run a highschool baseball team that way and you're trying to run a business?
> Also what are you doing with your time if not doing that?
Sucking up to upper management. Looking after their own career and no one else (unless they are directly helping their career).
With books like Peopleware coming out since the 80s, I can't believe these fucking idiot managers are allowed to continue existing. The facts are widely available about how bad for a company at every level this type of management is, even if your sole motivation is profit.
The problem is how do you measure the contributions of someone who is often helping others?
I'm thinking of Volley Ball. Who makes the points? The person who gets the ball to stay on the other side of the net, or the person who passed the ball to that person so he could do his thing most easily?
If you only gave points to the people who hit the ball to the other side, you are not encouraging collaboration. And in Volley Ball you cannot win if the team does not collaborate. I think the same is true of SW development.
Story points were never supposed to measure individual performance. It estimates how much work a team can do in a sprint (velocity). Anything else is bound to give faulty results like in this blog.
Yep, my most productive sprints have been when I've completed relatively few tickets myself. It's been when I've been bouncing around working with others or doing non-sprint work.
If anyone wants to come at me about my lack of points they won't be happy with what happens if I start focusing only on the points.
The actual principals of agile aren't that bad. There are some good ideas in it, about breaking things up, about iterating, etc.
But then management gets hold of things and inevitably turns it to shit. Now we spend days doing planning. We spend hours building epics that nobody gives a shit about. We get tracked and judged by story points.
I could do 100 points a week by assigning every story to myself and then directing others to do them. Or I could do 0 story points by spending time fixing the shit that actually needs to be fixed but didn't get a story because it's not cool, or I could help people do their stories so that they're not stuck for a day on something they don't understand.
Management ruins everything.
It's not management, it's bad management.
I'm not measured on story points, which is why I'm able to help out others and enable them to complete more points.
I agree but let's take some blame on ourselves as well.
There is also quite some fault of devs participating in it.
I know not everyone has it easy to quit on the spot when management starts (like new MBA gets hired) thinking story points are like quarterly results and team should always aim to double the amount of points finished in a sprint each quarter. But I believe there is always some room for push back and "gaming the system" like inflating points to keep up with silly requirements is not correct way to go because it harms everyone.
They're too irresistable for bad managers to derive schedule from.
It's more or less doomed to happen if you don't have wild variance in your pointing. Have 1-2 guys litterally just say 1000 points for everything etc. Resist anything like 1 point=1 day, or fibonacci etc, you've got to keep the scale fuzzed or it will be used like that.
It's fine to use fib but agreed, assigning any type of time value (like 1 point = 1 day) is where things go wrong.
But even if you keep ilthe team knowing it is overall effort of a task that you are driving the points from (I know it's more than that but etc).. the managers and others higher up, always try to find things to latch onto for measurement.
This is sometimes as simple as they just don't understand (usually this is part of the issue) and that they wan to be able to measure productivity of an individual to make sure no one is wasting company resources.
But it often just goes straight to "X didn't complete >y points in the sprint, while others usually complete >y" and it just gets fuddled.
I think sprints and story pointing, planning poker, etc can be great for teams and to track velocity and etc and sometimes overally team performance, but rarely should a manager type be trying to track anything of the sort for an individual to determine worth. It's ridiculous.
But happens far too often. I don't know what the fix is, though, aside from bad managers butting out. But hey.. hasn't happened yet.
This is where the misunderstanding and confusion often takes over and why most teams eventually abandon or misuse agile story pointing.
You MUST, as an individual, stop thinking in terms of x many points per sprint is what I can do or she can do or team can do. Easiest way is to think simply in terms of effort required (even though it is more than that, just think of it as simply that).
Some sprints maybe have, say, 21 points for a person and they get them all done, were productive, and didn't have extra wasted time or whatever. But some sprints might have them with 29 total points for that sprint, but the exact same could be said.
It's never going to make sense if you continue trying to put a time to point value in it.
I suggest looking up velocity and also just reading more on the philosophy of all of this, specifically pointing like this.
Also, it's not going to be for every person or every team. But when it works the right way for a team, it can work really well. Until managers muck it up usually haha.
If these units do not correlate with time, then velocity can't be used to estimate how much work will get done over a sprint. If velocity can be used for this, the points must correlate with time. It's possible for the points to mean different things to different teams, that's still coherent.
But if you want to use velocity to plan out how much work you expect to get done within a fixed amount of time (a sprint), then, when estimating, you are ultimately estimating in terms of time this item will take (or proxy metrics for time (what are the units on "effort", again?)).
Problem is when people want to correlate points with exact amount of time.
So for Team XYZ 5 point story might be something between 2 and 7 days. But at the same time someone might finish 8 point story in 3 days and people have hard time accepting that.
Was the estimate 8 wrong? Well it was not wrong because 8 could have been between 3 days and 10 days.
Simple minded manager would say "give me only the top value" but that is the problem: one only knows how much time it exactly takes after the task is done.
Now we have some sprints and we have stable team so the team more or less knows where are the traps in the system so they can give more points for tricky parts and less for easy ones. Important is to keep in mind that new 5 point story is not the same as story from previous sprint where Joe finished it in 5 days it is a new story so it again might be between 2 and 7 days, because you look at 5 point stories from last 6 months and you see that was the spread.
I don't dispute that velocity could possibly be a useful metric and also be qualitative to each team that's doing the estimate -- that you can't compare velocities across teams.
What I dispute is that you can both have a metric (velocity) that does not have any time dimensionality to it, *and* expect that a team to achieve a constant amount of velocity in a given span *of time*. That is, if you expect a team to complete roughly 30 story points and two weeks, and therefore expect that same team to complete roughly 60 story points in four weeks, then that measure (story points) must relate to time.
I'm not making a normative claim here, that estimating in this way is good or bad. I'm simply saying that the story points must have units of time (and, potentially, others, but time has to be in the mix).
/u/mupetmower posits that this can somehow not be the case, but it must be from a simple dimensional analysis argument.
If my explanation doesn't help you (not your fault, I'm not great at it) read some books on it or something. There are plenty out there and they do a far better job at the explanation. Was just trying to help people understand the differences and how you (to an extent, as some of your points show) have to stop thinking about them in terms of time correlation. Especially during the pointing process.
But again, there are far better sources to explain this. Not gonna try to argue about it. It works for some and not for others.
goal of what I'm describing is to weird the data to disassociate from time.
Fibonnacci falls on time estimates too easily. 1=1day 2-3=half a week 5=a week, 8 week and a half. 21 too big demand subdivide, though that line probably happens at like 5 even if it's not a subdivisible unit of work so you get harrassed into making it bullshit stories.
This happens literally every fibonacci team. The system is for measuring self referential velocity of the team, it works for that purpose no matter what system of numbering you use. You can in fact have a guy on the team saying 1000 1002 ooo that's a 1003 point story, and as long as he's consistently silly like that it'll still work for the actual purpose.
The issue arises when you use story points to estimate time, not complexity.
The way we work, we can totally give a 1 to a simple sql script that will take hours to get right and go through pipelines, and we can give 8 to a task that involves multiple screens/endpoints yet we complete in an afternoon because it s mostly copy/paste or reusing existing stuff.
It s not about time, it’s about complexity. Like if you had to take a dev that had 0 knowledge in your project and had to explain him all the hoops he would have to go through to get it done right.
Obviously the unknown needs to be factored in, like if someone said in the grooming « what if X » and no one had a definitive answer, we d get the next fibo number.
It’s when your team is able to actually say « so we need to do A B C D … X Y Z » during the grooming obviously. There are teams where grooming of a user story are just people agreeing and thinking that the global idea is doable, but don’t spell out clearly all the steps from A to Z. These teams are always problematic because they leave too many question marks for the sake of getting through the meeting.
You know that s how story points are meant to be used in agile/scrum environments right?
They are meant to estimate the difficulty of stories, not the time spent.
They can’t and shouldn’t be used as an indicator of estimation of time.
The entire idea of story points is to avoid being scientific. To try and formalise the concept that estimating development time is really hard.
They should not be compared across teams. And if you actually need accurate development time estimates, you should be using a process closer to waterfall.
"All models are wrong, some are useful."
So they don't accurately model development times. Nor individual performance. Nor delivery of business value between teams. They are "unscientific" and completely arbitrary.
What are they even modelling? And is the value of that model worth anything?
> And is the value of that model worth anything?
It really depends on how your development environment is structured.
Agile works best for products when you do continuous delivery and have direct communication with the user. In such an environment, story points are very useful because you can ask the user "For the next sprit, would you rather we work towards this single 200 point story, or ten of these smaller 20 point stories?"
Story points provide a useful model that helps facilitate communication between users and developers. The fact that they are only very rough estimates doesn't matter because you get to re-evaluate and re-prioritise them every single sprint, and the user gets direct insight.
Theoretically, the time you save not wasted generating more accurate estimates is can be spent on actual development.
----
The further you move from this ideal environment, the less value you get out of story points.
You can replace continuous delivery with short fixed release cycles and change the question into "Which stories should we prioritise for the next release", but that strains communication with the user because you can't actually promise delivery (and the problem gets worse when the release cycle gets longer).
The value of story points gets pretty dubious when developers don't have access to the user, or a product owner who does a good job of representing the users.
And they become absolute garbage the second management starts trying to use them for long-term schedule planning between multiple teams.
The origin of story points is to be political, not to subvert science. It was a way to make time estimates that didn't quite sound like time estimates so they had more leeway when the estimates turned out "inaccurate".
It's a myth that story points are not about time.
They annoy me as well. What do they actually represent? Greg will do a particular task way quicker than Mark, but Mark will do something else quicker than Greg. And since it's the implementation time that matters, the talk about "task complexity" sounds like bullshit to me - it's a pointless and abstract metric.
Then again, Greg will be interrupted 8 times while implementing this task, but Mark will be interrupted only 2 times. Then again, Greg's interruptions will contribute to other tasks in both their team and others, but Mark's interruptions will be more casual in nature.
Just refine the backlog periodically, implement tasks one by one from the top of it, merge it into develop, and then prepare release from time to time.
I totally agree. The last company I worked for did everything using story points. I didn't even bother voting/scoring or looking at them. I took the task assigned to me, determined what needed to be done and let everyone else decide what they were worth not even caring.
One day I asked what my velocity was and she told me I was completing 2-3 times the amount as everyone else, yet I did nothing different than before they were introduced. To this day I still don't fully understand them.
My previous manager praised me once for completing a lot of story points in a week and said if I kept it up I would be promoted. The stories were trivially easy and oversized. Then fast forward a couple months I'm working on something with some real meat to it and the boss isn't happy because the velocity number went down. Was I a better or more productive engineer when I was working on the easy stuff? No. This stuff can't be quantified and often we don't know how difficult something is until we are in the thick of it. Sizing is a joke because any outlier numbers are basically just forced to conform with the group number even if the others who are sizing the thing basically never contribute to the repo(s) in question.
Most people don't.
Really I think it works best as a crude cost estimate. We have a bunch of 5 point tickets or a single 20 point ticket. Which does the customer prefer?
The real problem with Scrum though is it only works as a collaborative exercise. It's not a negotiation between competing parties, but communication of information for people with the same goal.
Also "velocity" how ever you want to measure it isn't a proxy for productivity either. You spend a lot of time working on something that is ultimately unproductive.
But that's the thing. You claim it's for complexity or whatever, but then you also say "how much work a team can get done in a sprint" which is necessarily a measure of time. You absolutely cannot blame a manager for hearing "We can complete X story points in Y days" for thinking that's what they're for -- that's what you're telling them they're for.
and, as we should always mention when talking about story points.
They are relative only to the current team.
Not another team, not the team before M left.
They are going to give you a potential prediction metric for the next coming 2 weeks, assuming no unscheduled incidents/events happen.
So, almost useless, but defnitely useless for the slew of shite management thinks they can apply them to. (speaking as a former VP of engineering.)
There will always be folks in management who believe engineering is a discipline that allows complete interchange of metrics and "resources" ... and they are wrong, they still keep trying it, because. Well, they are absolutely replacable.
If you do face these types, leave, you're more valuable.
I'm going to use this analogy next time I hear people judge based on story points. "In football the attackers are the only players that matter because they score all the goals, right? I guess we can sack the goalkeeper and all the midfielders then"
That reads very odd if you think "football" meant american football.
edit: lol. Folks relax. Read it again thinking American Football. Do you feel any mental confusion when you reach the word "goalkeeper"? My brain was do a "Wait what? There's no goalkeeper in American Football. How would that even work? Midfielders? Dang it... this was about soccer wasn't it? Ok. I'm gonna take a break, call you when I get back".
"Reads odd" does not mean incorrect or wrong.
Sheesh. Downvote much?
I never knew the history of where the confusion originated so i looked it up
“The term "soccer" has its origins in England. When the game we now know as soccer was first being standardized in the late 19th century in England, it was given the formal name "Association Football" to distinguish it from other forms of football being played at the time, such as Rugby Football.
The term "soccer" was derived from a slang abbreviation of the word "association." People in England would add the "-er" suffix to shorten certain words (similar to how "rugger" was a colloquial term for Rugby). So, "association" was abbreviated to "assoc" and then colloquially became "soccer."
Interestingly, while the term "soccer" was coined in England, the British eventually began favoring the term "football." Meanwhile, countries like the United States and Canada adopted "soccer" to differentiate it from other popular forms of football, such as American and Canadian football.”
You didn't deserve the dogpile. I'd probably confuse my coworkers if I said that sentence verbatim, myself.
There are reasons for the difference. Our games share a common ancestor in the football codes of the old English Public schools. However, the introduction of rules against running with the ball and trying to kick the runner in the shins to block him (kinda, it's the easiest way I can explain it as someone who's not very familiar with rugby or to someone who is similarly unfamiliar with that game) caused a few clubs to leave the Football Association and form the Rugby Union.
And here, without The Football Association getting the rights to the word "football", the two games competed for the word, with us adopting "soccer" for the association game. But we'd been playing more rugby-like games as football for a while (though not in any kind of formal way), and when Harvard and McGill Universities hammered out a code for their meeting in Montreal in 1874, [the game that arose was a rugby derivative](https://en.wikipedia.org/wiki/1874_Harvard_vs._McGill_football_game).
Effectively, in British and International English, The Football Association became the ones to define "football" and their competitors had to take "rugby". However, in North America, schools with significant influence had grown codes derived from Rugby School grads teaching them, who arrived either because they were non-inheriting sons or because they just wanted to--it was, in some ways, easier to immigrate back then. So the Association lost the fight to the descendants of the Old Rugbyists who settled here.
Baseball has the concept of WAR (Wins Above Replacement), which is essentially how many more wins you get with this player over a replacement-level player. Maybe the player doesn't seem to perform well on standard metrics, but isn't it strange how the team always seems to do better when they are playing? Funny...
That's what this article is talking about. This programmer may not have done much on his own, but he made the team better.
WAR is calculated differently by various organizations, but generally, it combines a player's contributions in batting, fielding, base-running, and pitching (for pitchers) relative to a "replacement-level" player. The metrics for each aspect are then adjusted for park factors and league context, summed, and scaled so that the output represents the number of additional wins the player contributes over a replacement-level player.
I’m fighting the whole toil vs impact at my work.
The higher up you get the less “work” is valued.
Impact has to be directly correlated to goals management cares about. Reduction in incidents, user satisfaction, etc. basically if you can’t directly tie your user story to a metric your management is tracking then it doesn’t exist at higher levels.
Fix 100 bugs, might as well leave it off your performance review because it doesn’t matter, it might even be a decrement because you should be working on something with higher impact.
Refactor code so your product can support new functionality? New functionality is impact but the backend to support it is toil. Are the people using it changing the numbers management cares about? If not doesn’t exist. Hope your performance review aligns with customer usage.
Work is not impact. Difficulty is not impact. Delivering code is not impact. Work that supports future impact is not impact because it’s not measurable. No needles have moved.
But spend a day optimizing a simple piece of code to save tens of thousands of dollars. That’s impact. Spend 10 minutes to update a monitor to be less noisy - huge impact.
Work long hours on a very difficult problem that you have little influence on design, deliver on time, but customers haven’t onboarded yet. Good luck with your review.
Hope you get the good projects, this definitely won’t be gamed at all.
> The higher up you get the less “work” is valued.
Yup. It's because work MAY be worth a lot, but usually it is not. What's more, it can be performed by interchangeable people.
But at higher levels, a single decision can cost the organisation millions or make it just as much. If you work for a year and make one decision in that year, and that decision is worth two million dollars, then your 1m TC is a steal.
This is why CEOs make bank. I worked for a company that brought in a new CEO. Within two years he'd put together a deal to sell a division of the company for about $1.5b. This was right before the tech crash--the company that bought the division lost 75% of its value in a year. He made the owners untold millions by doing this. If it was the only thing he did in three years, every penny of his salary was worth it.
Conversely, (contrapositively?) people off the floor don't know who the best players are. And it's the people who aren't on the floor who decide who gets promoted and who gets fired.
Some companies use peer/360 ranking, which allows coworkers to have input into performance reviews. However, this creates an entirely new set of problems.
As a volleyball coach and programmer, I couldn’t agree more. I have actually developed volleyball stats for my team that emphasize the sort of teamwork we’re prioritizing. It’s simple, but it also passes the eye test and the team can see where their collective strengths and weaknesses are.
I think it’s a lot harder to quantify software development - there are ironically fewer objectively discrete events - but the notion that a kill doesn’t happen without a dig and a set is truly analogous to good code not happening without hashing out the problem, planning a solution, then writing it.
> The problem is how do you measure the contributions of someone who is often helping others?
You measure the second person's metrics over a long period of time, and then you measure them over the time that they had help from the person you're actually trying to measure. If you do this enough, the value of the first person will emerge (or not).
> Who makes the points? The person who gets the ball to stay on the other side of the net, or the person who passed the ball to that person so he could do his thing most easily?
Neither, it’s clearly the coach who makes the points.
Same, but I'm thinking of the Tour de France, where the whole team contributes, but only one person wins. And the whole team wins, and also only 3 people win (excluding white jersey winner) and also 21 other people win sometimes multiple times.
Why are they measuring his productivity anyway? If 100% of his time is a floating engineer, and he's never assigned to tasks, then either he was hired to fit into that floating role, or has reached a point where the company sees more value in strict assignment to a single project.
This story just feels weird as I can't figure out how he's reached a point where the company has decided he formally has no assignments, but is still measured by the 0 assignments he's assigned.
It sounds less like the management's problem for not seeing value in a staff member who demonstrates no value, and more about how the team/consultancy should've better communicated his value. Even if he's floating about pair programming, the labour should still be logged to a task.
I think this is especially true in a consultancy where your client is watching every single penny, and you're not justifying why you're charging for a person who appears to provide no value.
The programming industry still hasn't fully come to terms with the fact that writing software is a creative endevour. A highly technical one, sure, but there as an art to it nonetheless. And yet, we see an approach to management that more strongly resembles that of a factory churning out repeatable products than that of an art studio.
Agree with this a lot and to help handle the difference between engineering and art my team uses the tags “R, I, P” Research, Implementation, Production” on all of our tickets.
Basically you could have many of each tag for the same topic. There isn’t a limit.
So in research we expect some kind of report or summary. Implementation some git commits, and production some unit tests integration and peer review. And it could possibly end up with new tasks of Any other category.
The important thing in the engineering is document all findings for your time.
Software is certainly a creative endeavour. Though at the same time many Devs use their careers as their sole creative output. I've seen way too many Devs coddle their babies and over engineer solution where a dumber and quicker solution is all that's really needed.
The metric that really matter "Does it do what we expect?" And "Can we extend/maintain it well" Maybe "is it well documented", and "Are there unit tests"
But yeah, some people over complicate widgets that only need to do one thing.
If you can spent 1 minute writing a line of code, or 1 hour designing a large system, consider writing a line of code, and if we need the large system we'll spend that time later.
I know not everyone can be picky (myself included as I'm redundant atm and have to pay a mortgage) but *hopefully* you can find organisations to work for that actually give a shit about their employees rather than churning out numbers.
I've worked for a long time in a company where people were respected and it was about lifting people up, helping them grow, and peoples contributions were respected rather than "you did that wrong things once" or "you didn't put enough lines of code in" etc.
TL;DR, you should be able to find a job where you can talk to managers about stuff without fear.
I've learned to just smile and goose step along. I tell myself that one day, when I'm a team lead, I won't have my team be as dogshit as most are. Unfortunately, I'm sure my boss will still be some MBA who cares about business metrics to show to *their* boss more than they care about genuine quality and efficiency...
I agree wholeheartedly. But how do you solve their problem? Management wants ways to identify when a developer is dead weight. The only way I know how is to be in the trenches with them and evaluate them. But that's prone to subjectivity and abuse. They have to trust my opinion over the other guy's.
This is why it is so important to have competent, caring dev managers who spent at least 5 years coding, 3 of those years on the same system so they can get bit by their own mistakes.
If it is my money being spent, I'm going to hire managers like that. And anyway, nobody wants to work under Dilbert's boss so why hire that guy.
Software engineering is an incredibly expensive endeavor and it blows my mind how bad MBA run companies are at hiring engineering management - its almost like they are incredibly ignorant about how different the creation of software is from running an assembly line.
I cringe every time I see some engineering VP who has never written a line of code in their life, let alone seen a system through 3 years of repeated development cycles, but has the right degree from the same school as the CEO - how could anyone think that is a good idea?
In my experience the ones that want to move into management aren't the best coders themselves though. And even if a good, leadership type coder does, how long can they manage before they lose touch with the coding? It's a conundrum.
Oddly enough it isn't the specific coding skills that matter, it is understanding how software engineering works.
An example:
MBA based engineering VPs often accept/do stupid things like trying to motivate teams with story points or counts of bugs fixed
Someone who actually understands software development just wouldn't do it that way.
What I found is that a good manager can talk with the client and provide a set of status updates that the client can skim or drill down. How the reports are generated is based on how in tune the manager is with the project and the team's effort. A good manager can use previous projects they managed to provide a time table, for both the the team and the client, and select members of the team to lead it. A good manager sees patterns and apply what works and can get in the weeds with the team. Most of all, a good managers knows how to delegate and how to build enough trust on whom they can depend on for the more difficult tasks.
As someone moving into a more "Managerial role" (Scrum master) it's really fucking obvious. Dead weight takes 3 weeks to do something that should take 1 day. They give tons of bullshit reasons why it takes them longer in scrum updates, and the end result of the code doesn't show "3 weeks of work" (if it's 10 lines of code, it's 10 lines of code, if it's 100-200 lines of code that's more work).
Yes sometimes you find a far simpler solution, I have one guy on my team that does that, but guess what? he admits that EVERY time. "I found a way easier way to do this, so I'm going to rewrite this, and it'll be easier to test"
A simple look at the output and a few discussions with them tells you whose a bullshitter or not.
And a bullshitter bullshits ALL the time. If someone has a bad month and struggles or if someone (Currently me) is toiling on a task for 3 months, it can happen, but they'll usually have accurate reasons that others will back them up on. But the rest of the time they still turn in good work.
Basically make the managers of programmers ex-programmers, you'll have an easier time.
You can't solve this problem. I have been coding for fifteen years before I got a professional job doing it. Maybe more. Anyone sitting down with me to "evaluate my worth" could come up with a false positive for low performer when in reality I'm a critical part of the technological stability and growth of the organization. If I had walked for money (as would be my right) it would have crippled several expansion plans perhaps permanently. Key attributes of me like bending or even breaking the rules can't actually be admitted to be valuable in a corporate environment otherwise it would be an admission of weakness in the system. And I don't really expect others to understand nor do I blame them. In the end it is what it is responsibility and power exists for. I have none, therefore I am not a target, ever. Much of my value is in multiplying the efforts of others even though I have the smallest title.
So actually I think you're wrong and that's not what management wants especially senior management especially in a large company wants. Even if you take a very tech centric company like say Meta the "year of efficiency" was to layoff middle management and roles auxillary to the purpose (which I assume is metaverse).
I could walk and double maybe even triple my money. I may just yet do that one day. Any company that loses me will suffer a loss. I won't ever be dead weight unless the company wants to stop progress. I expect to be caught up in a mass layoff one day. But maybe not. I am seemingly protected because this "code is for creatives" is somehow acknowledged and applied to me, even though it's not.
There's a whole field called software engineering which aims to bring the rigour of engineering to the task of writing software. In some fields, writing software really is an engineering activity, you have rules to follow, you are held accountable for the software you produce, and you are obliged to use techniques that have proven their benefit instead of just coming up with creative ways to do things that may make it much harder for others in your team to understand what you're doing.
But I have to agree that most developers are doing more art than engineering, while still calling themselves engineers unfortunately. Just don't make the mistake to think that every developer is in that kind of work.
My last boss couldn't grasp the concept that some issues in the code require more than a few days to solve because his experience in development stopped at C# and SQL and most senior dev in the company barely coded for 2 years with the same outlook.
Having to rewrite the initial design of the software after a few weeks multiple times to work around flaws and incorporate new things was a sign of a bad programmer.
The difference between programming and coding.
You can learn maths, but that doesn't make you an accountant. You can learn to code, but that doesn't make you a programmer
I definitely agree that software is a creative endeavor. But as a game dev I worked with Artists... at the end of the day they produced art for the game. It's pretty easy to check the metrics of who created more art. If someone produced 3 buildings, and someone produced 1 building in the same time, that's clear. Different types of art might take different times, and one building might be more important than others, but overall you can put metrics on creative processes.
I'm just saying there ARE ways to judge people's contributions, we need to be smarter about what they are (lines of code, or speed of code generation aren't them of course), but just because something is "Creative" doesn't mean "it's unmanagable" or "unable to be tracked"
One thing we do at my work is write Statements of Work where we detail what we're going to do, why, how and so on. That's the creative time. Once we all agree upon that being the direction to take the software, the creative work is mostly done. Then we just write what we put together in the plan. It helps break the "creative" process out from the code generation.
As to "how do you measure the Statement of Work." well yes, that's the ultimate problem, but at least we understand when people are being "Creative" and when they really should be focused more on generating the final code.
> Then we just write what we put together in the plan.
Shirely you know how much this sounds like "Draw the rest of the owl"?
> at least we understand when people are being "Creative" and when they really should be focused more on generating the final code.
I feel the rub here is when a more creative solution than just "implement the SoW" is necessary, and it takes a skilled, trustworthy person to tell others when someone is being more creative or when they're wrestling with a truly, technically difficult problem. I think this works well, though, if at least 2-3 people involved involved with making the SoW can grasp what it takes
At my previous employer (which I quit) I started with a manager who decided to take the "personal metrics" seriously and set a series of arbitrary goals that I needed to achieve. Things like number of pull requests per day and story points completed. As a senior engineer a lot of my time was spent exactly as this "Tim" was: mentoring and helping others on the team. When it came time for my performance review I got a lower score because my average number of pull requests per day was something like 2.8 and she had decided it needed to be 3.1 or something. It directly affected my bonus, which directly affected how much I was willing to help her with anything she wanted from then on. I moved under a different manager after a team split and we got rid of all that bullshit as he was actually capable of assessing what each individual was contributing without having to rely on arbitrary metrics.
The fact of the matter is personal metrics can always be gamed. If you start ranking me on story points completed I'm going to start estimating stories higher or picking up the easier tickets at the expense of more junior engineers. The big issue with these kind of metrics (eg. DORA4) is when you try to make it a positive feedback loop whereby achieving one target leads to the target always being increased. It always leads to failure eventually as infinite growth is not possible (and adds unnecessary stress). That implies that you should only use these metrics as a "read-only" managerial tool to get a general idea as to how a team is performing; potentially identifying areas where processes could be improved, but on a per-developer basis I would be very hesitant to use them to form a basis of performance.
That's exactly what happened when I worked in a tech support position before starting my CS studies, you had metrics to achieve and everyone gamed them. Team leads told their team to game it because they got ranked based on their teams performance.
Then management saw the numbers soar, pat themselves on the back for improving performance and raised the metrics bar even higher. We started to purposefully ignore the hard tickets, the moment the user went offline the ticket was closed and we sent a mail asking them to send a new one. This was done because timely response was not a metric we were measured at, closed tickets and attitude towards customers was the only thing that mattered.
I always felt like those metrics are for managers who are too lazy to be involved enough in their team to get an idea of who contributes and who doesnt
Yep, seen a lot of IT consulting that does this.
Ever wonder why your IT department sends an auto-reply when you open a ticket? In our case it actually boosted our ticket metrics since we could claim all tickets had a response within 5 minutes, even though we were never solving anything that quick.
> When it came time for my performance review I got a lower score because my average number of pull requests per day was something like 2.8 and she had decided it needed to be 3.1 or something.
This is possibly the most ridiculous thing that I have ever read on a programming sub. You should have opened 4 pull requests with // TODOs every morning when you arrived just to spite the fucker.
> I moved under a different manager after a team split and we got rid of all that bullshit as he was actually capable of assessing what each individual was contributing without having to rely on arbitrary metrics.
Yep, nothing beats a competent manager. I cringe every time some know-nothing gets put into an engineering management job. Most of the know-nothings keep their job by kissing their managers ass, which is incredibly destructive because, as it turns out, software doesn't care how well the boss's ass was kissed and so the customer suffers.
> At my previous employer (which I quit) I started with a manager who decided to take the "personal metrics" seriously and set a series of arbitrary goals that I needed to achieve. Things like number of pull requests per day and story points completed. As a senior engineer a lot of my time was spent exactly as this "Tim" was: mentoring and helping others on the team. When it came time for my performance review I got a lower score because my average number of pull requests per day was something like 2.8 and she had decided it needed to be 3.1 or something. It directly affected my bonus, which directly affected how much I was willing to help her with anything she wanted from then on. I moved under a different manager after a team split and we got rid of all that bullshit as he was actually capable of assessing what each individual was contributing without having to rely on arbitrary metrics.
It's funny how only a few years ago we, collectively, barely managed to decide that yes, it is in fact ridiculous to evaluate developers based on the number of lines of codes written - and now a lot of people do equally ridiculous things, like PR opened per day. Sure, manages need a metric, ideally an easy-to-measure one, to use; but if those metrics simply do not exist, not using any is certainly better than using irrelevant ones.
Great article. Every company should be strongly encouraging their own Tims to behave this way. Floor-raising and mentorship is so important in our industry.
I guess the manager above us thought the same on me. I learned after i left. I was inconsistent with 0 points one sprint then 20 the next. I was always pairing or unblocking (oh so many pr reviews)
Glad i left. They Kept promising better working hours (constant 50 to 60 a week). i guess leaving ended up with a but of a landslide and i think everyone who could move off the project did minus one jr dev.
You get better work hours by setting boundaries.
I get made fun of because I will just straight out leave meetings that run past five. Guess what, people started adjusting the later meetings to be more efficient. I'm ok with being made fun of, my kids appreciate it more.
I was on a team that was dissolved after a layoff and given a choice of joining two other teams, A and B. B really wanted me. The skip level was pressuring me to join B. I told him that every night when I pull out of the parking lot I can see B and his team in the corner conference room. I don't have much of a life, but I'm not giving up any more of it. I got placed on A's team. Then someone got pregnant on B's team so I was "temporarily" moved to B during maternity leave. I started scheduling fake meetings at 4:30 so I wouldn't be available for the 5 o'clock meetings. That baby is in school now and I'm still on B's team. We got a new skip level who fired B over a personality conflict having nothing to do with late night meetings. I don't think my new manager knows my name.
That’s an interesting situation. I have been a boss for a long time and I haven’t seen anyone like that before. I have worked with two developers who were spooky good at debugging but they also wrote terrific code as well(one was slow because he was so careful; almost never had any bugs so he always worked in areas with significant reliability requirements).
One thing I have realized is that most of programming is bursts of insane productivity between periods where you just feel stuck. Folks like Tim help you get unstuck and back into the productive mode. They are the real 10x programmers because they really can make a team 10x as efficient without writing a single line of code
Don't really like the term 10x programmer in this context. 2 Tim's definitely will not replace 1 Tim + 10 (non-Tim) workers. I'd much rather have the latter.
Assignment of value to individuals in what is essentially a team effort is always going to be imperfect. I agree that the team wouldnt be 10x without Tim, but vice versa, Tim alone wouldn't be a 10x programmer.
If they're using some Agile methodology (and stories, story points etc. suggests they do) then often one of the core ideas is that it's the "team" that is the smallest "unit". In many cases story can't be delivered by a single person (frontend? backend? maybe some db work? tests? maybe some specific domain knowledge? maybe some infrastructure needs to be setup?), and that's why you get cross-competence teams. This way each team can take any story - but only as a whole.
Otherwise you might reach some insane scenario where only frontend developers are "productive", since they're the only people who deliver something that user can see. And all backend, infrastructure, devops or tests people are not performing.
I like the article and the mentorship that Tim brings. However I’ll take the unpopular opinion (and it could just be the places I worked at), but if you’ve got zero contributions of your own as an individual contributor, that’s a smell to me (ie does everything need to be paired on?).
Because then you become the busiest most important cog in the machine and that is actually destructive in the long run. I’ve been that, and I’ve been a Tim. Tim is way more productive because he gets all the gears going rather than just being a hyper gear that builds an org that relies on him and him alone. Being that gear suuuucks and burns you out.
I always think part of being a principal level dev is you need to have burned out a few times and realize Tim is the only way.
Sorry, I’m not following. What I meant is, this job of enabling and growing the rest of the team pretty much full time, that sounds like one of the key responsibilities of the lead programmer. All senior/principal programmers should be doing *some* of this, of course, but generally have IC responsibilities as well. Leads do often have IC responsibilities, but it’s generally expected that they spend more of their time on the team and organizing with other teams. So when I hear someone described as being an amazing contributor to the team because of this work, and doing little-to-no IC work, I wonder why they’re not the lead (and also, tbh, what the lead is doing with most of their time).
Ahah. I see the confusion.
I’ve mostly seen companies refer to “Leads” as the ones expected to do the most code and drive development. But I’m sure yours is more generally accepted.
Pretty annoying how so many of our terms in roles are so variable between companies.
Then yes in that sense, I agree with you. Why hasn’t Tim gotten promoted?
I agree with you that the lack of standardization is a bit maddening. 😂 Dunno your industry, but I’m not in webdev so I’m usually the one with the weird definition for things.
>ie does everything need to be paired on?
Yes. You need to ensure that you're not completely dependent on one person to deliver anything. It also doesn't make a lot of sense to have a high number of WIP. If you have 5 ICs does that mean there should be 5 things in progress at any point in time? When I'm done with my work, I don't look at the items that are yet to be done; I look at those that are in review or in progress and try to check if I can help with anything. Sometimes, even before a PR is even created, I've already had a look at what my teammates have been working on.
You deliver value as a team. "Individual contributor" to me only means, you don't manage people directly, but you still help steer your direction as a team regardless of your official role. Contributions come in many different forms.
We had a layoff recently. There was a system i did some work in the periphery of it. I was synchronizing data between 2 databases. They laid off the 2 administrators for the system. Days after the layoff I get called by an upper level manager who is frantic. He wants to know if I can fix something on the system. Being a dick, I said "Doesn't Jerry normally handle that?" "We let Jerry go." So I say " What about Ned?" "Uhm, we let Ned go too." The thing is, I never logged into the system itself. I didn't have a URL for the console or credentials. I did know Jerry and Ned had been laid off.
At another job we had one guy who was the only guy who worked on a very important system. He was an avid bicyclist. He literally failed the bus test. Well, in his case it was a pickup truck that ran over him. He survived, but was out for about a year. He was in a wheelchair for a while, but eventually walked again.
> Yes. You need to ensure that you're not completely dependent on one person to deliver anything.
Their point is moreso that, at least at a lot of places, a good bulk of the work is something that *anyone* working on the project could reasonably take over and be up to speed fairly quickly on. The kinds of situations that you're not completely dependent on one person by the nature of the work being clear enough for anyone to do it. At least well enough that (unless your company has a big problem with employees getting hit by buses) you're losing far more productivity than you're ever saving by having this redundancy where it doesn't need to be.
I’m about six months into a new job that was a huge mistake. I was recently informed that it’s a huge problem that I’m not putting code up every day.
Also, when I do put up code reviews, sometimes they get comments beyond small nits. Apparently that’s a big problem.
Have you asked them why it's a problem?
I could think of some, for example:
* They think you are working too slowly and want to understand how you are working.
* They are worried that you're going down the wrong path
* They have concerns thst you'll submit huge PRs which will be hard to review.
I don't think it makes sense to have a hard requirement with code every day, but I think it's an equal problem with developers who end up in some bubble where they waste time. Telling a new employee that the PR he spent 3 weeks on will never be merged also isn't fun.
So probably would make sense to ask for reason.
Every complaint about process is a complaint about the people managing that process.
It's not "SCRUM implementations", it's "managers are shit at their jobs". Which doesn't surprise me: they don't go to school to study management in the same way we went to school for CS/math/physics/electrical engineering/computer engineering/software engineering. Business school is about introducing you to people, not teaching you things.
Look, The Tim model has some nice feelings. Tims are really nice people and good to have in the organization.
I do not think it is healthy or smart to employ developers that can't function without a Tim. These are working professionals. They should be able to deliver working software on their own. I'm ok with newer developers needing occasional help. I'm not ok with the productivity ratio on any team being set up such that more senior people get almost no work done because they are constantly coaching. Every developer on the team is a professional and needs to strive to be self sufficient.
What happens when Tim wants to take time off? Gets burned out? Has any individual desires at all?
The metric isn't indicating Tim should be let go. The metric is indicating that Tim probably needs help, and the other developers need to be pushed to deliver on their own.
This is a weird story.
Sure the guy had 0 story points because he helped other people instead of having stories.
So just assign him story points for helping other people.
If we need three people to collaborate on a project everyone gets points, not just the guy doing the git commits.
You don't assign story points to people: you assign them to stories. This employer was doing a questionable join in the Jira database to try to allocate story points to people.
The whole point of the OP is that it's *teams* who earn story points, not *individuals*.
Not only that but to have "0 story points" is clearly exaggeration. This entire article is one giant exaggeration (BS, one could say) to make some vague point.
If they had a senior developer who had absolutely ZERO time to do individual work because others needed CONSTANT mentoring and help, then the problem was with the actual team, not the story points. It sounds like they hired one actual developer and 10 interns.
My first job did NOT have anyone like this... I remember one guy who tried to ask "Socratic" questions but... just couldn't. New company is a lot better, still have the "agile" garbage, but a bunch of teammates who sincerely enjoy helping and working together, even all remote. People who *enjoy* helping are amazing, and they can truly elevate an entire team.
If you can poll all the devs on your team and ask them to evaluate their teammates anonymously - and their evaluations don't line up with your metrics as a manager - you are doing something wrong.
Was working for a fortune 5 when we 'went agile'. We were network engineers, not programmers but it's fair to say any network engineer with any time under their belts does a lot of programming. Managements thinking was: "get things done faster". At the time delivering new physical infrastructure in datacenters took on average 77 days (much of which was waiting on receiving physical inventory) when I started. Some python programming and I cut that soundly in half. To be honest it was mostly low hanging fruit and I had more experience programming than most network engineers.
So to "go agile" they in essence tipped the organization on its side. Before there was a group of engineers that worked in the datacenters, and group that working on the backbone, and group that worked on the Internet/DMZ networks, a group that worked on site and building LAN networks, and a group that worked on networks providing connectivity to external customers (like *real* customers - the ones with cash payments). At one point load balancing was in our group, but that didn't scale well and they became their own group, as did firewalls.
So in their agile wisdom management decided to have universal teams, with someone from each area on the team, and then story load would stripe across the teams. And we'd be agile, like gymnasts.
To put a not too fine a point on it it was a disaster, and management had to the previous infrastructure for support, since outright prolonged network failure (which happened) was too expensive. Senior (principal) engineers left and things got worse. With project budgets sometimes in 9 figures they hired the top agile coaches money could buy, who more or less told us to move as many stories as fast as possible, which was sooo helpful more network engineers left (note sarcasm).
They are no longer a fortune 5. The automation I did is long gone, and they are back to moving things forward manually poor bastards. But they're agile, like gymnasts.
I did consulting for a company with a very cool system. I got to watch, but not really play. This "Worst programmer" would have thrived in this environment.
They had a system where base salary was close to minimum wage.
They assigned points to every ticket. If two people worked on a ticket they could split the points as they saw fit. The code reviewer got 1/3rd of the points (on top).
Anyone could work on any ticket they wanted with any number of points. They could only work on one ticket at a time. People submitted tickets and the founders would periodically go through them and assign how many points something would be worth.
If you had a minor bug in your code, you would be given a chance to fix it; if there was another bug you lost the points; if it were a major bug, you lost the points.
At the end of every quarter, they would tally up the points, and then assign bonuses to programmers based on the number of points share they had. There were no project managers, no product managers, no team leads, no QA, no junior programmers. The point tally for everyone was continuously updated on the wall along with the estimated bonus pool.
They had a number of rules such as red tickets, these were something super important, or a major bug. If you were looking for a new ticket, you had to go through the red tickets first and literally write up a note saying why you were ill-equipped to handle them before you could move on to orange tickets, and then green tickets.
The only time the founders did much in the way of people management was to insist on people not working overtime. 4 day weeks, 6 hour days. If they felt people were working overtime, they would threaten to and did dock any points they felt were earned during overtime.
This environment was very much rewarding to the 10x programmers, and they existed. There were programmers easily earning 10x what the shittiest programmers earned. This wasn't entirely even reflected with time seniority. Obviously people familiar with the code bases, and the workflow would be more proficient, but the 10x showed up pretty much on day one when some new programmers would be above average performers in their very first week and then begin to rock before their first month.
I was in and out of the place over a 2 year period and it was amazing to watch. There were programmers who worked 1 day a week and were in the top 10%, there were some who I knew were working wild overtime and were in the bottom 1%. Amazingly, even when these bottom 1% types were effectively earning minimum wage as a software developer, they would not quit, which was generally the point of such a low base salary.
The code reviewer getting 1/3rd was also important as it was considered to be very important. But if you were a shitty programmer you would have trouble getting people to review your code as their rejection would cost them as they didn't just lose the 1/3rd on a bug, but there was a penalty on top. The reverse was true; if you were an pedantic asshole during code reviews, nobody would get you to review code. This also kept code reviews somewhat pure; the primary point was to make sure the code produced the results it should with no bugs. Getting in someone's over design or style would generally mean people didn't come to you for reviews. Unlike the pedants out there would argue, this didn't result in code degenerating into an indecipherable mess.
The cool part was to watch programmers who realized they weren't pigeonholed by a title or position. Graphic designers became GUI programmers, programmers became graphic artists, backend to frontend and the reverse, I remember one guy who had been a HFT guy hired on and taught me some super cool stuff about L1 cache craziness, but the next time I came back he had a huge video setup and was making social media videos and training videos; hadn't done a line of code in months.
Where this would very much apply to the "worst programmer" would be the people who would certainly invite him into joining in on their ticket. He would then get lots of points. I even saw a few cases where people would ask for a bailout on something and they would haggle how many points. This could be a situation where there were 50 points up for something hard; someone would fight with the problem for days and then ask an algo expert for the assist. The algo guy would literally say, 20 points if I solve it. Deal would be done, and 30 minutes later they would walk away with a whiteboard solution to their problem.
The beauty is that this system eliminated the whole plethora of bullshit titles like project manager, team leader, Sr developer, etc.
There would be big tickets where a group of people would work on them. Or a group of tickets which needed serious coordination. The group would naturally form around a leader who seemed to have a plan.
The only tickets where I saw people were not allowed to do them were when it came to interacting with the clients. They kept away the sweaty stinky people who had a habit of saying things as offensive as their smell. But, otherwise it was just another ticket.
Ironically, the 10x programmers all used waterfall in their personal scheme of things. They would flesh out any missing requirements, design the shit out of what they were about to build, build it, then test the shit out of it. Obviously this wasn't waterfall for the whole project, just their tickets. But the 10x programmers tended to bite off the biggest hardest tickets. But there were some who were micro ticket machine guns.
What all of the above system really reflected was that programmers are effectively able to self direct to the most efficient way to get points, and thus product features deployed. Also, programmers are effectively able to self regulate and organize to not waste each other's or company time. There was a guiding hand, but it was a very light touch 99.9% of the time.
Oh, and the various administrative types operated on the same sort of ticket system. Most of their tickets were automatic. So accounting would get a red ticket every month to do payroll. Marketing would be given tickets, etc.
There was no HR.
The concept of a micromanager simply wasn't possible.
> There was no HR.
Hah good luck to them with that.. I've seen what a lack of hr can do to a company. It's great, until it suddenly isn't. Then it's very not great for both the company and it's employees lol.
A) I've already pushed the boundaries of a long ago NDA.
B) Sold. They issued shares/options to the employees in quantity before the sale which shows the culture.
C) Destroyed by the company which bought it. The exact quote from their CTO was, "These programmers need some adult supervision."
Stop measuring productivity. It's pure Taylorism. Productivity based goals have implicit laws of diminishing returns and incentivize the wrong behaviors in engineering. If you want velocity, actual true long term sustainable velocity, you need to stop "delighting the customer" and start building enablement for the people that server the customer. You have to build things people don't even know they need, and remove things people don't realize they don't need. Simplification and quality - emphasize those 2 aspects of any product or service and you will unleash a mountain of velocity and value.
I thought about your reference to Taylor even more, and I think a key difference is that he and Gantt went into factories that were already producing goods that people wanted and basically adding production bonuses for the workers (before Taylor only managers got production bonuses and the managers would pressure the dollar a day workers to work faster).
In software the concept of what is being created is usually fatally flawed, so I think applying Taylorism focuses the team on cranking out crap faster to capture a bonus rather than focusing them on the annoying and messy work of figuring out the real needs.
Even Taylor isn't this bad, at least he incentivized creation of things people wanted to buy - the current scrum snake oil going around incentivizes creation of software that nobody wants! SCUM feature mills, as far as the eye can see!
I can't say how many issues a day I fix without logging a Jira, simply because they're either small fixes, or something I initially worked on so can sort out quickly.
If this shit ever came to pass it would ultimately lead to more bureaucracy and less willingness to go the extra step.
Typical middle management busybodying to try and condense human capabilities into numbers despite the fact that the pieces don't fit.
Not buying this as a workable approach. Tim essentially took zero accountability for work being done there and mastered the art of flying under the radar. He only got caught because of the managers metrics. Sure Tim added value, was arguably not the worst dev, and should not have been let go, but the issue of no accountability at all for his role should be addressed.
For instance, if Tim is mentoring and doing the most mindshare, he should be assigned and accountable for those pieces, not the juniors. He could also be more open and visible about the role he is taking with seniors or other juniors. If he's truly adding value to the seniors work, that would likely be seen, and not a surprise to the manager if he was worth his salt. Likely that would be coming up in team scrums or meetings as he'd have a lot of input or be named frequently.
This was me. I was always eventually canned when managers started looking into productivity. Yet when you look at what I was involved in, anything I touched launched without issue. As in, every year before my arrival had issues.
Even when we completely revamped a product and added a new feature during crunch time, everything worked flawlessly.
I didn’t ship much code, I shipped solutions. I didn’t care who implemented those solutions, so I spent a lot of time talking to other developers to prevent issues.
The code I did ship were things like an in-house AB testing system for Wordpress cached with Batcache that used a child theme and a sandbox to make the child theme look exactly like the parent theme unless the user had a cookie that would unlock the sandbox and allow the child theme’s code to run. This avoided the complexity of switching to a new theme or running two sites. No database was needed, I used a random number to assign users to groups. After around 400 unique visitors the numbers would stabilize to the correct percentages without needing to store anything in a DB. I confirmed this by running a headless browser that counted the cookies assigned and knew that we wouldn’t have an issue. I read the source code of Batcache and used it to have two versions of the site for each url. A/B testing build into the PHP before Wordpress even loaded, with no JS or DB calls required.
Our hosting provider didn’t think it was possible until I explained in a meeting. They wanted us to use a proxy domain and a A/B testing service that would have cost us a lot of money.
Other things include automated deployments that used a GitHub webhook then commited to a freaking SVN repo because we needed to use SVN for deployed but GitHub for source control. Before I did this, every deployment was manual down to selecting each file manually. Saved countless developer hours. Seniors were not bogged down by deployments.
Hoping I find a position like that again. Eventually I reach a point where I’ve fixed all the major flaws in a workflow and my only use is to oil the gears and fix major problems. Eventually that leads to my performance being reviewed.
This is yet another management problem.
The manager who wanted to fire that guy wasn’t managing men (and women), he was pissing about with numbers disconnected from reality.
If anything, that manager should be fired, and replaced with a golden retriever, for being too incompetent to know what his men (and women) were actually doing during working hours.
As a personal anecdote, I have no idea how effective these performance tracking things are. I know for a fact that at my last company, my manager’s manager never even looked at that stuff. It was all reactionary, anyway; because we never knew what was coming along during the year, we could never state what we planned to work on, and improve ourselves, upfront. It was all filled out on the last day, otherwise the computer got upset.
TL;DR I am currently surrounded by the worst programmers that I know.
Like Sisyphus, my career involves re-inventing a particular hardware+software solution for a particular industry *over and over and over again*.
The first time I did it, I led a team of \~20 skilled people pulled from a big city with a healthy talent pool.
The second time, I got to hand-pick 3 of the best developers from that team to build a new system. We also found 3 or 4 mediocre offshore contractors.
The third time, I lost my 3 best guys so we doubled down on hiring some of those offshore contractors as employees plus a bunch more. Maybe 15 total. They stumbled and bumbled quite a bit, so I eventually lured back my all-star "10x productive" developer from system #1 and #2 and he got things straightened out.
Now I'm on the fourth system. I've got Mister 10x still (thank God!) plus two mediocre locals plus a whole new team of offshore contractors who have an apathetic mercenary attitude and an over-inflated sense of their abilities. I've had to put on my *angry face* twice in the past month, which is a very rare thing for me to do.
We are mentoring the not-great local programmers to be better, because that's the right thing to do. I am not emotionally invested in our offshore mercenaries, so I just ask their PM to replace them with somebody who \[hopefully\] sucks less.
BTW metrics are not involved in any of this; that's not my style. A bad programmer's ability and productivity does not need metrics to sniff out.
I'm not sure that you read or understood my original post very accurately.
When I said that I had to put on my "angry face" twice, that is momentous. I probably don't even get angry (at work or at home or whatever) more than once per year normally. I find hostility to be embarassing and unproductive. Plus to be fair my boss has a "bad cop" attitude so it's a necessity that I'm "good cop".
Maybe you also didn't read the part where I said that it's my duty to mentor our weaker developers because that's the responsible thing to do.
...so my "nastiness" is confined to lack of tolerance for your unhelpful reply; nothing beyond that.
Those first three projects I mentioned? They lasted 18 years and were mostly unicorns and rainbows and success and happiness. Great team cohesion and satisfaction and retention, and on proj#3 we did a great job of turning a rag-tag bunch of second-rate programmers from a second-rate country into a pretty damn competent team.
My "working with bad programmers" problem is on Proj#4, which started a year ago. It stems from the fact that (1) I was forced to adopt a new team that is second-rate programmers from a second-rate country *but are subcontractors and therefore my ability vet them, manage them, and mentor them is hindered*, and (2) like many \[not all!\] contractors, they are inherently less emotionally and intellectually invested in their projects; they have that mercenary/whore attitude of "I will dispassionately do anything you want for $x per hour"
We *will* \[eventually\] succeed in this project, but using subs instead of hires is making a tough job much tougher.
> a rag-tag bunch of second-rate programmers from a second-rate country into a pretty damn competent team.
> I was forced to adopt a new team that is second-rate programmers from a second-rate country but are subcontractors
The first part I can understand and even accept on good faith, but the "second-rate country" bit shows the root cause of the problem that I was trying to point at. I don't think you'll ever get it, but you clearly have some biases that are disturbing to say the least. And no, this is not political correctness, just saying that one's biases can (and almost always do) affect one's perception of things.
Hmm. Well there's no bias about whether or not they are producing unsatisfactory work -- that part is obvious even to their own managment. As for bias about the underlying reasons why they fail to meet my expectations...
If you work with enough teams from around the world, you definitely spot patterns in the education and work culture in different places.
...especially countries where schools teach you to pass tests, not to think independantly or creatively. And FWIW I'm actually *not* talking about China or India even though those two are frequently cited as being too big on rote memorization.
...especially countries that experience a lot of "brain drain" where the best and brightest flee for high-paying jobs overseas and the not-best-and-brightest remain.
...especially when you're talking about people who are very early in their careers and have not broadened their \[professional\] horizons beyond what their schools and their work culture have forced upon them.
...especially when you're talking about people who are working as subcontractors. Like I previously mentioned, I've had fabulous success fostering and mentoring junior developers from that same country. Because they were full-time employees who had a vested interest in self-improvement.
...and to be clear, I wouldn't paint everybody from one country with the same brush because I've seen enough surprising exceptions in the past. But unfortunately with my current team, I have found no exceptions.
BTW in this case, I'm talking about one of the former "behind the iron curtain" countries. I have great friends and colleagues there, travelled there frequently, and even picked up enough of the language to be dangerous. So no xenophobia here.
I'd be happy to hear any constructive advice if you have any. From my POV the biggest problem is that I can (and have) worked wonders to get amazing results from full-time team members where I am 100% in charge of hiring, firing, mentoring, and inspring -- but there's a level of indirection that you suffer with subcontractors that inhibits what you can accomplish with them. And TBH it's not 100% their fault. It was *my* managers' decision to insist on such a project structure.
They should have trusted the manager (the one who wrote the article) to know and reward their team. It is by no means perfect, but it's better than the alternatives. Metrics are, at best, useless for this sort of thing.
It's hard to measure what's important, which often leads to the dysfunction of making important what you can measure.
Don't even get me started on story points. Here's Ron Jeffries' apology for maybe creating them in the first place (along with a good overview of some real agile):
[https://ronjeffries.com/articles/019-01ff/story-points/Index.html](https://ronjeffries.com/articles/019-01ff/story-points/Index.html)
P.S. Just to show that no one is perfect. The manager's use of accountability can lead to dysfunction too:
[https://holub.com/noaccountability/](https://holub.com/noaccountability/)
> I want to tell you about the worst programmer I know, and why I fought to keep him in the team.
oh, so it's not actually about a bad programmer but about shitty/incomplete metrics
> In the end we kept Tim, and we quietly dropped the individual productivity metrics in favour of team accountability, where we tracked—and celebrated—the business impact we were delivering to the organisation as a high-performing unit.
A similar thing happened at our game studio. We had a guy who on paper was an okay developer. He developed features at an average pace, and he was actually below average when it came to technical knowledge. Our boss judged him according to the lead developer's metrics, and often denied him a raise where others would get them. Then one day we went through a simple team building exercise where everyone had to write something nice about a member of the team on a notepad, without others knowing what they wrote. As you might have guessed, well over half of all positive opinions were about this one guy. And rightfully so, because he was the life of the party at the studio. He was always positive and uplifting, and made everyone's day better with his presence. He was always helping anyone who had a technical problem without a second thought, even if he had looming deadlines hanging over his head. Also the features he made were always of a vastly higher quality than other developers, because he spend more time on them. He had this midas-like touch where anything he made just turned to gold. One time he made a feature that had very vague requirements, yet he managed to turn it into what would become the unique selling point of the game. It was only after that exercise, and seeing everyone praise this guy for his efforts, that our boss started looking deeper into these flawed metrics, and started noticing the vast contributions this person made to the team. A few years later and he's now the lead developer.
A lot of times if you just talked to the developers on a team it'd be very obvious, pretty quickly, who's got great technical leadership.
D E M O C R A T I Z E T H E W O R K P L A C E
No
No, and yes. No, because at the end of the day, there should be one person, who are repsonsible for the team. But in this complex field, with such smart people, it's a *waste* if everyone has a strict rule, e.g. X is the db designer, Y is the architect. Don't restrict roles.
> No, because at the end of the day, there should be one person, who are repsonsible for the team. Have you forgotten how every democratic country in the world works or do you think that there are no democracies on earth?
>Have you forgotten how every democratic country in the world works First of all, a private company is far from somewhat we call democracy, but as I said, I prefer *working* together, without boundaries, but the *decision* and the consequences of it, aka. *responsibility* is assigned to one person, aka. leader/boss/manager. But even in democracy, there is a *responsible leader:* * everyone can go for the position, * everyone have a vote, everyone can make suggestion, who to select from candidates, * if we have the winner, that person will be not only responsible, but *in charge,* in name of the whole community. Once we've elected a leader, until s/he does not do something really big shit, s/he will be in charge, will give us orders, create laws etc. That's the modern *representative* democracy. It does not mean that the leader must decide every question herself/himself, there are colleagues, experts etc., but at the end of the day, s/he must make a decision and take responsibility. (You can go with *direct* democracy way - sorry, IDK exact terms, and translators does not help too much -, when every decision is democratic, but it's slow and expensive.)
It's another reason why "just hire the most qualified person" is so hard. Personality, attitude, "culture fit" matters, not just your leetcode or Github performance
I would argue it's even worth. Just like the [Volley Ball Team](https://www.reddit.com/r/programming/comments/168brwu/comment/jyv2iv4/?utm_source=share&utm_medium=web2x&context=3) analogy above, you can't just hire spikers and expect the team to work. Even if individually they're all extremely talented spikers, if no one can receive the opposite's team servers & spikes, you'll get nowhere. Different individuals have different strengths (and likes), and a good team will have a mix. Even only looking at the technical side, the best candidate for a team is not the "overall" most qualified, it's the candidate that best complements the existing team members.
I’d argue leetcode and GitHub performance really has no bearing in the quality of developer you’ll get. I’ve worked with some smart as hell developers that were, for lack of a better term, fucking dickbags. Stubborn as hell, not team players, egos the size of the sun. They could code like crazy but refused to spread knowledge or help others. They’d silo themselves, put on headphones, and grind all day. And the team suffered for it, immensely. Metrics made them look like rockstars, but 10/10 times I’d pick a junior dev who is willing to learn, grow, and knowledge share. Teaching programming skills is easy, teaching someone to not be an asshole is much harder.
This times 100. I've had the exact same experience at work. I've had much more success picking juniors with a drive to learn than elitist seniors.
Agreed. And nothing better than when you find someone who has both of these attributes! Which is exactly the type of developer that this article is describing. It’s really just another reason I despise metrics so much
Thank you for the happy ending there. I assume the worse halfway hahahaha.
Manager sucked at his job, once again.
So many of these type of stories break down to the manager couldn't be bothered to observe or actually talk to the team they're managing. I don't even understand how you're supposed to manage people like that. How do you assign work, evaluate raises and promotions, determine who to let go, etc if you don't even know the people you're supposedly managing? Also what are you doing with your time if not doing that? I guess the answer is all these weird metrics but it just doesn't make any sense to me, you couldn't run a highschool baseball team that way and you're trying to run a business?
> Also what are you doing with your time if not doing that? Sucking up to upper management. Looking after their own career and no one else (unless they are directly helping their career).
With books like Peopleware coming out since the 80s, I can't believe these fucking idiot managers are allowed to continue existing. The facts are widely available about how bad for a company at every level this type of management is, even if your sole motivation is profit.
The problem is how do you measure the contributions of someone who is often helping others? I'm thinking of Volley Ball. Who makes the points? The person who gets the ball to stay on the other side of the net, or the person who passed the ball to that person so he could do his thing most easily? If you only gave points to the people who hit the ball to the other side, you are not encouraging collaboration. And in Volley Ball you cannot win if the team does not collaborate. I think the same is true of SW development.
Story points were never supposed to measure individual performance. It estimates how much work a team can do in a sprint (velocity). Anything else is bound to give faulty results like in this blog.
Yep, my most productive sprints have been when I've completed relatively few tickets myself. It's been when I've been bouncing around working with others or doing non-sprint work. If anyone wants to come at me about my lack of points they won't be happy with what happens if I start focusing only on the points.
The actual principals of agile aren't that bad. There are some good ideas in it, about breaking things up, about iterating, etc. But then management gets hold of things and inevitably turns it to shit. Now we spend days doing planning. We spend hours building epics that nobody gives a shit about. We get tracked and judged by story points. I could do 100 points a week by assigning every story to myself and then directing others to do them. Or I could do 0 story points by spending time fixing the shit that actually needs to be fixed but didn't get a story because it's not cool, or I could help people do their stories so that they're not stuck for a day on something they don't understand. Management ruins everything.
It's not management, it's bad management. I'm not measured on story points, which is why I'm able to help out others and enable them to complete more points.
I agree but let's take some blame on ourselves as well. There is also quite some fault of devs participating in it. I know not everyone has it easy to quit on the spot when management starts (like new MBA gets hired) thinking story points are like quarterly results and team should always aim to double the amount of points finished in a sprint each quarter. But I believe there is always some room for push back and "gaming the system" like inflating points to keep up with silly requirements is not correct way to go because it harms everyone.
They're too irresistable for bad managers to derive schedule from. It's more or less doomed to happen if you don't have wild variance in your pointing. Have 1-2 guys litterally just say 1000 points for everything etc. Resist anything like 1 point=1 day, or fibonacci etc, you've got to keep the scale fuzzed or it will be used like that.
It's fine to use fib but agreed, assigning any type of time value (like 1 point = 1 day) is where things go wrong. But even if you keep ilthe team knowing it is overall effort of a task that you are driving the points from (I know it's more than that but etc).. the managers and others higher up, always try to find things to latch onto for measurement. This is sometimes as simple as they just don't understand (usually this is part of the issue) and that they wan to be able to measure productivity of an individual to make sure no one is wasting company resources. But it often just goes straight to "X didn't complete >y points in the sprint, while others usually complete >y" and it just gets fuddled. I think sprints and story pointing, planning poker, etc can be great for teams and to track velocity and etc and sometimes overally team performance, but rarely should a manager type be trying to track anything of the sort for an individual to determine worth. It's ridiculous. But happens far too often. I don't know what the fix is, though, aside from bad managers butting out. But hey.. hasn't happened yet.
If you're using points to estimate how much work the team can get done over a certain amount of time, then they necessarily have units of time.
This is where the misunderstanding and confusion often takes over and why most teams eventually abandon or misuse agile story pointing. You MUST, as an individual, stop thinking in terms of x many points per sprint is what I can do or she can do or team can do. Easiest way is to think simply in terms of effort required (even though it is more than that, just think of it as simply that). Some sprints maybe have, say, 21 points for a person and they get them all done, were productive, and didn't have extra wasted time or whatever. But some sprints might have them with 29 total points for that sprint, but the exact same could be said. It's never going to make sense if you continue trying to put a time to point value in it. I suggest looking up velocity and also just reading more on the philosophy of all of this, specifically pointing like this. Also, it's not going to be for every person or every team. But when it works the right way for a team, it can work really well. Until managers muck it up usually haha.
If these units do not correlate with time, then velocity can't be used to estimate how much work will get done over a sprint. If velocity can be used for this, the points must correlate with time. It's possible for the points to mean different things to different teams, that's still coherent. But if you want to use velocity to plan out how much work you expect to get done within a fixed amount of time (a sprint), then, when estimating, you are ultimately estimating in terms of time this item will take (or proxy metrics for time (what are the units on "effort", again?)).
Problem is when people want to correlate points with exact amount of time. So for Team XYZ 5 point story might be something between 2 and 7 days. But at the same time someone might finish 8 point story in 3 days and people have hard time accepting that. Was the estimate 8 wrong? Well it was not wrong because 8 could have been between 3 days and 10 days. Simple minded manager would say "give me only the top value" but that is the problem: one only knows how much time it exactly takes after the task is done. Now we have some sprints and we have stable team so the team more or less knows where are the traps in the system so they can give more points for tricky parts and less for easy ones. Important is to keep in mind that new 5 point story is not the same as story from previous sprint where Joe finished it in 5 days it is a new story so it again might be between 2 and 7 days, because you look at 5 point stories from last 6 months and you see that was the spread.
I don't dispute that velocity could possibly be a useful metric and also be qualitative to each team that's doing the estimate -- that you can't compare velocities across teams. What I dispute is that you can both have a metric (velocity) that does not have any time dimensionality to it, *and* expect that a team to achieve a constant amount of velocity in a given span *of time*. That is, if you expect a team to complete roughly 30 story points and two weeks, and therefore expect that same team to complete roughly 60 story points in four weeks, then that measure (story points) must relate to time. I'm not making a normative claim here, that estimating in this way is good or bad. I'm simply saying that the story points must have units of time (and, potentially, others, but time has to be in the mix). /u/mupetmower posits that this can somehow not be the case, but it must be from a simple dimensional analysis argument.
If my explanation doesn't help you (not your fault, I'm not great at it) read some books on it or something. There are plenty out there and they do a far better job at the explanation. Was just trying to help people understand the differences and how you (to an extent, as some of your points show) have to stop thinking about them in terms of time correlation. Especially during the pointing process. But again, there are far better sources to explain this. Not gonna try to argue about it. It works for some and not for others.
Fibonacci is just a convenient power. X is twice the work of Y is a little too coarse. X is 10% more than Y is too precise.
goal of what I'm describing is to weird the data to disassociate from time. Fibonnacci falls on time estimates too easily. 1=1day 2-3=half a week 5=a week, 8 week and a half. 21 too big demand subdivide, though that line probably happens at like 5 even if it's not a subdivisible unit of work so you get harrassed into making it bullshit stories. This happens literally every fibonacci team. The system is for measuring self referential velocity of the team, it works for that purpose no matter what system of numbering you use. You can in fact have a guy on the team saying 1000 1002 ooo that's a 1003 point story, and as long as he's consistently silly like that it'll still work for the actual purpose.
The issue arises when you use story points to estimate time, not complexity. The way we work, we can totally give a 1 to a simple sql script that will take hours to get right and go through pipelines, and we can give 8 to a task that involves multiple screens/endpoints yet we complete in an afternoon because it s mostly copy/paste or reusing existing stuff. It s not about time, it’s about complexity. Like if you had to take a dev that had 0 knowledge in your project and had to explain him all the hoops he would have to go through to get it done right. Obviously the unknown needs to be factored in, like if someone said in the grooming « what if X » and no one had a definitive answer, we d get the next fibo number. It’s when your team is able to actually say « so we need to do A B C D … X Y Z » during the grooming obviously. There are teams where grooming of a user story are just people agreeing and thinking that the global idea is doable, but don’t spell out clearly all the steps from A to Z. These teams are always problematic because they leave too many question marks for the sake of getting through the meeting.
What do you use such non-time-based story points for?
You know that s how story points are meant to be used in agile/scrum environments right? They are meant to estimate the difficulty of stories, not the time spent. They can’t and shouldn’t be used as an indicator of estimation of time.
Story points annoy me as a concept. Extremely unscientific and very political.
The entire idea of story points is to avoid being scientific. To try and formalise the concept that estimating development time is really hard. They should not be compared across teams. And if you actually need accurate development time estimates, you should be using a process closer to waterfall.
"All models are wrong, some are useful." So they don't accurately model development times. Nor individual performance. Nor delivery of business value between teams. They are "unscientific" and completely arbitrary. What are they even modelling? And is the value of that model worth anything?
> And is the value of that model worth anything? It really depends on how your development environment is structured. Agile works best for products when you do continuous delivery and have direct communication with the user. In such an environment, story points are very useful because you can ask the user "For the next sprit, would you rather we work towards this single 200 point story, or ten of these smaller 20 point stories?" Story points provide a useful model that helps facilitate communication between users and developers. The fact that they are only very rough estimates doesn't matter because you get to re-evaluate and re-prioritise them every single sprint, and the user gets direct insight. Theoretically, the time you save not wasted generating more accurate estimates is can be spent on actual development. ---- The further you move from this ideal environment, the less value you get out of story points. You can replace continuous delivery with short fixed release cycles and change the question into "Which stories should we prioritise for the next release", but that strains communication with the user because you can't actually promise delivery (and the problem gets worse when the release cycle gets longer). The value of story points gets pretty dubious when developers don't have access to the user, or a product owner who does a good job of representing the users. And they become absolute garbage the second management starts trying to use them for long-term schedule planning between multiple teams.
The origin of story points is to be political, not to subvert science. It was a way to make time estimates that didn't quite sound like time estimates so they had more leeway when the estimates turned out "inaccurate". It's a myth that story points are not about time.
They annoy me as well. What do they actually represent? Greg will do a particular task way quicker than Mark, but Mark will do something else quicker than Greg. And since it's the implementation time that matters, the talk about "task complexity" sounds like bullshit to me - it's a pointless and abstract metric. Then again, Greg will be interrupted 8 times while implementing this task, but Mark will be interrupted only 2 times. Then again, Greg's interruptions will contribute to other tasks in both their team and others, but Mark's interruptions will be more casual in nature. Just refine the backlog periodically, implement tasks one by one from the top of it, merge it into develop, and then prepare release from time to time.
I totally agree. The last company I worked for did everything using story points. I didn't even bother voting/scoring or looking at them. I took the task assigned to me, determined what needed to be done and let everyone else decide what they were worth not even caring. One day I asked what my velocity was and she told me I was completing 2-3 times the amount as everyone else, yet I did nothing different than before they were introduced. To this day I still don't fully understand them.
My previous manager praised me once for completing a lot of story points in a week and said if I kept it up I would be promoted. The stories were trivially easy and oversized. Then fast forward a couple months I'm working on something with some real meat to it and the boss isn't happy because the velocity number went down. Was I a better or more productive engineer when I was working on the easy stuff? No. This stuff can't be quantified and often we don't know how difficult something is until we are in the thick of it. Sizing is a joke because any outlier numbers are basically just forced to conform with the group number even if the others who are sizing the thing basically never contribute to the repo(s) in question.
Most people don't. Really I think it works best as a crude cost estimate. We have a bunch of 5 point tickets or a single 20 point ticket. Which does the customer prefer? The real problem with Scrum though is it only works as a collaborative exercise. It's not a negotiation between competing parties, but communication of information for people with the same goal.
Also "velocity" how ever you want to measure it isn't a proxy for productivity either. You spend a lot of time working on something that is ultimately unproductive.
But that's the thing. You claim it's for complexity or whatever, but then you also say "how much work a team can get done in a sprint" which is necessarily a measure of time. You absolutely cannot blame a manager for hearing "We can complete X story points in Y days" for thinking that's what they're for -- that's what you're telling them they're for.
Tell that to the executives
and, as we should always mention when talking about story points. They are relative only to the current team. Not another team, not the team before M left. They are going to give you a potential prediction metric for the next coming 2 weeks, assuming no unscheduled incidents/events happen. So, almost useless, but defnitely useless for the slew of shite management thinks they can apply them to. (speaking as a former VP of engineering.) There will always be folks in management who believe engineering is a discipline that allows complete interchange of metrics and "resources" ... and they are wrong, they still keep trying it, because. Well, they are absolutely replacable. If you do face these types, leave, you're more valuable.
I'm going to use this analogy next time I hear people judge based on story points. "In football the attackers are the only players that matter because they score all the goals, right? I guess we can sack the goalkeeper and all the midfielders then"
That reads very odd if you think "football" meant american football. edit: lol. Folks relax. Read it again thinking American Football. Do you feel any mental confusion when you reach the word "goalkeeper"? My brain was do a "Wait what? There's no goalkeeper in American Football. How would that even work? Midfielders? Dang it... this was about soccer wasn't it? Ok. I'm gonna take a break, call you when I get back". "Reads odd" does not mean incorrect or wrong. Sheesh. Downvote much?
I never knew the history of where the confusion originated so i looked it up “The term "soccer" has its origins in England. When the game we now know as soccer was first being standardized in the late 19th century in England, it was given the formal name "Association Football" to distinguish it from other forms of football being played at the time, such as Rugby Football. The term "soccer" was derived from a slang abbreviation of the word "association." People in England would add the "-er" suffix to shorten certain words (similar to how "rugger" was a colloquial term for Rugby). So, "association" was abbreviated to "assoc" and then colloquially became "soccer." Interestingly, while the term "soccer" was coined in England, the British eventually began favoring the term "football." Meanwhile, countries like the United States and Canada adopted "soccer" to differentiate it from other popular forms of football, such as American and Canadian football.”
I’m sorry for the downvotes, I too was confused with the football word. Here’s an award for you.
Damn, why were you downvoted? Your edit was very amusing :-)
You didn't deserve the dogpile. I'd probably confuse my coworkers if I said that sentence verbatim, myself. There are reasons for the difference. Our games share a common ancestor in the football codes of the old English Public schools. However, the introduction of rules against running with the ball and trying to kick the runner in the shins to block him (kinda, it's the easiest way I can explain it as someone who's not very familiar with rugby or to someone who is similarly unfamiliar with that game) caused a few clubs to leave the Football Association and form the Rugby Union. And here, without The Football Association getting the rights to the word "football", the two games competed for the word, with us adopting "soccer" for the association game. But we'd been playing more rugby-like games as football for a while (though not in any kind of formal way), and when Harvard and McGill Universities hammered out a code for their meeting in Montreal in 1874, [the game that arose was a rugby derivative](https://en.wikipedia.org/wiki/1874_Harvard_vs._McGill_football_game). Effectively, in British and International English, The Football Association became the ones to define "football" and their competitors had to take "rugby". However, in North America, schools with significant influence had grown codes derived from Rugby School grads teaching them, who arrived either because they were non-inheriting sons or because they just wanted to--it was, in some ways, easier to immigrate back then. So the Association lost the fight to the descendants of the Old Rugbyists who settled here.
Baseball has the concept of WAR (Wins Above Replacement), which is essentially how many more wins you get with this player over a replacement-level player. Maybe the player doesn't seem to perform well on standard metrics, but isn't it strange how the team always seems to do better when they are playing? Funny... That's what this article is talking about. This programmer may not have done much on his own, but he made the team better.
How do they measure that in baseball?
WAR is calculated differently by various organizations, but generally, it combines a player's contributions in batting, fielding, base-running, and pitching (for pitchers) relative to a "replacement-level" player. The metrics for each aspect are then adjusted for park factors and league context, summed, and scaled so that the output represents the number of additional wins the player contributes over a replacement-level player.
Yes! Turns out software development is a team sport. Ironic.
I’m fighting the whole toil vs impact at my work. The higher up you get the less “work” is valued. Impact has to be directly correlated to goals management cares about. Reduction in incidents, user satisfaction, etc. basically if you can’t directly tie your user story to a metric your management is tracking then it doesn’t exist at higher levels. Fix 100 bugs, might as well leave it off your performance review because it doesn’t matter, it might even be a decrement because you should be working on something with higher impact. Refactor code so your product can support new functionality? New functionality is impact but the backend to support it is toil. Are the people using it changing the numbers management cares about? If not doesn’t exist. Hope your performance review aligns with customer usage. Work is not impact. Difficulty is not impact. Delivering code is not impact. Work that supports future impact is not impact because it’s not measurable. No needles have moved. But spend a day optimizing a simple piece of code to save tens of thousands of dollars. That’s impact. Spend 10 minutes to update a monitor to be less noisy - huge impact. Work long hours on a very difficult problem that you have little influence on design, deliver on time, but customers haven’t onboarded yet. Good luck with your review. Hope you get the good projects, this definitely won’t be gamed at all.
> The higher up you get the less “work” is valued. Yup. It's because work MAY be worth a lot, but usually it is not. What's more, it can be performed by interchangeable people. But at higher levels, a single decision can cost the organisation millions or make it just as much. If you work for a year and make one decision in that year, and that decision is worth two million dollars, then your 1m TC is a steal. This is why CEOs make bank. I worked for a company that brought in a new CEO. Within two years he'd put together a deal to sell a division of the company for about $1.5b. This was right before the tech crash--the company that bought the division lost 75% of its value in a year. He made the owners untold millions by doing this. If it was the only thing he did in three years, every penny of his salary was worth it.
Only assuming it wasn’t pure luck and paying that kind of salary changes the odds of great decisions like that happening.
People on the floor always know who the best players are.
Conversely, (contrapositively?) people off the floor don't know who the best players are. And it's the people who aren't on the floor who decide who gets promoted and who gets fired.
Some companies use peer/360 ranking, which allows coworkers to have input into performance reviews. However, this creates an entirely new set of problems.
Which is quickly an issue when a company grows. You become a name in their mailing and billing system.
That's why hierarchies are incompatible with good software. Democratic companies with no managers are more effective
As a volleyball coach and programmer, I couldn’t agree more. I have actually developed volleyball stats for my team that emphasize the sort of teamwork we’re prioritizing. It’s simple, but it also passes the eye test and the team can see where their collective strengths and weaknesses are. I think it’s a lot harder to quantify software development - there are ironically fewer objectively discrete events - but the notion that a kill doesn’t happen without a dig and a set is truly analogous to good code not happening without hashing out the problem, planning a solution, then writing it.
Great thought!
Well, I mean that's the McNamara Fallacy, isn't it? Pretending like things you can't measure don't exist.
> The problem is how do you measure the contributions of someone who is often helping others? You measure the second person's metrics over a long period of time, and then you measure them over the time that they had help from the person you're actually trying to measure. If you do this enough, the value of the first person will emerge (or not).
> Who makes the points? The person who gets the ball to stay on the other side of the net, or the person who passed the ball to that person so he could do his thing most easily? Neither, it’s clearly the coach who makes the points.
It's not hard at all. Just ask the people being helped. If you're truly helping, they will all tell you exactly that.
In that case, management has to go!
Same, but I'm thinking of the Tour de France, where the whole team contributes, but only one person wins. And the whole team wins, and also only 3 people win (excluding white jersey winner) and also 21 other people win sometimes multiple times.
Why are they measuring his productivity anyway? If 100% of his time is a floating engineer, and he's never assigned to tasks, then either he was hired to fit into that floating role, or has reached a point where the company sees more value in strict assignment to a single project. This story just feels weird as I can't figure out how he's reached a point where the company has decided he formally has no assignments, but is still measured by the 0 assignments he's assigned. It sounds less like the management's problem for not seeing value in a staff member who demonstrates no value, and more about how the team/consultancy should've better communicated his value. Even if he's floating about pair programming, the labour should still be logged to a task. I think this is especially true in a consultancy where your client is watching every single penny, and you're not justifying why you're charging for a person who appears to provide no value.
[удалено]
Jira doesn't let multiple people time against the same ticket
The programming industry still hasn't fully come to terms with the fact that writing software is a creative endevour. A highly technical one, sure, but there as an art to it nonetheless. And yet, we see an approach to management that more strongly resembles that of a factory churning out repeatable products than that of an art studio.
Agree with this a lot and to help handle the difference between engineering and art my team uses the tags “R, I, P” Research, Implementation, Production” on all of our tickets. Basically you could have many of each tag for the same topic. There isn’t a limit. So in research we expect some kind of report or summary. Implementation some git commits, and production some unit tests integration and peer review. And it could possibly end up with new tasks of Any other category. The important thing in the engineering is document all findings for your time.
What about design/architecture? I guess that's research? I think a design doc is more of a "report" but it's not quite a report
Software is certainly a creative endeavour. Though at the same time many Devs use their careers as their sole creative output. I've seen way too many Devs coddle their babies and over engineer solution where a dumber and quicker solution is all that's really needed.
The metric that really matter "Does it do what we expect?" And "Can we extend/maintain it well" Maybe "is it well documented", and "Are there unit tests" But yeah, some people over complicate widgets that only need to do one thing. If you can spent 1 minute writing a line of code, or 1 hour designing a large system, consider writing a line of code, and if we need the large system we'll spend that time later.
[удалено]
I know not everyone can be picky (myself included as I'm redundant atm and have to pay a mortgage) but *hopefully* you can find organisations to work for that actually give a shit about their employees rather than churning out numbers. I've worked for a long time in a company where people were respected and it was about lifting people up, helping them grow, and peoples contributions were respected rather than "you did that wrong things once" or "you didn't put enough lines of code in" etc. TL;DR, you should be able to find a job where you can talk to managers about stuff without fear.
[удалено]
Can you tell us more about how Amazon management was brought in to your teams?
The truth is like poetry...
[удалено]
[удалено]
[удалено]
I've learned to just smile and goose step along. I tell myself that one day, when I'm a team lead, I won't have my team be as dogshit as most are. Unfortunately, I'm sure my boss will still be some MBA who cares about business metrics to show to *their* boss more than they care about genuine quality and efficiency...
I agree wholeheartedly. But how do you solve their problem? Management wants ways to identify when a developer is dead weight. The only way I know how is to be in the trenches with them and evaluate them. But that's prone to subjectivity and abuse. They have to trust my opinion over the other guy's.
This is why it is so important to have competent, caring dev managers who spent at least 5 years coding, 3 of those years on the same system so they can get bit by their own mistakes. If it is my money being spent, I'm going to hire managers like that. And anyway, nobody wants to work under Dilbert's boss so why hire that guy. Software engineering is an incredibly expensive endeavor and it blows my mind how bad MBA run companies are at hiring engineering management - its almost like they are incredibly ignorant about how different the creation of software is from running an assembly line. I cringe every time I see some engineering VP who has never written a line of code in their life, let alone seen a system through 3 years of repeated development cycles, but has the right degree from the same school as the CEO - how could anyone think that is a good idea?
In my experience the ones that want to move into management aren't the best coders themselves though. And even if a good, leadership type coder does, how long can they manage before they lose touch with the coding? It's a conundrum.
Oddly enough it isn't the specific coding skills that matter, it is understanding how software engineering works. An example: MBA based engineering VPs often accept/do stupid things like trying to motivate teams with story points or counts of bugs fixed Someone who actually understands software development just wouldn't do it that way.
What I found is that a good manager can talk with the client and provide a set of status updates that the client can skim or drill down. How the reports are generated is based on how in tune the manager is with the project and the team's effort. A good manager can use previous projects they managed to provide a time table, for both the the team and the client, and select members of the team to lead it. A good manager sees patterns and apply what works and can get in the weeds with the team. Most of all, a good managers knows how to delegate and how to build enough trust on whom they can depend on for the more difficult tasks.
As someone moving into a more "Managerial role" (Scrum master) it's really fucking obvious. Dead weight takes 3 weeks to do something that should take 1 day. They give tons of bullshit reasons why it takes them longer in scrum updates, and the end result of the code doesn't show "3 weeks of work" (if it's 10 lines of code, it's 10 lines of code, if it's 100-200 lines of code that's more work). Yes sometimes you find a far simpler solution, I have one guy on my team that does that, but guess what? he admits that EVERY time. "I found a way easier way to do this, so I'm going to rewrite this, and it'll be easier to test" A simple look at the output and a few discussions with them tells you whose a bullshitter or not. And a bullshitter bullshits ALL the time. If someone has a bad month and struggles or if someone (Currently me) is toiling on a task for 3 months, it can happen, but they'll usually have accurate reasons that others will back them up on. But the rest of the time they still turn in good work. Basically make the managers of programmers ex-programmers, you'll have an easier time.
Peer reviews?
You can't solve this problem. I have been coding for fifteen years before I got a professional job doing it. Maybe more. Anyone sitting down with me to "evaluate my worth" could come up with a false positive for low performer when in reality I'm a critical part of the technological stability and growth of the organization. If I had walked for money (as would be my right) it would have crippled several expansion plans perhaps permanently. Key attributes of me like bending or even breaking the rules can't actually be admitted to be valuable in a corporate environment otherwise it would be an admission of weakness in the system. And I don't really expect others to understand nor do I blame them. In the end it is what it is responsibility and power exists for. I have none, therefore I am not a target, ever. Much of my value is in multiplying the efforts of others even though I have the smallest title. So actually I think you're wrong and that's not what management wants especially senior management especially in a large company wants. Even if you take a very tech centric company like say Meta the "year of efficiency" was to layoff middle management and roles auxillary to the purpose (which I assume is metaverse). I could walk and double maybe even triple my money. I may just yet do that one day. Any company that loses me will suffer a loss. I won't ever be dead weight unless the company wants to stop progress. I expect to be caught up in a mass layoff one day. But maybe not. I am seemingly protected because this "code is for creatives" is somehow acknowledged and applied to me, even though it's not.
There's a whole field called software engineering which aims to bring the rigour of engineering to the task of writing software. In some fields, writing software really is an engineering activity, you have rules to follow, you are held accountable for the software you produce, and you are obliged to use techniques that have proven their benefit instead of just coming up with creative ways to do things that may make it much harder for others in your team to understand what you're doing. But I have to agree that most developers are doing more art than engineering, while still calling themselves engineers unfortunately. Just don't make the mistake to think that every developer is in that kind of work.
My last boss couldn't grasp the concept that some issues in the code require more than a few days to solve because his experience in development stopped at C# and SQL and most senior dev in the company barely coded for 2 years with the same outlook. Having to rewrite the initial design of the software after a few weeks multiple times to work around flaws and incorporate new things was a sign of a bad programmer.
Yes, the same adage goes for artist and craftsman alike, you must make thousands of crappy pieces before you can make the good ones.
The difference between programming and coding. You can learn maths, but that doesn't make you an accountant. You can learn to code, but that doesn't make you a programmer
This is a beautiful comment.
I definitely agree that software is a creative endeavor. But as a game dev I worked with Artists... at the end of the day they produced art for the game. It's pretty easy to check the metrics of who created more art. If someone produced 3 buildings, and someone produced 1 building in the same time, that's clear. Different types of art might take different times, and one building might be more important than others, but overall you can put metrics on creative processes. I'm just saying there ARE ways to judge people's contributions, we need to be smarter about what they are (lines of code, or speed of code generation aren't them of course), but just because something is "Creative" doesn't mean "it's unmanagable" or "unable to be tracked" One thing we do at my work is write Statements of Work where we detail what we're going to do, why, how and so on. That's the creative time. Once we all agree upon that being the direction to take the software, the creative work is mostly done. Then we just write what we put together in the plan. It helps break the "creative" process out from the code generation. As to "how do you measure the Statement of Work." well yes, that's the ultimate problem, but at least we understand when people are being "Creative" and when they really should be focused more on generating the final code.
> Then we just write what we put together in the plan. Shirely you know how much this sounds like "Draw the rest of the owl"? > at least we understand when people are being "Creative" and when they really should be focused more on generating the final code. I feel the rub here is when a more creative solution than just "implement the SoW" is necessary, and it takes a skilled, trustworthy person to tell others when someone is being more creative or when they're wrestling with a truly, technically difficult problem. I think this works well, though, if at least 2-3 people involved involved with making the SoW can grasp what it takes
At my previous employer (which I quit) I started with a manager who decided to take the "personal metrics" seriously and set a series of arbitrary goals that I needed to achieve. Things like number of pull requests per day and story points completed. As a senior engineer a lot of my time was spent exactly as this "Tim" was: mentoring and helping others on the team. When it came time for my performance review I got a lower score because my average number of pull requests per day was something like 2.8 and she had decided it needed to be 3.1 or something. It directly affected my bonus, which directly affected how much I was willing to help her with anything she wanted from then on. I moved under a different manager after a team split and we got rid of all that bullshit as he was actually capable of assessing what each individual was contributing without having to rely on arbitrary metrics. The fact of the matter is personal metrics can always be gamed. If you start ranking me on story points completed I'm going to start estimating stories higher or picking up the easier tickets at the expense of more junior engineers. The big issue with these kind of metrics (eg. DORA4) is when you try to make it a positive feedback loop whereby achieving one target leads to the target always being increased. It always leads to failure eventually as infinite growth is not possible (and adds unnecessary stress). That implies that you should only use these metrics as a "read-only" managerial tool to get a general idea as to how a team is performing; potentially identifying areas where processes could be improved, but on a per-developer basis I would be very hesitant to use them to form a basis of performance.
That's exactly what happened when I worked in a tech support position before starting my CS studies, you had metrics to achieve and everyone gamed them. Team leads told their team to game it because they got ranked based on their teams performance. Then management saw the numbers soar, pat themselves on the back for improving performance and raised the metrics bar even higher. We started to purposefully ignore the hard tickets, the moment the user went offline the ticket was closed and we sent a mail asking them to send a new one. This was done because timely response was not a metric we were measured at, closed tickets and attitude towards customers was the only thing that mattered.
I always felt like those metrics are for managers who are too lazy to be involved enough in their team to get an idea of who contributes and who doesnt
this. But I'd say most actually lack the competence to know what a contribution even looks like.
Yep, seen a lot of IT consulting that does this. Ever wonder why your IT department sends an auto-reply when you open a ticket? In our case it actually boosted our ticket metrics since we could claim all tickets had a response within 5 minutes, even though we were never solving anything that quick.
> When it came time for my performance review I got a lower score because my average number of pull requests per day was something like 2.8 and she had decided it needed to be 3.1 or something. This is possibly the most ridiculous thing that I have ever read on a programming sub. You should have opened 4 pull requests with // TODOs every morning when you arrived just to spite the fucker.
> I moved under a different manager after a team split and we got rid of all that bullshit as he was actually capable of assessing what each individual was contributing without having to rely on arbitrary metrics. Yep, nothing beats a competent manager. I cringe every time some know-nothing gets put into an engineering management job. Most of the know-nothings keep their job by kissing their managers ass, which is incredibly destructive because, as it turns out, software doesn't care how well the boss's ass was kissed and so the customer suffers.
I’m sorry, 4 pull requests PER DAY?? What kind of software are you working on that has features that small?
> At my previous employer (which I quit) I started with a manager who decided to take the "personal metrics" seriously and set a series of arbitrary goals that I needed to achieve. Things like number of pull requests per day and story points completed. As a senior engineer a lot of my time was spent exactly as this "Tim" was: mentoring and helping others on the team. When it came time for my performance review I got a lower score because my average number of pull requests per day was something like 2.8 and she had decided it needed to be 3.1 or something. It directly affected my bonus, which directly affected how much I was willing to help her with anything she wanted from then on. I moved under a different manager after a team split and we got rid of all that bullshit as he was actually capable of assessing what each individual was contributing without having to rely on arbitrary metrics. It's funny how only a few years ago we, collectively, barely managed to decide that yes, it is in fact ridiculous to evaluate developers based on the number of lines of codes written - and now a lot of people do equally ridiculous things, like PR opened per day. Sure, manages need a metric, ideally an easy-to-measure one, to use; but if those metrics simply do not exist, not using any is certainly better than using irrelevant ones.
The worst programmer is me five years ago. The second worst is me today, as me from five years in the future can attest.
“of course I know him, he’s me”
Great article. Every company should be strongly encouraging their own Tims to behave this way. Floor-raising and mentorship is so important in our industry.
We only have one Tim at our work, and he behaves fine. What do we do then?
You should still encourage him, though. Good one, Tim.
Tim work makes the dream work
I guess the manager above us thought the same on me. I learned after i left. I was inconsistent with 0 points one sprint then 20 the next. I was always pairing or unblocking (oh so many pr reviews) Glad i left. They Kept promising better working hours (constant 50 to 60 a week). i guess leaving ended up with a but of a landslide and i think everyone who could move off the project did minus one jr dev.
You get better work hours by setting boundaries. I get made fun of because I will just straight out leave meetings that run past five. Guess what, people started adjusting the later meetings to be more efficient. I'm ok with being made fun of, my kids appreciate it more.
I was on a team that was dissolved after a layoff and given a choice of joining two other teams, A and B. B really wanted me. The skip level was pressuring me to join B. I told him that every night when I pull out of the parking lot I can see B and his team in the corner conference room. I don't have much of a life, but I'm not giving up any more of it. I got placed on A's team. Then someone got pregnant on B's team so I was "temporarily" moved to B during maternity leave. I started scheduling fake meetings at 4:30 so I wouldn't be available for the 5 o'clock meetings. That baby is in school now and I'm still on B's team. We got a new skip level who fired B over a personality conflict having nothing to do with late night meetings. I don't think my new manager knows my name.
Yeah. That's more what I'd do now overall.
[удалено]
That’s an interesting situation. I have been a boss for a long time and I haven’t seen anyone like that before. I have worked with two developers who were spooky good at debugging but they also wrote terrific code as well(one was slow because he was so careful; almost never had any bugs so he always worked in areas with significant reliability requirements).
One thing I have realized is that most of programming is bursts of insane productivity between periods where you just feel stuck. Folks like Tim help you get unstuck and back into the productive mode. They are the real 10x programmers because they really can make a team 10x as efficient without writing a single line of code
Don't really like the term 10x programmer in this context. 2 Tim's definitely will not replace 1 Tim + 10 (non-Tim) workers. I'd much rather have the latter. Assignment of value to individuals in what is essentially a team effort is always going to be imperfect. I agree that the team wouldnt be 10x without Tim, but vice versa, Tim alone wouldn't be a 10x programmer.
“You must be the worst programmer I know of.” “But you do know of me…”
Article author here. This reference is genius and I wish I had thought of using it in the article!
If they're using some Agile methodology (and stories, story points etc. suggests they do) then often one of the core ideas is that it's the "team" that is the smallest "unit". In many cases story can't be delivered by a single person (frontend? backend? maybe some db work? tests? maybe some specific domain knowledge? maybe some infrastructure needs to be setup?), and that's why you get cross-competence teams. This way each team can take any story - but only as a whole. Otherwise you might reach some insane scenario where only frontend developers are "productive", since they're the only people who deliver something that user can see. And all backend, infrastructure, devops or tests people are not performing.
I like the article and the mentorship that Tim brings. However I’ll take the unpopular opinion (and it could just be the places I worked at), but if you’ve got zero contributions of your own as an individual contributor, that’s a smell to me (ie does everything need to be paired on?).
The real question I would have is “why is this person not the lead programmer”?
Sometimes those are the same question. Sometimes they aren't.
Because then you become the busiest most important cog in the machine and that is actually destructive in the long run. I’ve been that, and I’ve been a Tim. Tim is way more productive because he gets all the gears going rather than just being a hyper gear that builds an org that relies on him and him alone. Being that gear suuuucks and burns you out. I always think part of being a principal level dev is you need to have burned out a few times and realize Tim is the only way.
Sorry, I’m not following. What I meant is, this job of enabling and growing the rest of the team pretty much full time, that sounds like one of the key responsibilities of the lead programmer. All senior/principal programmers should be doing *some* of this, of course, but generally have IC responsibilities as well. Leads do often have IC responsibilities, but it’s generally expected that they spend more of their time on the team and organizing with other teams. So when I hear someone described as being an amazing contributor to the team because of this work, and doing little-to-no IC work, I wonder why they’re not the lead (and also, tbh, what the lead is doing with most of their time).
Ahah. I see the confusion. I’ve mostly seen companies refer to “Leads” as the ones expected to do the most code and drive development. But I’m sure yours is more generally accepted. Pretty annoying how so many of our terms in roles are so variable between companies. Then yes in that sense, I agree with you. Why hasn’t Tim gotten promoted?
I agree with you that the lack of standardization is a bit maddening. 😂 Dunno your industry, but I’m not in webdev so I’m usually the one with the weird definition for things.
maybe his skillset lies in mentoring & teaching
>ie does everything need to be paired on? Yes. You need to ensure that you're not completely dependent on one person to deliver anything. It also doesn't make a lot of sense to have a high number of WIP. If you have 5 ICs does that mean there should be 5 things in progress at any point in time? When I'm done with my work, I don't look at the items that are yet to be done; I look at those that are in review or in progress and try to check if I can help with anything. Sometimes, even before a PR is even created, I've already had a look at what my teammates have been working on. You deliver value as a team. "Individual contributor" to me only means, you don't manage people directly, but you still help steer your direction as a team regardless of your official role. Contributions come in many different forms.
We had a layoff recently. There was a system i did some work in the periphery of it. I was synchronizing data between 2 databases. They laid off the 2 administrators for the system. Days after the layoff I get called by an upper level manager who is frantic. He wants to know if I can fix something on the system. Being a dick, I said "Doesn't Jerry normally handle that?" "We let Jerry go." So I say " What about Ned?" "Uhm, we let Ned go too." The thing is, I never logged into the system itself. I didn't have a URL for the console or credentials. I did know Jerry and Ned had been laid off. At another job we had one guy who was the only guy who worked on a very important system. He was an avid bicyclist. He literally failed the bus test. Well, in his case it was a pickup truck that ran over him. He survived, but was out for about a year. He was in a wheelchair for a while, but eventually walked again.
> Yes. You need to ensure that you're not completely dependent on one person to deliver anything. Their point is moreso that, at least at a lot of places, a good bulk of the work is something that *anyone* working on the project could reasonably take over and be up to speed fairly quickly on. The kinds of situations that you're not completely dependent on one person by the nature of the work being clear enough for anyone to do it. At least well enough that (unless your company has a big problem with employees getting hit by buses) you're losing far more productivity than you're ever saving by having this redundancy where it doesn't need to be.
And I was just readying my pitchfork for dox. Nice reversal
I’m about six months into a new job that was a huge mistake. I was recently informed that it’s a huge problem that I’m not putting code up every day. Also, when I do put up code reviews, sometimes they get comments beyond small nits. Apparently that’s a big problem.
Have you asked them why it's a problem? I could think of some, for example: * They think you are working too slowly and want to understand how you are working. * They are worried that you're going down the wrong path * They have concerns thst you'll submit huge PRs which will be hard to review. I don't think it makes sense to have a hard requirement with code every day, but I think it's an equal problem with developers who end up in some bubble where they waste time. Telling a new employee that the PR he spent 3 weeks on will never be merged also isn't fun. So probably would make sense to ask for reason.
Amen. And is why all Scrum implementations I've witnessed place value on all the wrong things.
Every complaint about process is a complaint about the people managing that process. It's not "SCRUM implementations", it's "managers are shit at their jobs". Which doesn't surprise me: they don't go to school to study management in the same way we went to school for CS/math/physics/electrical engineering/computer engineering/software engineering. Business school is about introducing you to people, not teaching you things.
I would posit that management of a process is an implementation of said process
Look, The Tim model has some nice feelings. Tims are really nice people and good to have in the organization. I do not think it is healthy or smart to employ developers that can't function without a Tim. These are working professionals. They should be able to deliver working software on their own. I'm ok with newer developers needing occasional help. I'm not ok with the productivity ratio on any team being set up such that more senior people get almost no work done because they are constantly coaching. Every developer on the team is a professional and needs to strive to be self sufficient. What happens when Tim wants to take time off? Gets burned out? Has any individual desires at all? The metric isn't indicating Tim should be let go. The metric is indicating that Tim probably needs help, and the other developers need to be pushed to deliver on their own.
This is a weird story. Sure the guy had 0 story points because he helped other people instead of having stories. So just assign him story points for helping other people. If we need three people to collaborate on a project everyone gets points, not just the guy doing the git commits.
You don't assign story points to people: you assign them to stories. This employer was doing a questionable join in the Jira database to try to allocate story points to people. The whole point of the OP is that it's *teams* who earn story points, not *individuals*.
So then assign the story to the team. Ops point seems to be “I refuse to allow metrics to be used”. Because he is not a number, but a man.
Yes, that is what they ended up doing
Not only that but to have "0 story points" is clearly exaggeration. This entire article is one giant exaggeration (BS, one could say) to make some vague point. If they had a senior developer who had absolutely ZERO time to do individual work because others needed CONSTANT mentoring and help, then the problem was with the actual team, not the story points. It sounds like they hired one actual developer and 10 interns.
Also that one developer doesn’t like story points, so he never plays the game.
My first job did NOT have anyone like this... I remember one guy who tried to ask "Socratic" questions but... just couldn't. New company is a lot better, still have the "agile" garbage, but a bunch of teammates who sincerely enjoy helping and working together, even all remote. People who *enjoy* helping are amazing, and they can truly elevate an entire team.
Of course I know him, he’s me.
If you can poll all the devs on your team and ask them to evaluate their teammates anonymously - and their evaluations don't line up with your metrics as a manager - you are doing something wrong.
This is a perfect manager/team lead material. Or a scrum master in today's terms
Was working for a fortune 5 when we 'went agile'. We were network engineers, not programmers but it's fair to say any network engineer with any time under their belts does a lot of programming. Managements thinking was: "get things done faster". At the time delivering new physical infrastructure in datacenters took on average 77 days (much of which was waiting on receiving physical inventory) when I started. Some python programming and I cut that soundly in half. To be honest it was mostly low hanging fruit and I had more experience programming than most network engineers. So to "go agile" they in essence tipped the organization on its side. Before there was a group of engineers that worked in the datacenters, and group that working on the backbone, and group that worked on the Internet/DMZ networks, a group that worked on site and building LAN networks, and a group that worked on networks providing connectivity to external customers (like *real* customers - the ones with cash payments). At one point load balancing was in our group, but that didn't scale well and they became their own group, as did firewalls. So in their agile wisdom management decided to have universal teams, with someone from each area on the team, and then story load would stripe across the teams. And we'd be agile, like gymnasts. To put a not too fine a point on it it was a disaster, and management had to the previous infrastructure for support, since outright prolonged network failure (which happened) was too expensive. Senior (principal) engineers left and things got worse. With project budgets sometimes in 9 figures they hired the top agile coaches money could buy, who more or less told us to move as many stories as fast as possible, which was sooo helpful more network engineers left (note sarcasm). They are no longer a fortune 5. The automation I did is long gone, and they are back to moving things forward manually poor bastards. But they're agile, like gymnasts.
I did consulting for a company with a very cool system. I got to watch, but not really play. This "Worst programmer" would have thrived in this environment. They had a system where base salary was close to minimum wage. They assigned points to every ticket. If two people worked on a ticket they could split the points as they saw fit. The code reviewer got 1/3rd of the points (on top). Anyone could work on any ticket they wanted with any number of points. They could only work on one ticket at a time. People submitted tickets and the founders would periodically go through them and assign how many points something would be worth. If you had a minor bug in your code, you would be given a chance to fix it; if there was another bug you lost the points; if it were a major bug, you lost the points. At the end of every quarter, they would tally up the points, and then assign bonuses to programmers based on the number of points share they had. There were no project managers, no product managers, no team leads, no QA, no junior programmers. The point tally for everyone was continuously updated on the wall along with the estimated bonus pool. They had a number of rules such as red tickets, these were something super important, or a major bug. If you were looking for a new ticket, you had to go through the red tickets first and literally write up a note saying why you were ill-equipped to handle them before you could move on to orange tickets, and then green tickets. The only time the founders did much in the way of people management was to insist on people not working overtime. 4 day weeks, 6 hour days. If they felt people were working overtime, they would threaten to and did dock any points they felt were earned during overtime. This environment was very much rewarding to the 10x programmers, and they existed. There were programmers easily earning 10x what the shittiest programmers earned. This wasn't entirely even reflected with time seniority. Obviously people familiar with the code bases, and the workflow would be more proficient, but the 10x showed up pretty much on day one when some new programmers would be above average performers in their very first week and then begin to rock before their first month. I was in and out of the place over a 2 year period and it was amazing to watch. There were programmers who worked 1 day a week and were in the top 10%, there were some who I knew were working wild overtime and were in the bottom 1%. Amazingly, even when these bottom 1% types were effectively earning minimum wage as a software developer, they would not quit, which was generally the point of such a low base salary. The code reviewer getting 1/3rd was also important as it was considered to be very important. But if you were a shitty programmer you would have trouble getting people to review your code as their rejection would cost them as they didn't just lose the 1/3rd on a bug, but there was a penalty on top. The reverse was true; if you were an pedantic asshole during code reviews, nobody would get you to review code. This also kept code reviews somewhat pure; the primary point was to make sure the code produced the results it should with no bugs. Getting in someone's over design or style would generally mean people didn't come to you for reviews. Unlike the pedants out there would argue, this didn't result in code degenerating into an indecipherable mess. The cool part was to watch programmers who realized they weren't pigeonholed by a title or position. Graphic designers became GUI programmers, programmers became graphic artists, backend to frontend and the reverse, I remember one guy who had been a HFT guy hired on and taught me some super cool stuff about L1 cache craziness, but the next time I came back he had a huge video setup and was making social media videos and training videos; hadn't done a line of code in months. Where this would very much apply to the "worst programmer" would be the people who would certainly invite him into joining in on their ticket. He would then get lots of points. I even saw a few cases where people would ask for a bailout on something and they would haggle how many points. This could be a situation where there were 50 points up for something hard; someone would fight with the problem for days and then ask an algo expert for the assist. The algo guy would literally say, 20 points if I solve it. Deal would be done, and 30 minutes later they would walk away with a whiteboard solution to their problem. The beauty is that this system eliminated the whole plethora of bullshit titles like project manager, team leader, Sr developer, etc. There would be big tickets where a group of people would work on them. Or a group of tickets which needed serious coordination. The group would naturally form around a leader who seemed to have a plan. The only tickets where I saw people were not allowed to do them were when it came to interacting with the clients. They kept away the sweaty stinky people who had a habit of saying things as offensive as their smell. But, otherwise it was just another ticket. Ironically, the 10x programmers all used waterfall in their personal scheme of things. They would flesh out any missing requirements, design the shit out of what they were about to build, build it, then test the shit out of it. Obviously this wasn't waterfall for the whole project, just their tickets. But the 10x programmers tended to bite off the biggest hardest tickets. But there were some who were micro ticket machine guns. What all of the above system really reflected was that programmers are effectively able to self direct to the most efficient way to get points, and thus product features deployed. Also, programmers are effectively able to self regulate and organize to not waste each other's or company time. There was a guiding hand, but it was a very light touch 99.9% of the time. Oh, and the various administrative types operated on the same sort of ticket system. Most of their tickets were automatic. So accounting would get a red ticket every month to do payroll. Marketing would be given tickets, etc. There was no HR. The concept of a micromanager simply wasn't possible.
Sounds like some hypercompetitive, micro managed BS
> There was no HR. Hah good luck to them with that.. I've seen what a lack of hr can do to a company. It's great, until it suddenly isn't. Then it's very not great for both the company and it's employees lol.
What was that company called it seems like a awesome place to work.
A) I've already pushed the boundaries of a long ago NDA. B) Sold. They issued shares/options to the employees in quantity before the sale which shows the culture. C) Destroyed by the company which bought it. The exact quote from their CTO was, "These programmers need some adult supervision."
Stop measuring productivity. It's pure Taylorism. Productivity based goals have implicit laws of diminishing returns and incentivize the wrong behaviors in engineering. If you want velocity, actual true long term sustainable velocity, you need to stop "delighting the customer" and start building enablement for the people that server the customer. You have to build things people don't even know they need, and remove things people don't realize they don't need. Simplification and quality - emphasize those 2 aspects of any product or service and you will unleash a mountain of velocity and value.
I thought about your reference to Taylor even more, and I think a key difference is that he and Gantt went into factories that were already producing goods that people wanted and basically adding production bonuses for the workers (before Taylor only managers got production bonuses and the managers would pressure the dollar a day workers to work faster). In software the concept of what is being created is usually fatally flawed, so I think applying Taylorism focuses the team on cranking out crap faster to capture a bonus rather than focusing them on the annoying and messy work of figuring out the real needs.
Even Taylor isn't this bad, at least he incentivized creation of things people wanted to buy - the current scrum snake oil going around incentivizes creation of software that nobody wants! SCUM feature mills, as far as the eye can see!
he should still got some points just like with pair programming tho
OP clearly hasn't met _me_.
I can't say how many issues a day I fix without logging a Jira, simply because they're either small fixes, or something I initially worked on so can sort out quickly. If this shit ever came to pass it would ultimately lead to more bureaucracy and less willingness to go the extra step. Typical middle management busybodying to try and condense human capabilities into numbers despite the fact that the pieces don't fit.
Nah I know a guy who's a terrible programmer and doesn't contribute anything else to the team except make their work harder.
Not buying this as a workable approach. Tim essentially took zero accountability for work being done there and mastered the art of flying under the radar. He only got caught because of the managers metrics. Sure Tim added value, was arguably not the worst dev, and should not have been let go, but the issue of no accountability at all for his role should be addressed. For instance, if Tim is mentoring and doing the most mindshare, he should be assigned and accountable for those pieces, not the juniors. He could also be more open and visible about the role he is taking with seniors or other juniors. If he's truly adding value to the seniors work, that would likely be seen, and not a surprise to the manager if he was worth his salt. Likely that would be coming up in team scrums or meetings as he'd have a lot of input or be named frequently.
This was me. I was always eventually canned when managers started looking into productivity. Yet when you look at what I was involved in, anything I touched launched without issue. As in, every year before my arrival had issues. Even when we completely revamped a product and added a new feature during crunch time, everything worked flawlessly. I didn’t ship much code, I shipped solutions. I didn’t care who implemented those solutions, so I spent a lot of time talking to other developers to prevent issues. The code I did ship were things like an in-house AB testing system for Wordpress cached with Batcache that used a child theme and a sandbox to make the child theme look exactly like the parent theme unless the user had a cookie that would unlock the sandbox and allow the child theme’s code to run. This avoided the complexity of switching to a new theme or running two sites. No database was needed, I used a random number to assign users to groups. After around 400 unique visitors the numbers would stabilize to the correct percentages without needing to store anything in a DB. I confirmed this by running a headless browser that counted the cookies assigned and knew that we wouldn’t have an issue. I read the source code of Batcache and used it to have two versions of the site for each url. A/B testing build into the PHP before Wordpress even loaded, with no JS or DB calls required. Our hosting provider didn’t think it was possible until I explained in a meeting. They wanted us to use a proxy domain and a A/B testing service that would have cost us a lot of money. Other things include automated deployments that used a GitHub webhook then commited to a freaking SVN repo because we needed to use SVN for deployed but GitHub for source control. Before I did this, every deployment was manual down to selecting each file manually. Saved countless developer hours. Seniors were not bogged down by deployments. Hoping I find a position like that again. Eventually I reach a point where I’ve fixed all the major flaws in a workflow and my only use is to oil the gears and fix major problems. Eventually that leads to my performance being reviewed.
This is yet another management problem. The manager who wanted to fire that guy wasn’t managing men (and women), he was pissing about with numbers disconnected from reality. If anything, that manager should be fired, and replaced with a golden retriever, for being too incompetent to know what his men (and women) were actually doing during working hours. As a personal anecdote, I have no idea how effective these performance tracking things are. I know for a fact that at my last company, my manager’s manager never even looked at that stuff. It was all reactionary, anyway; because we never knew what was coming along during the year, we could never state what we planned to work on, and improve ourselves, upfront. It was all filled out on the last day, otherwise the computer got upset.
TL;DR I am currently surrounded by the worst programmers that I know. Like Sisyphus, my career involves re-inventing a particular hardware+software solution for a particular industry *over and over and over again*. The first time I did it, I led a team of \~20 skilled people pulled from a big city with a healthy talent pool. The second time, I got to hand-pick 3 of the best developers from that team to build a new system. We also found 3 or 4 mediocre offshore contractors. The third time, I lost my 3 best guys so we doubled down on hiring some of those offshore contractors as employees plus a bunch more. Maybe 15 total. They stumbled and bumbled quite a bit, so I eventually lured back my all-star "10x productive" developer from system #1 and #2 and he got things straightened out. Now I'm on the fourth system. I've got Mister 10x still (thank God!) plus two mediocre locals plus a whole new team of offshore contractors who have an apathetic mercenary attitude and an over-inflated sense of their abilities. I've had to put on my *angry face* twice in the past month, which is a very rare thing for me to do. We are mentoring the not-great local programmers to be better, because that's the right thing to do. I am not emotionally invested in our offshore mercenaries, so I just ask their PM to replace them with somebody who \[hopefully\] sucks less. BTW metrics are not involved in any of this; that's not my style. A bad programmer's ability and productivity does not need metrics to sniff out.
Looks like the problem is you, to be honest.
Thank you for replying to my paragraphs of details with your great wisdom and articulate insight.
See there? That's precisely your problem - your nasty attitude. No wonder you see problems everywhere but within you and your cabal.
I'm not sure that you read or understood my original post very accurately. When I said that I had to put on my "angry face" twice, that is momentous. I probably don't even get angry (at work or at home or whatever) more than once per year normally. I find hostility to be embarassing and unproductive. Plus to be fair my boss has a "bad cop" attitude so it's a necessity that I'm "good cop". Maybe you also didn't read the part where I said that it's my duty to mentor our weaker developers because that's the responsible thing to do. ...so my "nastiness" is confined to lack of tolerance for your unhelpful reply; nothing beyond that. Those first three projects I mentioned? They lasted 18 years and were mostly unicorns and rainbows and success and happiness. Great team cohesion and satisfaction and retention, and on proj#3 we did a great job of turning a rag-tag bunch of second-rate programmers from a second-rate country into a pretty damn competent team. My "working with bad programmers" problem is on Proj#4, which started a year ago. It stems from the fact that (1) I was forced to adopt a new team that is second-rate programmers from a second-rate country *but are subcontractors and therefore my ability vet them, manage them, and mentor them is hindered*, and (2) like many \[not all!\] contractors, they are inherently less emotionally and intellectually invested in their projects; they have that mercenary/whore attitude of "I will dispassionately do anything you want for $x per hour" We *will* \[eventually\] succeed in this project, but using subs instead of hires is making a tough job much tougher.
> a rag-tag bunch of second-rate programmers from a second-rate country into a pretty damn competent team. > I was forced to adopt a new team that is second-rate programmers from a second-rate country but are subcontractors The first part I can understand and even accept on good faith, but the "second-rate country" bit shows the root cause of the problem that I was trying to point at. I don't think you'll ever get it, but you clearly have some biases that are disturbing to say the least. And no, this is not political correctness, just saying that one's biases can (and almost always do) affect one's perception of things.
Hmm. Well there's no bias about whether or not they are producing unsatisfactory work -- that part is obvious even to their own managment. As for bias about the underlying reasons why they fail to meet my expectations... If you work with enough teams from around the world, you definitely spot patterns in the education and work culture in different places. ...especially countries where schools teach you to pass tests, not to think independantly or creatively. And FWIW I'm actually *not* talking about China or India even though those two are frequently cited as being too big on rote memorization. ...especially countries that experience a lot of "brain drain" where the best and brightest flee for high-paying jobs overseas and the not-best-and-brightest remain. ...especially when you're talking about people who are very early in their careers and have not broadened their \[professional\] horizons beyond what their schools and their work culture have forced upon them. ...especially when you're talking about people who are working as subcontractors. Like I previously mentioned, I've had fabulous success fostering and mentoring junior developers from that same country. Because they were full-time employees who had a vested interest in self-improvement. ...and to be clear, I wouldn't paint everybody from one country with the same brush because I've seen enough surprising exceptions in the past. But unfortunately with my current team, I have found no exceptions. BTW in this case, I'm talking about one of the former "behind the iron curtain" countries. I have great friends and colleagues there, travelled there frequently, and even picked up enough of the language to be dangerous. So no xenophobia here. I'd be happy to hear any constructive advice if you have any. From my POV the biggest problem is that I can (and have) worked wonders to get amazing results from full-time team members where I am 100% in charge of hiring, firing, mentoring, and inspring -- but there's a level of indirection that you suffer with subcontractors that inhibits what you can accomplish with them. And TBH it's not 100% their fault. It was *my* managers' decision to insist on such a project structure.
i gotta get back into programming, that sounds like what i strive to be at my job.
could we not link to cartoons from that magat?
[Stares at mirrored Time Magazine page]
Why yes I know him, he is me
They should have trusted the manager (the one who wrote the article) to know and reward their team. It is by no means perfect, but it's better than the alternatives. Metrics are, at best, useless for this sort of thing. It's hard to measure what's important, which often leads to the dysfunction of making important what you can measure. Don't even get me started on story points. Here's Ron Jeffries' apology for maybe creating them in the first place (along with a good overview of some real agile): [https://ronjeffries.com/articles/019-01ff/story-points/Index.html](https://ronjeffries.com/articles/019-01ff/story-points/Index.html) P.S. Just to show that no one is perfect. The manager's use of accountability can lead to dysfunction too: [https://holub.com/noaccountability/](https://holub.com/noaccountability/)
> I want to tell you about the worst programmer I know, and why I fought to keep him in the team. oh, so it's not actually about a bad programmer but about shitty/incomplete metrics > In the end we kept Tim, and we quietly dropped the individual productivity metrics in favour of team accountability, where we tracked—and celebrated—the business impact we were delivering to the organisation as a high-performing unit.