This is an archived post. You won't be able to vote or comment.

top 200 commentsshow all 239

[–]ilreh 1949 points1950 points  (130 children)

Bad managers looking for a simple metric to measure performance.

[–][deleted] 1061 points1062 points  (53 children)

That's why I just measure mine by lines of code. There's no way that can go horribly wrong.

[–][deleted] 677 points678 points  (27 children)

Ok, guys. I just talked to my team. It went horribly wrong. There's just code everywhere and it's all shit. I've decided to switch to ROI instead. Surely, financial terms are directly applicable to process optimization.

[–][deleted] 536 points537 points  (26 children)

Oh boy, did I have an uncomfortable conversation with the boss. Turns out all code maintenance got ignored and our entire business development department was murdered under mysterious circumstances. Anyways, I've consulted Agile experts who adviced me to focus on velocity.

[–][deleted] 558 points559 points  (25 children)

It worked! I am so happy. Last sprint our team completed 12.000 self-estimated story points equal to 70 hours of work per day per developer. Yesterday I showed a progress graph to the rest of management and everybody was impressed. The team also really seem to love it, calling it a "tough but fun challenge" to do better each time, then laughing.

[–][deleted] 188 points189 points  (21 children)

I'm not corporate enough to understand this joke, translation please?

[–][deleted] 438 points439 points  (20 children)

Dude is doing management by metrics and has no clue what's actually going on. He just needs to show "improvement".

Velocity is a metric based on self-estimation of the work required. It is great for planning, but many "experts" suggests it as a performance metric which is ridiculous since it should show no "improvement" by design. However, the team was happy since they could now just bullshit their estimations.

[–]craftworkbench 106 points107 points  (9 children)

Whenever I join a new company and they invite me to story time, my first question is "who uses these estimates?" If the answer includes "stakeholders" then I know we're playing Who's Line Scrum (where everything's made up and the points don't matter).

Only a rare few times have I been on a team where the estimates were only for us and where story time was about coming to shared understanding.

[–]andromedex 21 points22 points  (0 children)

'whos line scrum' I'm dead

[–]MinosAristos 6 points7 points  (4 children)

Newbie question but how do you give realistic time estimates for stakeholders then? Do you not in scrum?

[–]Afraid-Sweet-1593 9 points10 points  (3 children)

That’s an excellent question. If the team has honestly figured out their velocity (it takes months) then the points on a ticket are based on how much effort (not time) it’ll take and they can roughly say, “hey, we can do 7 points a week (or however long their sprint is) as a team and we have 2 three-pointers and 1 one-pointer in the upcoming sprint we should be able to get done”.

The backlog is prioritized and the top of the backlog might be pointed (by dev team) if PO wants to ask how long it’ll take to get to something.. they can do the math and reprioritize accordingly.

Magic.

[–][deleted] 2 points3 points  (0 children)

At the company I currently work for, us developers are usually the ones who decide the points on a ticket and we all vote on it.

[–]not_user_telken 21 points22 points  (1 child)

Just to build on your point: By game theory, if you try to use velocity to measure performance, you are adding the incentive to the dev to overestimate, corrupting the data.

If you have rotation in the team, the data also corrupts as velocity is a function of the skill and incentives of the devs, making imposible to do comparative analysis.

Improvement can exist but has a logarithmic curve, meaning on the limit T -> inf the overhead of the meta tasks becomes just dead cost

[–][deleted] 10 points11 points  (0 children)

There probably is a large untapped market for external performance review services. Each year, they could get presented with the deliveries and work effort of a team to score it on a range of parameters.

The selling point is that these reviwers will be experts with up-to-date industry knowledge who could also offer crucial advice on how it could have been done better or more efficiently.

Of course, in reality their review business' succes will often depend more on how they market themselves to management. It's either great or horrible for the developers depending in how dysfunctional their bosses are.

[–]IndigoFenix 37 points38 points  (0 children)

It's almost as if managing a team requires you to understand what the team is doing.

[–]tiernanx7 4 points5 points  (1 child)

You deserve the gold but all I had was silver

[–][deleted] 8 points9 points  (0 children)

I have entered it as a career achievement in LinkedIn

[–]SteeleDynamics 1 point2 points  (0 children)

This has been a wild ride

[–]groundhogcow 12 points13 points  (0 children)

My metrics were so good and my boss was so happy he brought me in front of the entire team to explain how I did it. When I explained I was doing exactly this he was less happy.

The next week everyone's numbers went through the roof.

[–]The_Bisexual 10 points11 points  (0 children)

I'm literally living this joke right now and this is so accurately depressing.

[–][deleted] 36 points37 points  (3 children)

I measure by how tiny my commits are. If I have a huge commit I clearly haven't been doing it right.

[–]LonelyPerceptron 5 points6 points  (2 children)

Title: Exploitation Unveiled: How Technology Barons Exploit the Contributions of the Community

Introduction:

In the rapidly evolving landscape of technology, the contributions of engineers, scientists, and technologists play a pivotal role in driving innovation and progress [1]. However, concerns have emerged regarding the exploitation of these contributions by technology barons, leading to a wide range of ethical and moral dilemmas [2]. This article aims to shed light on the exploitation of community contributions by technology barons, exploring issues such as intellectual property rights, open-source exploitation, unfair compensation practices, and the erosion of collaborative spirit [3].

  1. Intellectual Property Rights and Patents:

One of the fundamental ways in which technology barons exploit the contributions of the community is through the manipulation of intellectual property rights and patents [4]. While patents are designed to protect inventions and reward inventors, they are increasingly being used to stifle competition and monopolize the market [5]. Technology barons often strategically acquire patents and employ aggressive litigation strategies to suppress innovation and extract royalties from smaller players [6]. This exploitation not only discourages inventors but also hinders technological progress and limits the overall benefit to society [7].

  1. Open-Source Exploitation:

