## What You Might Have Learned From this Instance of Software Dev

- the course 

- planning, aka interface design 
- program design

- partners
- reviews 

- your favorite programming language 

### The Course 

It is a studio course, so you primarily learned from the designs, codes,
and mistakes that your peers explain.

### Planning: Identifying Components, Specifying Interfaces

Describe the context. Identify the (tentative) line between the context and
the software system.

Describe use cases. Identify the lines between pieces of the software
system. 

Describe the context for each pieces. Identify the (tentative) line
crossings. Now you get to see the interface. 

Explicit descriptions of data representations and interface signatures
matter. Especially when you work in an untyped language (JS, Python), 

- write down your data representation 
  - don't use strings 
  - use dictionaries only for what they are good for 
  - there are many other "structures"; use where appropriate or make your own

- write down your signatures 
  - otherwise you can't read code 

- write down the commonalities in all detail: 
  - all data types (defs) 
  - all methods with all signatures 
  - all purpose statements 
  - contracts (informal) 
  - protocols (informal)

Terminology matters: player (the mechanics) vs strategy (the intelligence
 or logic). 

Consistency matters. 

### Program Design 

- Systematic Design 

  - systematic design is the key to saving time down the road 

  - F I: one task, one function 
    - example: the tournament manager performs two tasks: config, run tournament
    - example: the server performs three tasks: config, connect, dispatch to TM

  - F II: one task, one method; class hierarchies represent information as data
    - example: see above 
    - example: the hierarchy of players: 
      - super 
      - player and failing players
        - classes of failures

  - F III: one task, one component 
    - example 1: separate _all_ communications software from logic Remote
      vs Admin|Player|Common  

    - example 2: separate mechanics from goal-oriented logic 
      - Player/player
      - Player/strategy 

- Tests 
  - you need unit tests 
  - you need unit tests, even for methods that perform I/O 
  - you need system tests 
  - you need debugging tests 
  - you need regression tests 

- Abstraction 
  - functions (parametric abstraction) from F I
  - inheritance (indexed abstraction) from F II 
  Some languages allow mixture. Find out. Exploit, your life will get easier.

### Partnerships 

- Pair programming requires managing a person, without having managerial
  rights and powers. As you will find out, learning to manage someone else
  is critical, because you will always have to manage up your boss,
  manager, start-up owner, chief programmer, etc.

- Keep notes. 

### Design and Code Reviews 

- Accept criticism, embrace it. 

- You are a creator. In contrast to a conventional artist though (a person
  we typically think of as a creator), your creation has a very high chance
  of surviving and making money. 

- Let go of your creation. (Artists have to do so, too. Think of a poet. A
  poem is subject to interpretation, and many readers interpretations will
  differ from the poet's.) 

- When you explain code and ask for help, 
  
  - start with the context (often the most important) 
  - hone in on the critical points 
  - give readers time to digest 
  - don't ask them where to go because they don't know 
  - but follow their requests 

### Your Programming Language 

- superficial properties ("pretty syntax") are not key 
- the sheer number of packages on line are not key 

- it is key to know what your language's feature do (mean) 
- it is key to evaluate a language's capabilities (lambda, meta, annotations)
- it is key to evaluate a package's capabilities (JSON representation, I/O)
- it is key to get to know the most basic tools of your tool suite (telnet) 

### The End

- Keep learning. 

- You need to learn how to learn. (That's College's job.) 

- Good luck.