4 ms·

true.. adequate programmers code exactly what you tell them to..and even then it may not be great. Great engineers step back and ask 'why are you asking me to d

true.. adequate programmers code exactly what you tell them to..and even then it may not be great. Great engineers step back and ask 'why are you asking me to do this?'..(probably silently).. which inevitably leads to a more refined solution, or none at all when they realize you don't actually understand the actual problem, more likely just a symptom of it. Nobody remembers what didn't happen and they certainly don't pay you more for that. This is usually a function of experience, but not necessarily. Productive developers are constantly mapping each development requirement into a larger context of the 'system processes' at large, cross-referencing their (usually deeper) understanding of the technical, business, and political issues involved (all involving some acquisition or expenditure of 'energy' in the general sense). Their productivity is more a function of their understanding of economics writ large, than their recall of algorithms or specific toolsets. It's the main reason senior development is so difficult to hire for..

simonh 4y ago
My favourite programmer productivity anecdote: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
zasdffaa 4y ago
> Their productivity is more a function of their understanding of economics writ large, than their recall of algorithms or specific toolsets I agree with your post except for that bit. IME it is very much down to a more creative and questioning approach to coding that separates the better from the less good. I don't think, again IME, that asking the question "but should we?" has ever got me that far (though it is a good question) because bad managers take no notice and good managers have already asked it.
- cmollis 4y ago
  I think what I was trying to say is that the best performers attempt to understand the problem domain more holistically than, say, more average performers. What are the forces driving all of this and how do I deal with those forces in the most efficient way. Obviously, a dramatically more productive engineer also has deep experience is probably many toolsets, languages, etc., and that experience informs many of the decisions that they make when crafting a solution. However, I would argue that they have forgotten many of the picayune details of each, and only retain the most useful conceptual capabilities of those experiences so they can apply them quickly to some new and (seemingly) unrelated problem.

simonh 4y ago

My favourite programmer productivity anecdote: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

zasdffaa 4y ago

> Their productivity is more a function of their understanding of economics writ large, than their recall of algorithms or specific toolsets I agree with your post except for that bit. IME it is very much down to a more creative and questioning approach to coding that separates the better from the less good. I don't think, again IME, that asking the question "but should we?" has ever got me that far (though it is a good question) because bad managers take no notice and good managers have already asked it.

cmollis 4y ago
I think what I was trying to say is that the best performers attempt to understand the problem domain more holistically than, say, more average performers. What are the forces driving all of this and how do I deal with those forces in the most efficient way. Obviously, a dramatically more productive engineer also has deep experience is probably many toolsets, languages, etc., and that experience informs many of the decisions that they make when crafting a solution. However, I would argue that they have forgotten many of the picayune details of each, and only retain the most useful conceptual capabilities of those experiences so they can apply them quickly to some new and (seemingly) unrelated problem.