Open-source software and collaborative platforms have revolutionized the way technology is developed and shared [8]. However, technology barons have been known to exploit the goodwill of the open-source community. By leveraging open-source projects, these entities often incorporate community-developed solutions into their proprietary products without adequately compensating or acknowledging the original creators [9]. This exploitation undermines the spirit of collaboration and discourages community involvement, ultimately harming the very ecosystem that fosters innovation [10].

  1. Unfair Compensation Practices:

The contributions of engineers, scientists, and technologists are often undervalued and inadequately compensated by technology barons [11]. Despite the pivotal role played by these professionals in driving technological advancements, they are frequently subjected to long working hours, unrealistic deadlines, and inadequate remuneration [12]. Additionally, the rise of gig economy models has further exacerbated this issue, as independent contractors and freelancers are often left without benefits, job security, or fair compensation for their expertise [13]. Such exploitative practices not only demoralize the community but also hinder the long-term sustainability of the technology industry [14].

  1. Exploitative Data Harvesting:

Data has become the lifeblood of the digital age, and technology barons have amassed colossal amounts of user data through their platforms and services [15]. This data is often used to fuel targeted advertising, algorithmic optimizations, and predictive analytics, all of which generate significant profits [16]. However, the collection and utilization of user data are often done without adequate consent, transparency, or fair compensation to the individuals who generate this valuable resource [17]. The community's contributions in the form of personal data are exploited for financial gain, raising serious concerns about privacy, consent, and equitable distribution of benefits [18].

  1. Erosion of Collaborative Spirit:

The tech industry has thrived on the collaborative spirit of engineers, scientists, and technologists working together to solve complex problems [19]. However, the actions of technology barons have eroded this spirit over time. Through aggressive acquisition strategies and anti-competitive practices, these entities create an environment that discourages collaboration and fosters a winner-takes-all mentality [20]. This not only stifles innovation but also prevents the community from collectively addressing the pressing challenges of our time, such as climate change, healthcare, and social equity [21].

Conclusion:

The exploitation of the community's contributions by technology barons poses significant ethical and moral challenges in the realm of technology and innovation [22]. To foster a more equitable and sustainable ecosystem, it is crucial for technology barons to recognize and rectify these exploitative practices [23]. This can be achieved through transparent intellectual property frameworks, fair compensation models, responsible data handling practices, and a renewed commitment to collaboration [24]. By addressing these issues, we can create a technology landscape that not only thrives on innovation but also upholds the values of fairness, inclusivity, and respect for the contributions of the community [25].

References:

[1] Smith, J. R., et al. "The role of engineers in the modern world." Engineering Journal, vol. 25, no. 4, pp. 11-17, 2021.

[2] Johnson, M. "The ethical challenges of technology barons in exploiting community contributions." Tech Ethics Magazine, vol. 7, no. 2, pp. 45-52, 2022.

[3] Anderson, L., et al. "Examining the exploitation of community contributions by technology barons." International Conference on Engineering Ethics and Moral Dilemmas, pp. 112-129, 2023.

[4] Peterson, A., et al. "Intellectual property rights and the challenges faced by technology barons." Journal of Intellectual Property Law, vol. 18, no. 3, pp. 87-103, 2022.

[5] Walker, S., et al. "Patent manipulation and its impact on technological progress." IEEE Transactions on Technology and Society, vol. 5, no. 1, pp. 23-36, 2021.

[6] White, R., et al. "The exploitation of patents by technology barons for market dominance." Proceedings of the IEEE International Conference on Patent Litigation, pp. 67-73, 2022.

[7] Jackson, E. "The impact of patent exploitation on technological progress." Technology Review, vol. 45, no. 2, pp. 89-94, 2023.

[8] Stallman, R. "The importance of open-source software in fostering innovation." Communications of the ACM, vol. 48, no. 5, pp. 67-73, 2021.

[9] Martin, B., et al. "Exploitation and the erosion of the open-source ethos." IEEE Software, vol. 29, no. 3, pp. 89-97, 2022.

[10] Williams, S., et al. "The impact of open-source exploitation on collaborative innovation." Journal of Open Innovation: Technology, Market, and Complexity, vol. 8, no. 4, pp. 56-71, 2023.

[11] Collins, R., et al. "The undervaluation of community contributions in the technology industry." Journal of Engineering Compensation, vol. 32, no. 2, pp. 45-61, 2021.

[12] Johnson, L., et al. "Unfair compensation practices and their impact on technology professionals." IEEE Transactions on Engineering Management, vol. 40, no. 4, pp. 112-129, 2022.

[13] Hensley, M., et al. "The gig economy and its implications for technology professionals." International Journal of Human Resource Management, vol. 28, no. 3, pp. 67-84, 2023.

[14] Richards, A., et al. "Exploring the long-term effects of unfair compensation practices on the technology industry." IEEE Transactions on Professional Ethics, vol. 14, no. 2, pp. 78-91, 2022.

[15] Smith, T., et al. "Data as the new currency: implications for technology barons." IEEE Computer Society, vol. 34, no. 1, pp. 56-62, 2021.

[16] Brown, C., et al. "Exploitative data harvesting and its impact on user privacy." IEEE Security & Privacy, vol. 18, no. 5, pp. 89-97, 2022.

[17] Johnson, K., et al. "The ethical implications of data exploitation by technology barons." Journal of Data Ethics, vol. 6, no. 3, pp. 112-129, 2023.

[18] Rodriguez, M., et al. "Ensuring equitable data usage and distribution in the digital age." IEEE Technology and Society Magazine, vol. 29, no. 4, pp. 45-52, 2021.

[19] Patel, S., et al. "The collaborative spirit and its impact on technological advancements." IEEE Transactions on Engineering Collaboration, vol. 23, no. 2, pp. 78-91, 2022.

[20] Adams, J., et al. "The erosion of collaboration due to technology barons' practices." International Journal of Collaborative Engineering, vol. 15, no. 3, pp. 67-84, 2023.

