An important point appearing elsewhere in the comments: who is a programmer anyway? If you can write Hello World in C, are you a programmer? If you can't write your own compiler are you a non-programmer? This is an unanswerable question.
Maybe we could focus on kinds of thinking that help you program well. There is nothing you can't learn eventually. However, we might find some common ground by looking at how good programmers have trained their minds.
We can list some desirable skills for a programmer that reach across languages and tools. There is an old saw by Joel on Software that some people just can't understand pointers and recursion. Or on the next level, that some people can't understand multithreaded/parallel programming. I think I'd say that an instinct for simplicity or mathematical beauty and symmetry also plays a role in making good designs. In other words, making not just consistent mental models that you can simulate in your head (as another comment says), but making beautiful ones.
I was sitting with my manager yesterday. He was giving me requirements for a system I'll have to build over the next two weeks. Along the way we came across a problem where we need to take a bunch of multidimensional values and combine them together.
Instead of leaving it to me, he wanted to design it on the spot. He thought of this like voting where each value makes some contribution, but then the requirements dictated that we needed to add things like "some values have more votes than others", and "some votes have veto power".
As he was describing this pseudo-consensus algorithm with weights and vetos, I was surprised he didn't know how ugly this design sounded. It is hard to set up the contribution of each value, hard to predict the behavior, and hard to make intuitive.
It's not that this is a bad, uncreative idea. Voting is an interesting analogy for the problem, and intuition is a good way to take a stab at a problem. It's that when he started working it out he didn't see the multiplying problems, or the counterexamples that would cause trouble for his system. And I do think this is something that good programmers and system designers do well, even without much conscious thinking. They find the attack surface, figure out where their abstraction leaks, jump immediately to edge cases.
I'm going to have to pull him back early next week. :oD
You don't have to say that the programmer has a magic switch in their brain that enabled them to be a genius while everyone else is left out. Anyone Can Cook!
Maybe we could focus on kinds of thinking that help you program well. There is nothing you can't learn eventually. However, we might find some common ground by looking at how good programmers have trained their minds.
We can list some desirable skills for a programmer that reach across languages and tools. There is an old saw by Joel on Software that some people just can't understand pointers and recursion. Or on the next level, that some people can't understand multithreaded/parallel programming. I think I'd say that an instinct for simplicity or mathematical beauty and symmetry also plays a role in making good designs. In other words, making not just consistent mental models that you can simulate in your head (as another comment says), but making beautiful ones.
I was sitting with my manager yesterday. He was giving me requirements for a system I'll have to build over the next two weeks. Along the way we came across a problem where we need to take a bunch of multidimensional values and combine them together.
Instead of leaving it to me, he wanted to design it on the spot. He thought of this like voting where each value makes some contribution, but then the requirements dictated that we needed to add things like "some values have more votes than others", and "some votes have veto power".
As he was describing this pseudo-consensus algorithm with weights and vetos, I was surprised he didn't know how ugly this design sounded. It is hard to set up the contribution of each value, hard to predict the behavior, and hard to make intuitive.
It's not that this is a bad, uncreative idea. Voting is an interesting analogy for the problem, and intuition is a good way to take a stab at a problem. It's that when he started working it out he didn't see the multiplying problems, or the counterexamples that would cause trouble for his system. And I do think this is something that good programmers and system designers do well, even without much conscious thinking. They find the attack surface, figure out where their abstraction leaks, jump immediately to edge cases.
I'm going to have to pull him back early next week. :oD
You don't have to say that the programmer has a magic switch in their brain that enabled them to be a genius while everyone else is left out. Anyone Can Cook!
edit: wwhere => where