I posit that there are two distinct ways in which people become fascinated by programming.

One way is via high-level languages, web development tools, and visual languages. This “way” in is for people who are more interested in the act of creating with code than coding itself. I call these people the “artist-programmers”: people who don’t care about pointers and arrays, and would much rather fiddle with knobs and buttons than bits and bytes to create something cool. Artist-programmers can trust what is under the hood, and use this metaphorical car to go very far.

On the other hand, some people start programming with coding as the goal. These people learn about the array and are FASCINATED. These people can spend an afternoon messing with pointer indirection and not call it wasted time. These “scientist-programmers” believe that typing, references, and pointers are important to understand – their metaphorical car sits in the garage, taken apart into its components, and yet they are more fulfilled than if they were out driving it without any idea how it works. These programmers usually arrive via C, Assembly, or even hardware.

I think both ways to learn programming are correct, and appeal to different people. One of the reasons I enjoy python as a first language is that it is broad enough to appeal to both types as people. Lisp is great for this as well. Teaching an artist-programmer C++ is going to be a painful process for everyone involved. And teaching a scientist-programmer Mathematica will leave them wanting to know what’s going on inside.

The “programmer-in-fullness”, however, is both an artist-programmer and a scientist-programmer. These programmers are driving the metaphorical car AND have a full understanding of what’s going on inside the hood. They can speed along in a high-level language, but know what is happening on the inside enough to optimize as they write, fix things when they break, and use the right data structures and algorithms without sacrificing time worrying about the details.

Edit: My friend and fellow Hacker School alumnus @jordanorelli provides a great distillation of this idea: “I think the distinction is that I’m driven to learn things because they allow me to create things, whereas many others are driven to create things because in doing so, they learn things. Do you learn to create, or do you create to learn?”

Some thoughts on the types:

Artist-Programmers:

• Teaching Them:
  • Focus on high level languages and visual languages
  • Focus on process and outcome, not design or implementation
  • Focus on immediate feedback and not worrying about speed
• As one:
  • Don’t feel bad about using tools and helpers (e.g. Dreamweaver)
  • Aim for large projects that you can use these big tools to complete
• To become a programmer-in-fullness:
  • Take a course like NAND-to-Tetris, which will allow you to see how the parts all fit together in a project
  • Take an interest in optimization, as far as you’ll still be able to finish your projects
  • Take apart your favorite tool and see how it works

Scientist-Programmers:

• Teaching Them:
  • Focus on the little things. Pointers. Arrays. Bytecode.
  • Give them an extremely restricted toolset and a slow processor.
  • Start them in on data structures and algorithms fast – they’ll eat it up.
• As one:
  • Buy books on programming. Implement their examples. Explore hardware organization.
  • Don’t be frustrated by projects that you can’t finish, as long as you learned something in the process.
  • Contribute to larger artist-programmer projects which can use your optimization skills.
  • Don’t mock artist-programmers for using tools. They don’t mock you for not using tools!
• To become a programmer-in-fullness:
  • Start to use libraries and packages which will allow you to complete projects faster, even if you don’t know what they do at the low level.
  • Focus on optimization less, as long as you still understand what’s going on inside.
  • Work hard to finish projects, as painful as the final sprint is.

And above all, understand that people might come to programming from a different perspective than you. The scale is most likely not binary, either – think of it as a float instead of a bool. And be able to use this knowledge to give people projects that they’ll be interested in and will do well with.

From Manhattan,

–Erty