Notes in preparation for a discussion with new programmers

notes.txt

start w/ apple ][+ simulation, show how it taught me to communicate with it: 'list' shows the full source of the current program, line number-based editing, 'run' to test changes and 'save' to store them. 
then cut to chrome's dev tools, show how they teach us to communicate -- start from blank page, build vibraphone.

- started programming when six -- first phase is learning to speak to the machine and have it do what you want
- ultimately that means building a little computer inside your head, since communication is heavily predicated on prediction

your first 100 programs 
  - like games of go: get them out of the way as quickly as possible
  - you're learning the language: practice practice practice

learn to optimize, then forget everything you learned and intentionally de-optimize. 
  - your programs will be simpler
  - you leave more opportunity for global optimizations: doing less work trumps doing work faster
  - but first learn to optimize

keep it simple:
  - small teams (team of one if possible)
  - take on responsibility and ownership (of as little as possible, but be devout with what you have)
  - don't build anything you couldn't rebuild from scratch in a single month
  - use plumbing to stitch smaller pieces together (unix, service-driven, etc)
  - but don't ignore the plumbing -- it's just as important as your main API, and often harder to abstract

work yourself out of a job. automate like crazy.

- master your tools. customize them. don't update them. stay with them until you can use them without expending any energy. until you dream in your language / framework / environment / editor of choice. until it's fluid. 
- but keep learning everything you can. when new tools get to the point of eclipsing your current tools, switch. but not until at least a 50% boost. 

- take the path of least resistance to your goals. (have to know your goal first, then work backwards.) in some cases this takes a long time. as you increase the temporal interval over which you integrate your return on investment decisions selfishness asymptotically approaches altruism. 

- how do you add value to the world as a programmer?
- make someone who does real work more efficient. farmers. home builders. clothes makers. people who keep our drinking water safe. ditch diggers.
- make one of them twice as efficient and you've justified your existence. 
- make someone 10% more efficient and scale it out to 100 more people and you're doing the work of 10 valuable humans.
- double the efficiency of 100,000 people? you're a literal superhero.
- tie the value you extract from the world to the value you add to the world: you'll sleep soundly at night and make a lot of money
- put the money you make back in to your company -- you make people more efficient, so they make the world better, so they make money, so you make money, so you can use it to make them even *more* efficient: it's a virtuous cycle

- beautiful code: Arthur Whitney's J-like C

- blank slate -> input field -> trace text as you type -> canvas with colors for letters -> play like vibraphone

- get real users for your side projects
- ship early, share early, beg people to give you feedback on your code and applications

- i solve problems. i relieve pain points. i make people more efficient. 
- i do that mostly by building organisms composed of both humans and machines, each of them doing what they do best. 
- one problem is what the machines will be doing. another is convincing them to do it. 
- the harder problem is what the humans will be doing -- they're less predictable. 
- lines of communication and roles are the key. just like plumbing in your code: black box functions are lovely, but it's the plumbing that makes your application. 

- data transformations: if you think of your function as just a transformation of input data to output data, then you can compose functions without worrying about the effects that may have.

theory: humans build computer systems that simulate their natural mental environments. 
corollary: if you want to write cleaner [better?] code, upgrade your mental systems.
- organic code structure vs rigid code structure

code decay rate
- half-life of Ew
- probably about 5 days for you. six months for me. per page of code, 50% chance of ew. I've had times when it's been years. pros and cons, but an interesting measure of your progress as a coder -- which is decoupled from your progress at actually making useful things.

if you're adding value to the world, and you're not encountering issues that are slowing you down, don't worry about upgrading your tools. better to master a slightly inferior toolset than to jump from tool to tool without ever achieving mastery. 
city cowboys who buy all the "best" gear. weekend DIYers who buy super-fancy power tools they'll barely use and don't need. [i was almost one once, but the kindly neighborhood hardware store owner talked me out of it]

stages of learning
- convincing the computer to do what you ask [get the music in your blood]
- doing so in a way that is digestible by other humans
- learning to structure large programs
[this is a very incomplete list]

- find someone who does valuable, inexhaustible work -- if they did 10x more work the world would benefit at least 10x more from it. 
  - attach yourself to them and make it your job to make them more effective at their job
  - ???
  - profit!