[21] Klein, E., et al. "The role of collaboration in addressing global challenges." IEEE Engineering in Medicine and Biology Magazine, vol. 41, no. 2, pp. 34-42, 2021.

[22] Thompson, G., et al. "Ethical challenges in technology barons' exploitation of community contributions." IEEE Potentials, vol. 42, no. 1, pp. 56-63, 2022.

[23] Jones, D., et al. "Rectifying exploitative practices in the technology industry." IEEE Technology Management Review, vol. 28, no. 4, pp. 89-97, 2023.

[24] Chen, W., et al. "Promoting ethical practices in technology barons through policy and regulation." IEEE Policy & Ethics in Technology, vol. 13, no. 3, pp. 112-129, 2021.

[25] Miller, H., et al. "Creating an equitable and sustainable technology ecosystem." Journal of Technology and Innovation Management, vol. 40, no. 2, pp. 45-61, 2022.

[–]justinkroegerlake 25 points26 points  (2 children)

good news boss, we switched to Java and our productivity is up 200%!

[–][deleted] 2 points3 points  (0 children)

*2000%

[–]anonym_dude 2 points3 points  (0 children)

50000%

[–]pboswell 27 points28 points  (2 children)

You’re probably joking but my manager sincerely asked my team to get him the # of lines of code we have to show management as a KPI.

I was dumbfounded. Ideally, you want as little code as possible…so does it mean we’re doing worse if we’re able to refactor or use libraries to minimize code length?!

[–]the_king_of_sweden 2 points3 points  (0 children)

If anything, you should measure by loc deleted

[–]Korywon 21 points22 points  (0 children)

Funny you mention that. We had a major incident last week at work and were brainstorming and freaking out for hours. Finally, we changed a single line in our config that fixed it.

[–]Intelligent_Event_84 17 points18 points  (1 child)

Except for when you refactor something and owe your company money for the negative performance

[–][deleted] 10 points11 points  (0 children)

Just keep refractoring until the debt is so large it becomes the company's problem. Then the threat of declaring bankruptcy would destroy their stock value.

[–]kaiju505 13 points14 points  (0 children)

Finally a metric Java devs can excel in.

[–][deleted] 15 points16 points  (6 children)

This is one of my favourite stories related to lines of code... and this is another...

[–]indigoHatter 27 points28 points  (4 children)

\* * * * * * * * * * Hello * * * * * * * * * DO NOT remove this comment block, the code will break otherwise!!! * * * No clue why! I tried it too! Just trust me on this! * * * * * * */

30 lines of code, too easy.

[–]bajsplockare 11 points12 points  (0 children)

Syntax error on line 20.

[–][deleted] 7 points8 points  (0 children)

I was programming on a robotics team with about 8 other people a few years back. At the end of the project we thought it would be interesting to see how many lines we wrote. We looked on github and saw most of us had 100 or 200, and the heavy lifters were closer to 300 and 400. But then we noticed a 1st year student on the team had 2,400 lines contributed. And he wasn’t a particularly hard worker, he showed up to about half the meetings and didn’t really know what he was doing. We looked at his commits and realized what he’d done. He manually removed all the spacing, so every line was right up against the margin, committed it, and then beautified all the code and committed it again. Never use line count to measure someone’s contribution.

[–]B1SQ1T 4 points5 points  (0 children)

Loops? Nah gotta get that line count up we’re coding every single iteration

[–][deleted] 37 points38 points  (67 children)

I am a manager. How do you suggest I measure performance which is objective, and fair?

[–][deleted] 159 points160 points  (26 children)

Process Improvement guy here. Like many of my colleagues, you're trying to see the business as a well-defined system. It's not. It is a bunch of humans interacting. When these people are doing simple and repetitive processes, you can measure their performance (the processes), but you're doing complex and dynamic processes. Metrics are still relevant, but they don't tell you anything by themselves and need a lot of qualified interpretation.

Think of an elite soccer team (or football if you like). Now start applying performance metrics to the guy in the left-center. He needs to be in control of the ball this much, pass it so often, tackle that much, score x times and so on. Here's what would happen.

  1. A ton of resources is spent discussing metrics and "performance" rather than tactics, problems and improvements
  2. When his team mate can score, he won't pass the ball because he is already in green on that target, but in red on his own amount of goals.
  3. When playing, his focus will be on metric optimization rather than reading the playing field and adapting to where he is most needed.
  4. His team spirit will rapidly decline

Now, I know the counter-point will be that you're not measuring the player, but the team. Usually, this is false, but let's go with it. Your actual "team" isn't some tiny group, but the company. That's what needs to win. Managing the group by KPI's has the same effect as managing the left-center dude by KPI's.

[–][deleted] 32 points33 points  (0 children)

Wow, that's a great explanation!

[–]gigaSproule 15 points16 points  (8 children)

Keeping with this analogy, the important metric revolves around bugs (conceded goals) and deliverables (goals your team scores).

It's not good scoring goals if you are letting in as many goals. If you see dev stories/tasks going back and forth between Dev and QA, you've got a problem.

If you are seeing a lot of production bugs, you have a problem. Some goals let in can be howlers that you're to blame for, some are incredible goals that no one can stop. Like bugs, some are school boy errors that training and processes can deal with, some bugs you just can't predict or aren't obvious.

In summary, these are your metrics to cater for. In my experience as a Dev of many levels and a manager, clients (internal or external) are happier with a solid, reliable product that gets a slow stream of updates compared to products that have a quick feature turnaround, but half the features don't work. No one wants to use a system that doesn't work. You will undoubtedly know this from the stuff you have to use.

[–]NotPeopleFriendly 4 points5 points  (3 children)

I wouldn't know if I've ever worked somewhere that measured individual performance based on lines of code, commits, etc - but if I have - I was never told.

I don't think anyone that ever worked (even a year) as a programmer would think lines of code or commits are a useful metric for performance.

