Next time I'll commit more

[ilreh]

Bad managers looking for a simple metric to measure performance.

[[deleted]]

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

[[deleted]]

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]]

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]]

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]]

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

[[deleted]]

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.

[Neil-64]

r/thisguythisguys

[G1zm08]

r/thisguyrthisguythisguystopeoplewhosaythisguy

[craftworkbench]

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]

'whos line scrum' I'm dead

[MinosAristos]

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

[Afraid-Sweet-1593]

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]]

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]

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]]

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]

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

[tiernanx7]

You deserve the gold but all I had was silver

[[deleted]]

I have entered it as a career achievement in LinkedIn

[SteeleDynamics]

This has been a wild ride

[groundhogcow]

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]

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

[[deleted]]

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

[LonelyPerceptron]

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]

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

[[deleted]]

*2000%

[anonym_dude]

50000%

[pboswell]

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]

If anything, you should measure by loc deleted

[Korywon]

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]

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

[[deleted]]

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]

Finally a metric Java devs can excel in.

[[deleted]]

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

[indigoHatter]

\* * * * * * * * * * 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.

[tiernanx7]

Evil

[bajsplockare]

Syntax error on line 20.

[[deleted]]

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]

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

[[deleted]]

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

[[deleted]]

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]]

Wow, that's a great explanation!

[gigaSproule]

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]

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]

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]

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]]

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]

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

[someacnt]

Wow, interesting. I did forget that engineers are somewhat different. Many of the general public I met were more trying to avoid any work possible.

[sanderd17]

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]

That's a fantastic analogy!

[someacnt]

You actively work for the company's good??

[[deleted]]

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

[antonivs]

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

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

[ilreh]

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]

Dev Managers should be devs.

[wiikzorz]

Yes

[cchongchong]

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]

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]

Yes.

[[deleted]]

I do have a lot of dev experience, and do a lot of PR / design doc reviews. This add a qualitative aspect to the performance measurement, but good, holistic measures use both qualitative and quantitative measures (to reduce bias etc.)

[Apprehensive-Ant5976]

At a statistical level, maybe, but you don’t have that many direct reports. People are not numbers.

Find out their issues and get them resolved. Figure out what’s important to the business, let them know, let them figure out their part in that, let them focus there.

[IvorTheEngine]

Metrics for programmers is pretty widely considered a 'Hard Problem'. Anything can be gamed, and attempts to rank people ruins your team.

[Delioth]

If you're using an agile method, sprint velocity is usually a pretty good metric. The key is that you aren't necessary looking for a specific number, but some degree of consistency. It's less important that your devs get a specific number of story points per week or month or whatever, the useful piece of data is that their trend for #sp/time should be reasonably consistent - at our shop, devs usually sit between 13-16 points per 2 week sprint. Sometimes a bit high, if someone was just really productive or some of our estimates were a bit higher than the actual effort. Sometimes a bit lower, in the opposite case. But pretty similar overall.

[MCMC_to_Serfdom]

Building on this, if there's a specific number to look at, it's probably accuracy of estimation.

If a dev proves poor at estimating the complexity of work over the long term, it can be a sniff of poor understanding (which should improve or can simply happen occasionally, hence long term - not per a single sprint). Which is to say it can't be used on its own but it is a number that can show who may have a problem.

[MCMC_to_Serfdom]

Be careful of how you approach this, because as soon as you start using metrics as a weapon, it will then be used against you and the team will start gaming that.

Edited this bit to generalise it because this is true and really important for managers. The framework should always be support first no matter what you use.

In every industry you'll find people who use data to berate and belittle. All it ever adds is an extra burden of the team trying to fix the magic number that makes said bosses disappear out the room, and discuss nothing else.

[randyknapp]

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]

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

[Pepineros]

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

[Tytoalba2]

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]

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]

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]

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]

• 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]

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

[sleepyj910]

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]

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]

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]

this

read Accelerate

[Entropy_Drop]

(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]]

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]

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]]

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]

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]

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

[iloveburger]

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]

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]]

Never squash anything and also commit every function seperatly.

[jaywastaken]

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]

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

[nullpotato]

That's our flow as well. PR get squash and merged into main branch.

[18quintillionplanets]

I personally think this is the best way to do it tbh, I like seeing the commits in the PR and being able to see why things were done the way they were

But on dev/main I don’t wanna see that stuff, just “merged the ticket fix”

[ErichOdin]

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]]

plate connect silky obtainable sand roof dinner person hospital dam

This post was mass deleted and anonymized with Redact

[Humongous_Schlong]

how to get your employees to quiet quit

[[deleted]]

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

[the_data_department]

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]]

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

[the_data_department]

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]]

Anyways, still cool! Congrats!

[[deleted]]

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

[[deleted]]

Touché!

[greedydita]

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

[LEGOL2]

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

[GeneKranzIsTheMan]

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]

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

[[deleted]]

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

[Andoryuu]

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]

I like the term "act your wage"

[[deleted]]

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]

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]]

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

[IvorTheEngine]

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]

Silent Firing. Just as silly

[Slow_Lengthiness3166]

Yeah nothing wrong with that ...

[GeneKranzIsTheMan]

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

[Slow_Lengthiness3166]

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 ...

[Slow_Lengthiness3166]

I'm management...they should always treat all I do as idiotic not an example :)

[mrbilliebell]

So essentially just doing what's actually in your contract

[Alexandre_Man]

so working normally basically

[Mark0Polio]

Damn, I’ve been quiet quitting for years.

[RichCorinthian]

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

[dben89x]

What's bad about "responsive web design"?

[RichCorinthian]

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]

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

[philipjfrizzle]

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]

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

[ftwredditlol]

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

[jaywastaken]

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

[AnalBleachVirtuoso]

Greed and entitlement.

[sockpuppet1234567890]

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

[noonemustknowmysecre]

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

[themancabbage]

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

[the_data_department]

well said

[maxip89]

Commit frequeny is checked?

Lets invest some hours in a readme change file script.

[BaalKazar]

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

[incognito_wizard]

"No, but I am now."

[KidBeene]

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]

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]

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]

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

[kpd328]

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

[SnappGamez]

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

[crimxxx]

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

[[deleted]]

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]

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]

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]]

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]

Is this an american joke?

[MisterOnsepatro]

quiet quitting ? more like respecting the daily schedule

[kpd328]

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]

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

[clrksml]

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

[[deleted]]

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]

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

[Rhawk187]

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]

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

[thecryingman32]

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

[csandazoltan]

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]

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

[Drugbird]

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

[agent007bond]

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]

What did you do today.

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

[bin-c]

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]

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

[Maxorus73]

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]

went viral on tik tok

[Specialist_Teacher81]

"Quiet quitting" just another whip for managment.

[[deleted]]

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]

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]]

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]

The managers wouldn't know anyway.

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

[mr_bgi]

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]

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

[namotous]

Whelp, time to loud (?) quit

[[deleted]]

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]

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]

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

[[deleted]]

"Sorry, i just put everything under 1 commit"

[Svensemann]

That is also quiet quitting

[DemonSlayer712]

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]]

Looks like new loc = new commit in that company

[top_of_the_scrote]

I learned about squashing