3 ms·

From personal experience, speed has very little to do with productivity. Productivity is a function of knowledge and experience. The most productive programmer

From personal experience, speed has very little to do with productivity. Productivity is a function of knowledge and experience. The most productive programmers I've met almost always had enough experience in what not to use. They have a clear focus on the simplicity of their code and their ability to reason about it. They understand the problem and the hardware as well as the language in a very detailed manner. They are by nature extraordinarily curious people. In comparison, the worst programmers I've met were the exact opposite, learning barely enough to get the job done and never digging into the details. Sometimes they don't even understand the hardware they're using. They pick the wrong data structures, think about code first and data is an afterthought. Productive programmers don't really type faster or think faster. They just make far less mistakes to begin with and such mistakes always inflate the development time exponentially.

altcognito 11y ago
> They pick the wrong data structures, think about code first and data is an afterthought. It makes me so happy to read this. Data in the grand scheme of things is vastly more important than code. "picking" data structures is a luxury in many cases and thus data structure often dictates the structure and expectations of your code. Data usually outlives the code. Data is effectively the earth in your code farm. Take care of it, and form it as best you can given a set of restrictions so that your program runs smoothly.
- base698 11y ago
  According to SICP data and code are the same! Interesting concept anyway. http://stackoverflow.com/questions/355406/concepts-that-surprised-you-when-you-read-sicp#answer-483339 http://stackoverflow.com/questions/355406/concepts-that-surp... http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#%_sec_2.1.3 http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html...
  - webnrrd2k 11y ago
    That's like saying all Turing-equivalent languages are the same. It may be true in theory, but is hardly a useful point in most programming language discussions. As an example of code vs. data, and this is a general statement (so YMMV) I try to structure my code such that, if there is a choice between making the code more complex, vs making the data more complex, I generally choose to make the data more complex. The code is usually harder to reason about, so it's a win if I can use a simpler algorithm.
    - seabee 11y ago
      Unless I misunderstand your point, how do you create complex data without complex code? I agree with the sentiment, but priority queues don't organise themselves. It seems more like its about the abstractions you use.
      - webnrrd2k 11y ago
        It's more of a general rule, a rule of thumb, and the difference between data and code can be very fluid, depending on the situation... But as a general rule it's worth paying attention to. Just a quick example -- I need to get going -- Say I have a bunch of data in a database I need to do something to once or twice, like validating imported data. It's easier to use a complex select to get it in an easy to process form, then it is to use a simple select and have a complex algorithm to process the data. Generally, given the choice, it's easier to have complicated "static" data, since it's rather static and easier to reason about, rather than complicated "dynamic" code since algorithms are generally harder to reason about.
        sokoloff 11y ago
        I agree with your choice in the example, but I think of your select as code, not as data. So, you're moving the complex code closer to the data, but it's still code IMO.
- henrik_w 11y ago
  I like these two quotes on that: "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." Fred Brooks, The Mythical Man-Month. "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." Linus Torvalds
nilkn 11y ago
> From personal experience, speed has very little to do with productivity. Productivity is a function of knowledge and experience. As I wrote elsewhere, it's not just speed. The more talented programmers I referred to write better, cleaner, more performant and more elegant code -- and they do it faster. > Productive programmers don't really type faster or think faster. They just make far less mistakes to begin with and such mistakes always inflate the development time exponentially. We can postulate all sorts of different explanations. I wasn't attempting to do that in my previous post. I was just relaying my own repeated observations that some programmers don't just write better code -- they manage to do it much faster too. Do they think faster? I don't know. They just have a knack for programming. It's obvious to them which data structure to use, so they just use it. Maybe it just comes down to this. If it's not obvious to someone which data structure to use and they have to spend a significant amount of time being confused about it, not only are they more likely to make the wrong choice, but they're likely to take longer too. Someone who, for whatever reason, has better intuition about how to structure a piece of code is going to be able to write it faster, not because they think or type faster, but because they just didn't even have to think as much in the first place. Consequently, I suppose that frees up mental space for thinking about the cleanliness of the code and other such factors.
- verbin217 11y ago
  I suspect those that learn to program before they're expected to have more undirected time to consider alternative formulations of their programs. People who learn later aren't performing the playful exploration that's necessary for independent mastery. They're just treating it like any other subject and completing tasks for the approval of an authority figure. I watched plenty of students learn bad habits from arrogant teachers like it was just "the way" you program. We don't have some master method of programming that can be taught that way. It's not like we're building bridges and already know pretty much exactly what we're doing. The craft is evolving before our eyes. They have to understand the incomplete state of our knowledge to know that they should seek superiority amongst potential selves and not merely acceptance from some external deity.
