This whole writing seems to assume that productivity is a feature of an individual and not a feature of a team. That’s a wrong assumption. The fairest way to pay is same salary for the whole team.
This writing is also PR for some individual company.
And this writing is three years old, written before the current economic slump. Nowadays the market is not so busy, at least not where I live in.
assume that productivity is a feature of an individual and not a feature of a team. That’s a wrong assumption. The fairest way to pay is same salary for the whole team.
So much of what we do produces nothing, but prevents a lot. There is definitely a reason to pay for experience and seniority: it’s not so much about creating widgets faster but more about not making short-sighted decisions. And in dev work, we have a high chance of making bad decisions as we’re second-generation lost-boys.
Having said that, those individuals are out there for whom compensation starts competitive and ends just short of their value. It’s eye-opening to meet and talk with these people and, once you do, it will change your life having them in it.
Above a certain level of seniority (in the sense of real breadth and depth of experience rather than merely high count of work years) one’s increased productivity is mainly in making others more productive.
You can only be so productive at making code, but you can certainly make others more productive with better design of the software, better software architecture, properly designed (for productivity, bug reduction and future extensibility) libraries, adequate and suitably adjusted software development processes for the specifics of the business for which the software is being made, proper technical and requirements analysis well before time has been wasted in coding, mentorship, use of experience to foresee future needs and potential pitfalls at all levels (from requirements all the way through systems design and down to code making), and so on.
Don’t pay for that and then be surprised of just how much work turns out to have been wasted in doing the wrong things, how much trouble people have with integration, how many “unexpected” things delay the deliveries, how fast your code base ages and how brittle it seems, how often whole applications and systems have to be rewritten, how much the software made mismatches the needs of the users, how mistrusting and even adversarial the developer-user relationship ends up being and so on.
From the outside it’s actually pretty easy to deduce (and also from having known people on the inside) how plenty of Tech companies (Google being a prime example) haven’t learned the lesson that there are more forms of value in the software development process than merely “works 14h/day, is young and intelligent (but clearly not wise)”
This whole writing seems to assume that productivity is a feature of an individual and not a feature of a team. That’s a wrong assumption. The fairest way to pay is same salary for the whole team.
This writing is also PR for some individual company.
And this writing is three years old, written before the current economic slump. Nowadays the market is not so busy, at least not where I live in.
So much of what we do produces nothing, but prevents a lot. There is definitely a reason to pay for experience and seniority: it’s not so much about creating widgets faster but more about not making short-sighted decisions. And in dev work, we have a high chance of making bad decisions as we’re second-generation lost-boys.
Having said that, those individuals are out there for whom compensation starts competitive and ends just short of their value. It’s eye-opening to meet and talk with these people and, once you do, it will change your life having them in it.
Above a certain level of seniority (in the sense of real breadth and depth of experience rather than merely high count of work years) one’s increased productivity is mainly in making others more productive.
You can only be so productive at making code, but you can certainly make others more productive with better design of the software, better software architecture, properly designed (for productivity, bug reduction and future extensibility) libraries, adequate and suitably adjusted software development processes for the specifics of the business for which the software is being made, proper technical and requirements analysis well before time has been wasted in coding, mentorship, use of experience to foresee future needs and potential pitfalls at all levels (from requirements all the way through systems design and down to code making), and so on.
Don’t pay for that and then be surprised of just how much work turns out to have been wasted in doing the wrong things, how much trouble people have with integration, how many “unexpected” things delay the deliveries, how fast your code base ages and how brittle it seems, how often whole applications and systems have to be rewritten, how much the software made mismatches the needs of the users, how mistrusting and even adversarial the developer-user relationship ends up being and so on.
From the outside it’s actually pretty easy to deduce (and also from having known people on the inside) how plenty of Tech companies (Google being a prime example) haven’t learned the lesson that there are more forms of value in the software development process than merely “works 14h/day, is young and intelligent (but clearly not wise)”