Creating incentive structures with perverse incentives is one of the most common organizational problems out there. I logged ~5 years as an IT management consultant, and this (anti) pattern occurred over and over. There's a great saying, though I'm not sure of its attribution: "if you give your staff a metric, they will achieve that metric, even if they have to burn the company to the ground to do it."
The most common instantiation of this object, so to speak, in software was always unit test coverage. I can't tell you how many codebases I've seen with 75+ percent code coverage, achieved with "unit tests" that contain no asserts and such. Asked about, devs would say, "we've got delivery pressure, and we can't commit if we don't make Sonar happy... so we make it happy."
Anyway, I think my advice about measuring success and choosing skills would depend heavily on whether the developer is a current/aspiring freelancer or an employee. For an employee, it'd really be about finding job description/requirements for desired job(s) and working backward toward being well suited for that. For the freelancer... it's more of a heavy mindset shift to thinking about how to deliver holistic outcomes for clients. And the reason I make this distinction is that employers tend to view developers as tuples of (skill, experience years), whereas clients are more interested in outcomes (unless they're just mining Upwork for staff aug/pseudo-employee contractors)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Creating incentive structures with perverse incentives is one of the most common organizational problems out there. I logged ~5 years as an IT management consultant, and this (anti) pattern occurred over and over. There's a great saying, though I'm not sure of its attribution: "if you give your staff a metric, they will achieve that metric, even if they have to burn the company to the ground to do it."
The most common instantiation of this object, so to speak, in software was always unit test coverage. I can't tell you how many codebases I've seen with 75+ percent code coverage, achieved with "unit tests" that contain no asserts and such. Asked about, devs would say, "we've got delivery pressure, and we can't commit if we don't make Sonar happy... so we make it happy."
Anyway, I think my advice about measuring success and choosing skills would depend heavily on whether the developer is a current/aspiring freelancer or an employee. For an employee, it'd really be about finding job description/requirements for desired job(s) and working backward toward being well suited for that. For the freelancer... it's more of a heavy mindset shift to thinking about how to deliver holistic outcomes for clients. And the reason I make this distinction is that employers tend to view developers as tuples of (skill, experience years), whereas clients are more interested in outcomes (unless they're just mining Upwork for staff aug/pseudo-employee contractors)