devonkim 11y ago
While there's clearly some skill that matters, there's a difference between someone that's going slow and being thoughtful (arguably too thoughtful in many cases, myself included especially here) and being just plain slow. My idea of a slow and not particularly thoughtful programmers are the ones that really do look like someone's programming in slow motion - as well as everything else (this is something beyond the professional work I've seen). They're slow to ssh to a remote server, they're still typing in passwords again and again every day, they're slow to type out even a simple git commit message, they're slow to write out an e-mail that has very low interesting content in it. In their off-time, they're going fishing, maybe playing board games, or just constantly trying to relax and avoid thinking about anything at all because they seem to instinctively avoid anything that would be serious or present any sort of stress. To me, they're the complete opposite of the "type A" personality that's always trying to stay occupied and hyperactive. I have no problem with this life approach on a personal level, but it's a liability in a business setting wherever you are in the world and whatever industry you're in because there is just no urgency to anything and the person is pretty much incapable of handling modern professional life perhaps in general.
JoachimS 11y ago
Heh, I know one prime example. A guy with a Masters degree that for some reason really fell in love with linked lists in one of the courses. Ever since it is THE data structure he uses no matter what. And yes he starts coding away while reading the specs. He gets something up and running quickly, but it is rarely close to the spec and expected solution.
BurningFrog 11y ago
> Productive programmers don't really type faster or think faster. They just make far less mistakes to begin with This reminds me of studies of chess players. It turns out that grand masters and average club players think as far ahead and as fast. The master just think of better moves.

altcognito 11y ago

> They pick the wrong data structures, think about code first and data is an afterthought. It makes me so happy to read this. Data in the grand scheme of things is vastly more important than code. "picking" data structures is a luxury in many cases and thus data structure often dictates the structure and expectations of your code. Data usually outlives the code. Data is effectively the earth in your code farm. Take care of it, and form it as best you can given a set of restrictions so that your program runs smoothly.

base698 11y ago
According to SICP data and code are the same! Interesting concept anyway. http://stackoverflow.com/questions/355406/concepts-that-surprised-you-when-you-read-sicp#answer-483339 http://stackoverflow.com/questions/355406/concepts-that-surp... http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#%_sec_2.1.3 http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html...
- webnrrd2k 11y ago
  That's like saying all Turing-equivalent languages are the same. It may be true in theory, but is hardly a useful point in most programming language discussions. As an example of code vs. data, and this is a general statement (so YMMV) I try to structure my code such that, if there is a choice between making the code more complex, vs making the data more complex, I generally choose to make the data more complex. The code is usually harder to reason about, so it's a win if I can use a simpler algorithm.
  - seabee 11y ago
    Unless I misunderstand your point, how do you create complex data without complex code? I agree with the sentiment, but priority queues don't organise themselves. It seems more like its about the abstractions you use.
    - webnrrd2k 11y ago
      It's more of a general rule, a rule of thumb, and the difference between data and code can be very fluid, depending on the situation... But as a general rule it's worth paying attention to. Just a quick example -- I need to get going -- Say I have a bunch of data in a database I need to do something to once or twice, like validating imported data. It's easier to use a complex select to get it in an easy to process form, then it is to use a simple select and have a complex algorithm to process the data. Generally, given the choice, it's easier to have complicated "static" data, since it's rather static and easier to reason about, rather than complicated "dynamic" code since algorithms are generally harder to reason about.
      - sokoloff 11y ago
        I agree with your choice in the example, but I think of your select as code, not as data. So, you're moving the complex code closer to the data, but it's still code IMO.
henrik_w 11y ago
I like these two quotes on that: "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." Fred Brooks, The Mythical Man-Month. "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." Linus Torvalds

nilkn 11y ago

> From personal experience, speed has very little to do with productivity. Productivity is a function of knowledge and experience. As I wrote elsewhere, it's not just speed. The more talented programmers I referred to write better, cleaner, more performant and more elegant code -- and they do it faster. > Productive programmers don't really type faster or think faster. They just make far less mistakes to begin with and such mistakes always inflate the development time exponentially. We can postulate all sorts of different explanations. I wasn't attempting to do that in my previous post. I was just relaying my own repeated observations that some programmers don't just write better code -- they manage to do it much faster too. Do they think faster? I don't know. They just have a knack for programming. It's obvious to them which data structure to use, so they just use it. Maybe it just comes down to this. If it's not obvious to someone which data structure to use and they have to spend a significant amount of time being confused about it, not only are they more likely to make the wrong choice, but they're likely to take longer too. Someone who, for whatever reason, has better intuition about how to structure a piece of code is going to be able to write it faster, not because they think or type faster, but because they just didn't even have to think as much in the first place. Consequently, I suppose that frees up mental space for thinking about the cleanliness of the code and other such factors.

verbin217 11y ago
I suspect those that learn to program before they're expected to have more undirected time to consider alternative formulations of their programs. People who learn later aren't performing the playful exploration that's necessary for independent mastery. They're just treating it like any other subject and completing tasks for the approval of an authority figure. I watched plenty of students learn bad habits from arrogant teachers like it was just "the way" you program. We don't have some master method of programming that can be taught that way. It's not like we're building bridges and already know pretty much exactly what we're doing. The craft is evolving before our eyes. They have to understand the incomplete state of our knowledge to know that they should seek superiority amongst potential selves and not merely acceptance from some external deity.

devonkim 11y ago

While there's clearly some skill that matters, there's a difference between someone that's going slow and being thoughtful (arguably too thoughtful in many cases, myself included especially here) and being just plain slow. My idea of a slow and not particularly thoughtful programmers are the ones that really do look like someone's programming in slow motion - as well as everything else (this is something beyond the professional work I've seen). They're slow to ssh to a remote server, they're still typing in passwords again and again every day, they're slow to type out even a simple git commit message, they're slow to write out an e-mail that has very low interesting content in it. In their off-time, they're going fishing, maybe playing board games, or just constantly trying to relax and avoid thinking about anything at all because they seem to instinctively avoid anything that would be serious or present any sort of stress. To me, they're the complete opposite of the "type A" personality that's always trying to stay occupied and hyperactive. I have no problem with this life approach on a personal level, but it's a liability in a business setting wherever you are in the world and whatever industry you're in because there is just no urgency to anything and the person is pretty much incapable of handling modern professional life perhaps in general.

JoachimS 11y ago

Heh, I know one prime example. A guy with a Masters degree that for some reason really fell in love with linked lists in one of the courses. Ever since it is THE data structure he uses no matter what. And yes he starts coding away while reading the specs. He gets something up and running quickly, but it is rarely close to the spec and expected solution.

BurningFrog 11y ago

> Productive programmers don't really type faster or think faster. They just make far less mistakes to begin with This reminds me of studies of chess players. It turns out that grand masters and average club players think as far ahead and as fast. The master just think of better moves.