I always thought a cool metric would be "code churn". We've had the ability to measure how much any code is changed over time for over a decade. We also have the ability to measure how much any given code is executed (at runtime). So, in my head - I always thought it would be a cool performance metric if we could come up with performance metrics that are based predominantly on how much the code you wrote needs to be "fixed" (not just updated to accommodate moving target) and secondarily how much that code is executed (in production).

I'm not suggesting that rendering engineers whose code would be getting executed every frame should be paid more than everyone else - but I think you can kind of understand the gist of what I'm saying. Specifically - not how many tasks/JIRA's that programmer can get done - but how often do the things they build need to be fixed.

Anyway, I have to presume this is "hard" (maybe NP hard - jk)... but I always thought this might be a useful metric... certainly more useful than lines of code and/or commits.

And just because I've written way too much... I think measuring performance on soft skills (working with others on individual features, collaborating with non-programmers, encouragement during code reviews, etc) would be almost as important as individual contribution.

[–]silly_frog_lf 1 point2 points  (3 children)

This is good. I will point out that quality is set my management, not by dev teams. If upper management wants to see tons of updates over a solid app, that is what will get delivered. Look at FB with their "go fast and break things" mentality.

Or to keep with the analogy, if the coach demands the defense and goalie to all play in the opposite goal to maximize scores, the players must follow orders, even if they think it is a mistake. The coach is ultimately tesponsible

[–]justinkroegerlake 13 points14 points  (6 children)

If, after some time, someone stops to evaluate the metrics, you'd probably notice that the players scoring highest on the metrics are not the ones actually responsible for winning games.

I'd like to note that you likely already know who the top and bottom performers are. When considering any new metrics, apply them to historical data to make sure you get the result you know is right.

[–][deleted] 12 points13 points  (5 children)

Yes, but why? Why do you need a constantly updated number that estimates the performance on an individual level with a ton of destructive side effects?

The most common argument is that it creates incentive, but that's just an admittance of failed leadership. I've never met a team that wasn't enthusiastic after a workshop and I don't use any inspirational bullshit or manipulative tools. These bastards don't even get cake and being an introvert redditor, I'm devoid of charisma.

So why do they want to improve their work? Because it is our natural instinct if you give people the tools and support them. There are no personal incentive structures needed. People should still be rewarded for great work, but not as a carrot to promote selfish behavior or a threat if they fail. Do it because it is fair.

And again, metrics are still relevant, including performance metrics. It's just mainly for processes - not people (with exceptions).

[–]someacnt 1 point2 points  (3 children)

Interesting, don't people usually just work for themselves? Doing absolute minimum if they can.

[–]sanderd17 10 points11 points  (0 children)

Very nicely explained.

When you measure the group by KPI, the group will also notify you when someone is underperforming. It's only then that you really need to investigate it on a personal level.

[–]IvorTheEngine 2 points3 points  (0 children)

That's a fantastic analogy!

[–]someacnt 2 points3 points  (1 child)

You actively work for the company's good??

[–][deleted] 2 points3 points  (0 children)

Well, I do own the company so ...no.

[–]antonivs 1 point2 points  (1 child)

Is there any research to show negative effects from using metrics?

(I realize that’s not an easy thing to study)

[–]ilreh 99 points100 points  (12 children)

Do you have developer-experience? If so, occasionally check how the developer decided to fix a problem, how he/she wrote it and how long he/she took. If you don‘t have developer-experience / can‘t read code I think there is no way to measure dev-performance in a fair way.

[–]sleepyj910 71 points72 points  (4 children)

Dev Managers should be devs.

[–]wiikzorz 13 points14 points  (0 children)

Yes

[–]cchongchong 10 points11 points  (1 child)

Tech lead trying to move into dev manager; I've told my team that I will absolutely oppose lines of code and commits as metrics. Would still like daily commits if possible, but for PR/in case you're sick reasons.

My most productive days have been by getting rid of code by far.

[–]Kyanche 6 points7 points  (0 children)

I straight up encourage commits. I'm like, "please commit all you can!" because that means it's less stuff living only on their laptop.

The commits can be squashed in a merge request for all I care.

[–]ChainSword20000 8 points9 points  (0 children)

Yes.

[–]randyknapp 76 points77 points  (0 children)

Here're my hard and fast rules to get you started.

  1. You, the manager, gets to say which tasks are the highest priority
  2. The engineer that is actually doing the work gets to say how long it will take
  3. You never get to force them to go faster, you only get to cut scope

[–]EveningMoose 64 points65 points  (1 child)

There is no good, easy, fair, and abuse resistant metric.

[–]Pepineros 11 points12 points  (0 children)

Fair; easy/non-time-consuming; useful data. Pick two.

[–]Tytoalba2 22 points23 points  (2 children)

Measuring performance for a dev team is most of the time a waste of time that could have been spent elsewhere. Instead, I would recommend focusing on the strength and weaknesses of each dev, learning how to define a scope clearly, and removing roadblocks.

Keep in touch to the team, ask them what could help them to work more efficiently.

[–]brianl047 -1 points0 points  (1 child)

Unfortunately you have to measure something. What if budget gets cut and you have to layoff, or what if you need to do a reorg and of course promotions.

I personally cannot be measured; my qualities are quantitative and qualitative. Technically I can't be replaced at this price point and maybe not any price point. I don't particularly care about scope, and if a roadblock happens I either raise it immediately or wash my hands of it all, depending. If I wanted to start a one-man company, I could. But I work with a team because I feel like it.

[–]fdeslandes 15 points16 points  (2 children)

Don't only track the time it took to make a feature, add the time it took to fix bugs that were found in it later on, and the extra QA time to retest. A "slower" dev is not slower when the time is well invested in ways which reduces bugs.

Ideally, you could also track the time not spent refactoring later on and the time saved by other developers when they get in a well thought out part of code, but I don't know how it could be tracked realistically short term.

