4 ms·

I agree that measuring productivity is a hard, universal problem. While I don't claim to commit 10x more LOCs, I do write exceptional abstractions that allow m

by vemv 10y ago

I agree that measuring productivity is a hard, universal problem. While I don't claim to commit 10x more LOCs, I do write exceptional abstractions that allow me to get things done in a quick, robust way. I've met far too many 'senior' developers blatantly breaking DRY because they don't really know/use all features $language or $framework has to offer.

tmptmp 10y ago
You don't have to claim "10x more LOC", if your abstractions are powerful enough to capture a vast breadth of situations in an elegant and not-an-over-inefficient manner. If you could achieve this feat, I'd say you are already a 10x type programmer. It's good you are better at abstraction, you may not be 10x but you may be 5x/4x and that's significant. LOC is the worst measure of productivity, but sadly, most managers (mainly, the excel sheet type managers) find it easy because they can use LOC in their shitty formulas.
jfoster 10y ago
I think you're missing Jare's point. You don't need an amazingly powerful engine in your car to go at 20 miles/hour, just as companies don't need 10x programmers to work on the types of software problems that Jare asserts Spanish companies are working on.
- lightbendover 10y ago
  In my experience, the real '10x' productivity bump comes from engineers who can internalize huge swaths of the codebase and make all of the necessary connections. Given a large enough product, that will be out of reach for the majority, due to either dedication or capacity. Hearing about a new feature and instantly knowing the implementation points and consequences instead of having to fumble around parts of the system you're not familiar with is easily '10x,' LOC be damned.
jfoutz 10y ago
I've worked with developers that commit far far more code than i do. I still find it intimidating. I take solice in replacing those 50kloc subsystems with a few interfaces and a handful of implementations. Those -40kloc days are awesome. To be fair, those guys that throw out tons of code really explore the problem space. it's tough to start with a clean design when the spec is vague.
thinkloop 10y ago
Several years ago I took over the lead UI position at a company. Jira has a feature to display lines of code contributed by developer. After 10 months of adding features, and getting the product to shipping, I had contributed -1500 lines. There were less lines than when I started, and the code was simpler for it. I'd _almost_ say that LOC is a good measure of bad coding.
- 50CNT 10y ago
  It's a general thing about data. Just because it is easy to measure doesn't mean its a useful metric. My hunch is that as expertise increases for developers, LOC/day initially goes up, as they have to think less about language constructs and how to do certain things. Once a certain level of expertise is reached, LOC/day goes down, as the developer figures out how to do more with less code and spends more time in decision making and planning.
wiredfool 10y ago
I'll just leave this here: http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...

by vemv 10y ago

tmptmp 10y ago

You don't have to claim "10x more LOC", if your abstractions are powerful enough to capture a vast breadth of situations in an elegant and not-an-over-inefficient manner. If you could achieve this feat, I'd say you are already a 10x type programmer. It's good you are better at abstraction, you may not be 10x but you may be 5x/4x and that's significant. LOC is the worst measure of productivity, but sadly, most managers (mainly, the excel sheet type managers) find it easy because they can use LOC in their shitty formulas.

jfoster 10y ago

I think you're missing Jare's point. You don't need an amazingly powerful engine in your car to go at 20 miles/hour, just as companies don't need 10x programmers to work on the types of software problems that Jare asserts Spanish companies are working on.

lightbendover 10y ago
In my experience, the real '10x' productivity bump comes from engineers who can internalize huge swaths of the codebase and make all of the necessary connections. Given a large enough product, that will be out of reach for the majority, due to either dedication or capacity. Hearing about a new feature and instantly knowing the implementation points and consequences instead of having to fumble around parts of the system you're not familiar with is easily '10x,' LOC be damned.

jfoutz 10y ago

I've worked with developers that commit far far more code than i do. I still find it intimidating. I take solice in replacing those 50kloc subsystems with a few interfaces and a handful of implementations. Those -40kloc days are awesome. To be fair, those guys that throw out tons of code really explore the problem space. it's tough to start with a clean design when the spec is vague.

thinkloop 10y ago

Several years ago I took over the lead UI position at a company. Jira has a feature to display lines of code contributed by developer. After 10 months of adding features, and getting the product to shipping, I had contributed -1500 lines. There were less lines than when I started, and the code was simpler for it. I'd _almost_ say that LOC is a good measure of bad coding.

50CNT 10y ago
It's a general thing about data. Just because it is easy to measure doesn't mean its a useful metric. My hunch is that as expertise increases for developers, LOC/day initially goes up, as they have to think less about language constructs and how to do certain things. Once a certain level of expertise is reached, LOC/day goes down, as the developer figures out how to do more with less code and spends more time in decision making and planning.

wiredfool 10y ago

I'll just leave this here: http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...