3 ms·

There are things where it's not about learning as much as about the quality of code you produce within the same timeframe. My personal record of rewriting a big

by mojuba 7y ago

There are things where it's not about learning as much as about the quality of code you produce within the same timeframe. My personal record of rewriting a big product was reducing a 150k LOC project to 7k lines with the same functionality and then some more. Now compare the cost of maintenance of 150k lines of code vs 7k. That literally translates to a lot of (saved) money for the company. While that one was probably a bit extreme, even 3x or 4x reduction can be a big win. These things come with experience more than "learning" in the traditional sense.

world32 7y ago
Fair point but do we have any actual data around the correlation between years of experience and value to a company? Admittedly its probably a hard thing to measure.. Because I can also tell you another anecdotal example of some developers who each had 20+ years experience each and we're quite high ranking they company they worked at: - They would re-invent the wheel constantly: the framework provided lots of functionality which had been developed and battle tested by thousands of other developers but they couldn't be bothered to learn what was available to them so wrote a lot of functionality from scratch which was usually far more buggy than the open source code available. - classes which had literally 10,000+ lines of code in them. - of course the idea of following SOLID principles was never ever going to happen - a general view that they were the experienced ones who "just made it work and got on with the job" while the younger programmers or those who followed more modern practices were seen by them as being "airy-fairy" and worried about things that didn't matter. that argument might have held weight if the application they built wasn't so awfully riddled with bugs and so poorly architected that mainting it and building new features took ages. - They had all been working at the same company for at least 15 years, so they were able to ignore the advances made in software development in that time and carry on with their old ways. Of course they could still code new features and fix bugs but they didn't realise that what they were doing could be done in a much much better way. I'm not saying all old developers are like this. But if somebody is able to tell me that older developers are better because X, then they should be able to accept somebody else disagreeing and saying that older developers are worse because Y. You can't have it both ways.

by mojuba 7y ago

world32 7y ago

Fair point but do we have any actual data around the correlation between years of experience and value to a company? Admittedly its probably a hard thing to measure.. Because I can also tell you another anecdotal example of some developers who each had 20+ years experience each and we're quite high ranking they company they worked at: - They would re-invent the wheel constantly: the framework provided lots of functionality which had been developed and battle tested by thousands of other developers but they couldn't be bothered to learn what was available to them so wrote a lot of functionality from scratch which was usually far more buggy than the open source code available. - classes which had literally 10,000+ lines of code in them. - of course the idea of following SOLID principles was never ever going to happen - a general view that they were the experienced ones who "just made it work and got on with the job" while the younger programmers or those who followed more modern practices were seen by them as being "airy-fairy" and worried about things that didn't matter. that argument might have held weight if the application they built wasn't so awfully riddled with bugs and so poorly architected that mainting it and building new features took ages. - They had all been working at the same company for at least 15 years, so they were able to ignore the advances made in software development in that time and carry on with their old ways. Of course they could still code new features and fix bugs but they didn't realise that what they were doing could be done in a much much better way. I'm not saying all old developers are like this. But if somebody is able to tell me that older developers are better because X, then they should be able to accept somebody else disagreeing and saying that older developers are worse because Y. You can't have it both ways.