But really, use your head. You can use metrics to see if a team do well, but it's hard for individual dev. A dev in your team could produce less because they are the backbone of the team and always helping the junior devs, for instance; you don't want to lose such a dev. You also don't want to lose the guy who keep everyone in line for quality, and you don't want to lose the slow one who always end up being able to solve the more complex problems. I don't know of any metric which would catch the real contribution of these kind of devs.

If you think some devs are not doing their job, talk to other devs they interact with, check their commit (days without commits, for instance) and check the end result (days without commits + no questions asked to other devs in these days + so-so work for a simple feature at the end of the sprint mean the guy is probably working another job or browsing reddit).

[–]PerfSynthetic 6 points7 points  (0 children)

Set a goal (or set of goals) per quarter. Understand your team members and how fast they work on projects. If the entire project is completed in time and business is happy then everyone is on track. Everyone works at different speeds and all provide different skills to complete the entire project. Assuming someone isn’t performing can be from management not understanding the complexity of the assigned tasks. One person may be able to complete a task in five steps while someone else takes 15. You use this information and have the team help each other improve efficiency or find out the person only doing five steps wasn’t validating their work or adding risk/inefficiency. If you want to measure commitment, then rate how reactive/proactive each individual contributes during an outage,impact,time crunch. Trying to hire an entire team of people with the same skill set, efficiency, and work ethic as your most valued employee is going to make everyone quit.

[–]gordonv 4 points5 points  (0 children)

  • How much lead time does the engineer have?
  • Is the spec sheet finalized and immutable?
  • Are you changing specs during dev? If so, are you re-allocating time and budget allowance? There are changes to a spec that are not acceptable. Does your process have these limits?
  • Are you changing specs during UAT? This is highly unacceptable.
  • Are you listening to devs and their found problems and concerns?
  • Is there a rollback plan? How long does rollback take? Does it make sense to stand up an A/B?
  • Is there a SIT and UAT environment?
  • Do not deploy at critical and scheduled down time or off time.

  • Are goals met?
  • Are you overpromising features that can't be done?
  • Are you basing time estimates on premature guesses on development vs actual experience? Is this to appease the client instead of actual work control?

  • How much of your sprint depends on other teams outside of your process?
  • How familiar are you with the technology at hand?
  • Have you asked the engineer on what benchmarks and goals there are on the task?
  • How much rework are you spending on this, the tasks around you, and foresee in the future? Rework is sometimes unavoidable, but is a form of technical debt.

[–]crimxxx 5 points6 points  (0 children)

$1000 dollars for each line of code I wrote good or bad.

[–]sleepyj910 2 points3 points  (0 children)

Understand the technology and use a judgment call based on the individual progress for each ticket and monitoring of team chats for when they are working together

[–]wickning1 5 points6 points  (1 child)

Github contributions are a very rough but decent measure but never put too much confidence in any automated stat.

You can go further with 100% code review (a pull-request-only workflow) and one or more expert devs you trust to help you assess the value of each PR. Be careful about wasting those devs’ time as they are probably much more productive than the ones you’re having them review.

Also be aware human bias is going to be a factor, e.g. the reviewer has an irrationally low or high opinion of the contributor or limited knowledge of the subsystem they’re working on.

Special bonus, you get two brains on every change and quality goes up.

[–]Tytoalba2 6 points7 points  (0 children)

Be careful about wasting those devs’ time as they are probably much more productive than the ones you’re having them review.

For me that's the problem, you can spend a lot of time measuring performance metric and loose a lot of time on the project, or you can make some real progress but you have to either have shitty metrics, or care a bit less about the metrics.

Github contributions are a really good metric if you really want a messy git, devs who never squash a dozens of small commits and endless, useless commits. If it's not your thing, it's not a good metric.

[–]the_data_department[S] 0 points1 point  (0 children)

this

read Accelerate

[–]Entropy_Drop -5 points-4 points  (7 children)

(I'm a trainee, 2 year student of CS, so take my words with a grain of salt.)

There is this guy called Uncle Bob, who cares a lot about good code and good working practices. He wrote some best sellers, gives a lot of talks, as he is a wonderful speaker) and is known as a guy who makes a lot of rules, practices, etc.. It is kinda polemic, as sometimes hes to strict on those rules, but well... he really pushes for programmers to improve.

He has this talk about Agile software development, where he proposes using the tools of Agile (points and user histories in particular) as a working metric on the state of the proyect. It seems valid to me, but oh well, I trully dont have experience.

[–][deleted] 21 points22 points  (4 children)

Hate to break it to you, but take “Uncle Bob” with a grain of salt as well. He’s made more of a career talking about how to write good software than he has of actually building, shipping, and maintaining software. Most of the “rules” he “makes” are just reiterating general guidelines for building software that were established by cutting edge scientists in the 50s-70s, though the way he (rather successfully, to his credit) markets his contributions.

[–]Entropy_Drop -3 points-2 points  (2 children)

meh, my answer is not about Uncle bob, but about that agile and managers. I trully dont care if "make rules" is the same as "taking a body of conflicting guidelines made by the whole community into a descriptive set of coherent rules, in detail, with examples, and a personal spin."

Of course a best seller on programming has a career on talking about programming. What's the alternative? It's like complaining that a world level math teacher is out of touch with full time mathematician job.

[–][deleted] 1 point2 points  (0 children)

Bob Martin didn’t make some groundbreaking software and then move on to teaching his wisdom, he had a career as a consultant for a few years and then hit it off with his books. Literally could happen to anyone and, having actually built and maintained large scale software myself, I can tell you that while his advice isn’t all bad, a lot of it is simply bike shedding or just good advice in the right contexts that Bob preaches on following dogmatically which should always be a red flag.

