I really think you've hit home with this post. Personally, I tend to get stuck doing some course or other in order to try and improve my skills, but at the end I don't really have much to show, and even if I do (if you actually build something in the course), all I have to show is that I've done the course really since everybody else would have the same thing.
One thing I've learned in my career so far is the power of incentives and how bad things can go when you incentivize the wrong thing. I worked for a call center for a while, and instead of looking at the amount of successful sales, the manager started looking at the amount of time the agents were on the phone for. This lead to people drawing out the phone calls, making calls to themselves and then going on lunch etc. All because this was an adjustable value that was more a side effect of what was actually needed - the desired result. He eventually realized that there was just no way of fooling desired result, whereas the peripheral numbers can be manipulated.
I guess as developers, there's no getting around actually making products. At least it's an indication of what you can do and the fact that you actually can deliver something of value. What would your suggestions be for this though? Should people be more focused on delivering products to show people? Building up their GitHub profile etc?
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.
I really think you've hit home with this post. Personally, I tend to get stuck doing some course or other in order to try and improve my skills, but at the end I don't really have much to show, and even if I do (if you actually build something in the course), all I have to show is that I've done the course really since everybody else would have the same thing.
One thing I've learned in my career so far is the power of incentives and how bad things can go when you incentivize the wrong thing. I worked for a call center for a while, and instead of looking at the amount of successful sales, the manager started looking at the amount of time the agents were on the phone for. This lead to people drawing out the phone calls, making calls to themselves and then going on lunch etc. All because this was an adjustable value that was more a side effect of what was actually needed - the desired result. He eventually realized that there was just no way of fooling desired result, whereas the peripheral numbers can be manipulated.
I guess as developers, there's no getting around actually making products. At least it's an indication of what you can do and the fact that you actually can deliver something of value. What would your suggestions be for this though? Should people be more focused on delivering products to show people? Building up their GitHub profile etc?
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)