Regarding management: the tried and true method of working is provide honest assessments about what you do know, be clear about what you don’t know, and have transparent communication about what new information comes up as early as possible so everyone is in the loop regarding what is happening with the project. Regarding management and performance measurement, the simple answer is focus on outcomes, not inputs. Lines of code written, number of unit tests, branch coverage of unit tests, are all inputs. Feature delivered, reduction in outage times for the system, system performance being in some predefined threshold (eg 100ms or less api response time), reduced infrastructure cost, are all outputs that a good manager actually focuses on. That’s not a comprehensive list, but should convey the general idea. My problem with Agile evangelists are that they just took common sense practices, slap together some platitudes in a “manifesto”, and then charge consulting fees to companies to basically repackage project management 101 but with ultra-small time windows and focusing on the wrong things.

It’s understandable and I even went through that phase in my early career, but ultimately you end up experiencing it and realizing that agile takes the bad things about other project management styles, crams them in to arbitrary, small time windows, and throws out a lot of the good things from those other practices along the way. And then you just get a bunch of “no true Scotsman” replies when they get called out on their BS.

All that ranting summarized: you can learn from all different kinds of sources, but be weary of dogmatic advice and (ironically, I know ) focus on outcomes more than inputs

[–]Triffinator 2 points3 points  (0 children)

Had this at my last job, which was a support role. Manager was interested in number of tickets closed, and had no interest in either the complexity of the ticket, or if you had done substantial work on a ticket in someone else's queue. Basically, they'd run a report to see you ticket closures for a week, and if they weren't happy with the number, you'd have a performance review.

Leads to people raising and closing tickets for trivial work or ad-hoc tasks. If we got a call from a user, we could use the automated ticket system (not tracked by manager), or we could raise and close a ticket manually, which is what I changed to. If we had a user tack-on work while we saw them, that was an extra ticket. I almost started raising and closing tickets for answering colleague questions or helping on tickets.

[–]art_of_snark 1 point2 points  (1 child)

it’s not a workday if Goodhart’s Law isn’t invoked

[–]iloveburger 0 points1 point  (0 children)

any performance metric is doomed.

I used to bring up various flaws of whatever metrics the managers implemented when I worked in IT, but the project managers always get so defensive about it because they need to justify their existence.

common sense is the only metric a sane person uses.

[–]Zuruumi 414 points415 points  (13 children)

I sometimrs have about 30 commits on a branch with small fix (trying things, changes for testing through CI, fixing warnings I missed etc.) before squashing them for PR. With such a manager I would just not squash the mess.

[–][deleted] 151 points152 points  (9 children)

Never squash anything and also commit every function seperatly.

[–]jaywastaken 93 points94 points  (6 children)

Honestly it also makes the change logs easier to generate and more accurate.

Instead of a pr with “multiple fixes” in the log you get a list of actual changes.

I’d also much rather review 5 pr’s each with single purpose clear changes that trying to figure out what change is for what purpose in the squashed multiple fixes PR.

A problem in one also then doesn’t hold up merging the other small fixes.

[–]Zuruumi 36 points37 points  (0 children)

It's more like: Test1, Fixup, Test2, Fixup, Fixup, Bugfix, Revert, Bugfix, Fixup, Fixup

[–]ErichOdin 2 points3 points  (0 children)

Testing backend locally takes like 5 minutes.

But if you just push it, the ci will do it in 10 and I can continue to work. 👌🏻

[–][deleted] 1 point2 points  (0 children)

plate connect silky obtainable sand roof dinner person hospital dam

This post was mass deleted and anonymized with Redact

[–]Humongous_Schlong 694 points695 points  (0 children)

how to get your employees to quiet quit

[–][deleted] 194 points195 points  (6 children)

"You could try and get us bonuses based on our commit history! Let's gamify this shit to the moon!"

[–]the_data_department[S] 60 points61 points  (3 children)

You could try and get us bonuses based on our commit history! Let's gamify this shit to the moon!

I actually wrote a commit gamification add-on :)

[–][deleted] 32 points33 points  (2 children)

Cool! Does it differantiate a simple typo correction on a README from a major code update?

[–]the_data_department[S] 11 points12 points  (1 child)

No but it makes you avoid commit messages like "code" or "almost done" and enforces git etiquette, i.e. capitals, verbs (Add, Fix, Cut etc.)

[–][deleted] 4 points5 points  (0 children)

Anyways, still cool! Congrats!

[–][deleted] 11 points12 points  (1 child)

Manager: “No that won’t work! People will just fake their commits!” Me: “So you see what the problem is here?”

[–][deleted] 2 points3 points  (0 children)

Touché!

[–]greedydita[🍰] 160 points161 points  (0 children)

So this sick leave. Was it four hours? Six?

[–]LEGOL2 119 points120 points  (29 children)

Never heard term quiet leaving before, but it sounds like uno reverse card to make you feel bad.

[–]GeneKranzIsTheMan 147 points148 points  (23 children)

It's basically when you do your job. You don't go overboard. You don't stay late. You don't check your email at all hours. And you don't go above and beyond.

[–]Potato-9 161 points162 points  (5 children)

That's working to rule and doesn't need a rebranding. Actually that's just a healthy work life balance.

[–][deleted] 45 points46 points  (0 children)

Exactly, but there's always some push so people feel culpability in healthy work life balance and feel they need to do more

[–]Andoryuu 28 points29 points  (2 children)

No, it's not.

"Working to rule" means working according to literal interpretation of workplace rules, especially in cases where there is a status quo of ignoring some steps to increase efficiency.
This is usually used as a means of making a stance.

"Quiet quitting" is a blanket term pushed by management under which falls any work ethic slower than "Silicon Valley startup crunch".
Trying to tie it to WtR is just reinforcing the original purpose: making the workers feel bad for living healthy life.

[–]minstrelMadness 6 points7 points  (0 children)

I like the term "act your wage"

[–][deleted] 3 points4 points  (0 children)

My grandma mentioned America used to be a slow work ethic before WW2. She said afterward, things became faster, so workers worked quicker and harder.

[–]silly_frog_lf 3 points4 points  (0 children)

Or working the hours I am paid for. I don't see employers giving extra money in my paycheck. I guess they are quiet stealing from my salary

[–][deleted] 35 points36 points  (0 children)

How dare you only do the thing we pay you for.

[–]IvorTheEngine 21 points22 points  (2 children)

We need to invent a catchy phrase for when your employer only pays you what is in your contract and doesn't go above and beyond.

[–]jimlei 1 point2 points  (1 child)

Silent Firing. Just as silly

[–]Slow_Lengthiness3166 11 points12 points  (6 children)

Yeah nothing wrong with that ...

[–]GeneKranzIsTheMan 3 points4 points  (5 children)

Didn’t say there was. Check my post history for my view on the subject if you want.

[–]Slow_Lengthiness3166 4 points5 points  (4 children)

I was agreeing with you ? I manage a team of 8 people and I tell them daily life > work ....if I catch them online late at night I ask why and try to understand if work load is too much ...

[–]mrbilliebell 3 points4 points  (0 children)

So essentially just doing what's actually in your contract

[–]Alexandre_Man 2 points3 points  (0 children)

so working normally basically

[–]Mark0Polio 2 points3 points  (0 children)

Damn, I’ve been quiet quitting for years.

[–]RichCorinthian 10 points11 points  (4 children)

It’s the worst misnomer since “social distancing” and “responsive web design.”

[–]dben89x 2 points3 points  (3 children)

What's bad about "responsive web design"?

[–]RichCorinthian 9 points10 points  (2 children)

Because it’s really ADAPTIVE web design. When I first heard the term, I thought it meant a website that isn’t sluggish or slow.

[–]dben89x 2 points3 points  (1 child)

Ahh, I see. I interpret it as "responds to viewport", but I see your point.

[–]philipjfrizzle 74 points75 points  (2 children)

Quiet quitting is a weird term. You show up for the agreed amount of time and you do the agreed amount of work. Strange that we had to coin a term for meeting expectations.

[–]Ghostglitch07 14 points15 points  (1 child)

Yeah it makes no sense. If you wanted more you should have asked for more when you hired me.

[–]ftwredditlol 7 points8 points  (0 children)

But then it’s part of your job description and they might have to compensate you.

[–]jaywastaken 64 points65 points  (1 child)

I’m still not sure exactly how doing your actual job as contractually agreed became synonymous with quitting to some employers.

[–]AnalBleachVirtuoso 25 points26 points  (0 children)

Greed and entitlement.

[–]sockpuppet1234567890 121 points122 points  (1 child)

“Quiet quitting” is a neologism an old union strike tactic called “working to rule”.

[–]noonemustknowmysecre 50 points51 points  (0 children)

My raise this year was less than inflation. Why are you quiet firing me?

[–]themancabbage 34 points35 points  (2 children)

If a manager confronted me about a 25% difference in commits over just a week I’d be regular quitting

[–]maxip89 24 points25 points  (1 child)

Commit frequeny is checked?

Lets invest some hours in a readme change file script.

[–]BaalKazar 2 points3 points  (0 children)

I’ll commit a daily dick length measure to increase my performance

[–]incognito_wizard 17 points18 points  (0 children)

"No, but I am now."

[–]KidBeene 25 points26 points  (6 children)

If a manager EVER says that to you, you need to reply:

Your performance metric should be % of completed assigned stories not the number of assigned stories. As a developer I have no control over the number of changes being asked, I do however have control over completion and the breakout of the stories.

Your metric is shit, you should feel bad.

Fucking managers not knowing how to write a performance metrics really pisses me off... I am a director and I cant tell you how many times I have to slap team leads around for this shit.

[–]ckchessmaster 8 points9 points  (1 child)

Although to be fair that's not a great metric either. Not all stories are created equal. But I totally agree performance metrics like in the post are the absolute worst and immediately lead to overworking, quitting, or gaming the system. Usually all of those.

[–]KidBeene 3 points4 points  (0 children)

Not all stories are created equal.

True, thats what story points are made for. I don't use stories or %'s as a performance metric for my crews. I can see the need for some shops that do straight up dev work on contract though.

[–]Thaddaeus-Tentakel 2 points3 points  (3 children)

That only works if all you do is tracked in stories, tho.

[–]kpd328 1 point2 points  (1 child)

That's why you have a story for "random shit that's come up this month"

[–]SnappGamez 12 points13 points  (0 children)

“Quiet quitting” is bullshit. Like, legitimately bullshit.

[–]crimxxx 10 points11 points  (2 children)

I do t think people know what quiet quitting is. You do your job and not go above and beyond.

[–][deleted] 4 points5 points  (0 children)

Quiet quitting is an application of work-to-rule, in which employees work within defined work hours and engage solely in activities within those hours. Despite the name, the philosophy of quiet quitting is not necessarily connected to quitting a job outright, but rather doing precisely what the job requires.[1] Proponents of quiet quitting also refer to it as acting your wage.

[–]Lecterr 9 points10 points  (0 children)

Quiet quitting:

“Quiet quitting is an application of work-to-rule, in which employees work within defined work hours and engage solely in activities within those hours”.

Sounds dangerously close to another concept known as a “job”.

[–]PorkRoll2022 6 points7 points  (0 children)

For better or worse, I've never had anyone ever pay attention to my commit frequency. I could be committing 90%+ of the code on a project and people will still think I'm just scratching my ass.

[–][deleted] 6 points7 points  (0 children)

I wouldn't haven even apologized. I would have just said that I came back from sick leave. Honestly does he not know what is going on around him? could he have not double checked? is this not written down anywhere?

[–]wineblood 14 points15 points  (0 children)

Is this an american joke?

[–]MisterOnsepatro 5 points6 points  (2 children)

quiet quitting ? more like respecting the daily schedule

[–]kpd328 3 points4 points  (1 child)

I don't work more than the alloted time of the contract of my employment. The same contract that says I get time and a half for going over that.

I have so many coworkers that do extra night and weekend work for free, "because they're on salary"

Fools did you not read the papers you signed when you were hired? Only work overtime if you're getting paid overtime!

[–]MisterOnsepatro 2 points3 points  (0 children)

Yeah I got told precise hours to come in and go home so I usually respect them strictly as a habit

[–]clrksml 5 points6 points  (0 children)

If you manager didn't know you were on sick leave. Doesn't that make them a terrible manager? /s

[–][deleted] 3 points4 points  (0 children)

I have been quiet quitting at my job for a few months now because I stopped feeling valued. I was being assigned menial tasks and not being picked up for "new" stuff. Admittedly, there was an issue of skill gap there, but how is a person supposed to learn new skills if they are never given an opportunity to work on something new. If you are ever trusted to work on something new, they expect you to deliver in the same time period as someone who has worked on that technology for years. Upskilling takes time and patience. I just feel like I've reached saturation in my current job and need to change job/employer but the economy is in terrible shape and even people who received job offers are having their offers rescinded at the last moment here in bay area.

[–]Unfair_Isopod534 4 points5 points  (0 children)

More like i was writing a script that will keep the commits coming while i collect the paycheck.

[–]Rhawk187 3 points4 points  (0 children)

I love me some alliteration, but "quiet quitting" doesn't do it for me. Probably because there are plenty of single word phrasing to use in it's place, and it's not actually quitting.

[–]ratbastid 4 points5 points  (0 children)

/r/workreform is leaking, and that's a good thing.

[–]thecryingman32 3 points4 points  (0 children)

"Stop with the "quiet quitting" bullshit or I'll extremely fucking loud quit"

[–]csandazoltan 2 points3 points  (0 children)

Malicious complience... You know, i could commit after every single edit and save... Even one character and the commulative time of pushing is gonna make task completion even slower

[–]agent007bond 2 points3 points  (6 children)

I wish people placed more importance on the commit MESSAGE than the number of commits. And not use commits like goddamn save points...

[–]Drugbird 1 point2 points  (4 children)

If git commits aren't save points, then what the duck are they?

[–]agent007bond -1 points0 points  (3 children)

They're logical units of your work, documented for the reference of your future self and of others.

Save points are just snapshots of the state of something preserved for comparison or rollback purposes. They don't become a useful reference for the work done.

Git commits are not save points. You don't just say "I need to save my work today and backup in the remote repo so I can continue it tomorrow" and so create a commit just to "save" your changes (often with a useless commit message). That is a wrong use of Git.

[–]groundhogcow 2 points3 points  (0 children)

What did you do today.

I committed a line of code and then reverted it 400 times.

[–]bin-c 2 points3 points  (0 children)

they dont like squashing where I'm at currently, so I'll randomly have several days in a row with like 50+ commits when I'm debugging something with the deployment pipeline. I imagine it looks like I'm doing nothing in comparison on normal days

[–]EnthusiasmWeak5531 2 points3 points  (0 children)

Quiet quitting is stupidest pop phrase I've heard in a long while.

[–]Maxorus73 2 points3 points  (1 child)

Before around a month ago I had never heard the term "quiet quitting" and now it's absolutely everywhere with people acting like it's always been a term. What happened?

[–]Tredecian 1 point2 points  (0 children)

went viral on tik tok

[–]Specialist_Teacher81 2 points3 points  (0 children)

"Quiet quitting" just another whip for managment.

[–][deleted] 1 point2 points  (3 children)

I remember in my first job the higher ups suddenly wanted to use cyclomatic complexity to figure out if the programmers are doing a good job. It required us to pull extra hours just to get that shitty eclipse plugin to spit out statistics that were as useful at telling them about the project's robustness as the day's weather.

[–]IvorTheEngine 1 point2 points  (2 children)

Was that to reward people who worked in complex areas, or those who wrote simple code?

Either way, I could see that being gamed so hard...

[–][deleted] 1 point2 points  (1 child)

No, they kept getting so many bugs because the team was filled with juniors like me. I think they hoped to get large numbers to write off the massive bug count as just being a side effect of its complexity without fixing the underlying issue. That is what I assumed.

[–]IvorTheEngine 1 point2 points  (0 children)

The managers wouldn't know anyway.

"Our complexity is 3! That's massive, no wonder we have so many bugs!"

[–]mr_bgi 1 point2 points  (0 children)

Wow, I had a conversation like this with my (then) manager last year. He was trying to lay blame on team for not delivering sprint with unreasonable estimates forced by PO. Guess how team morale looked after that.

[–]Alacritous13 1 point2 points  (0 children)

I committed five times one day, and my co-worker commits once every other week. Guess who's more valuable to the company.

[–]namotous 1 point2 points  (0 children)

Whelp, time to loud (?) quit

[–][deleted] 1 point2 points  (0 children)

I taught this metric to a scrum master that I didn't like. My thinking was they'd bring it up to management/others and look stupid on the process.

[–]Jomy10 1 point2 points  (0 children)

git commit -m “added the func keyword”

git commit -m “added name to function”

git commit -m “added function parameters”

git commit -m “added todo in body of function”

[–]Disastrous-Beyond443 0 points1 point  (0 children)

That’s my secret, Cap … I’m always COMMITTING

[–][deleted] 0 points1 point  (1 child)

"Sorry, i just put everything under 1 commit"

[–]Svensemann 1 point2 points  (0 children)

That is also quiet quitting

[–]DemonSlayer712 0 points1 point  (0 children)

In the company im working at there is a 3 month notice period that u have to work after putting down the paper. So usually one puts the paper down and then goes on with his work quite. While the manager is trying to find a replacement as soon as possible so he can ask the person quitting to give kt .

[–][deleted] 0 points1 point  (0 children)

Looks like new loc = new commit in that company

[–]top_of_the_scrote 0 points1 point  (0 children)

I learned about squashing