I’m at SCNA today, and so far it’s pretty great. I know this post is short but I plan on eventually cleaning up my notes and posting them here later today or tomorrow. I promise!

*edit* As promised, here are my notes (maybe, just maybe I’ll write up a summary… later).

George Leonard - Mastery (Book)

Ken Auer - Swimming Upstream, ...
  Does a fish know he's wet?
  Google: "Sutherland Sketchpad"
          "intrapreneurs"
  Home schoolers vs Classroom schoolers
    apprenticeships
  Staying home everyday leaves you less challenged
    Leaving home everyday leaves your family less challenged
  rolemodelstudios.com <= family project/business
  integrated life - large home for family, extended family, and work
  Pragmatic Programmer
    Learn to Program (Yellow Belt)
    Agile Wed Dev w/Rails (Black Belt)

Michael Feathers - Self Education and the Crafstman
  Big O / Little O / Theta Notation
  Covariance & Contra-variance - substitutability
  Types - not just language constructs
  State Machines - the forgotten diagram
  Turing Machines
  The Halting Problem - limits on verifiability (?)
  Worse is Better - simplified design is easier to debug (but has less features)
  Redundancy is not Strength - reinforce a bridge
    the same specs to different teams produces a correlation in the bugs from each team
    "things only fall apart when we touch the code"
  Security on Sand - On Trusting Trust (paper)
  Location Transparency is a Myth
  Books - "Cool stuff to know"
    SICP - Structure and Interpretation of Computer Programs (http://mitpress.mit.edu)
    Syntropy - Designing Object Systems - Steve Cook & John Daniels
    Graph Theory - Graphs: Theory and Algorithms
    Compilers, Principles, Techniques and Tools
    Discrete Mathematics with Combinatorics - James A. Anderson
    Theory of Computation - Michael Sipser

Christopher Avery - Demonstrating Responsibility: The Mindset of -an Agile Leader- Crafstmanship
  Involved w/Agile ~ 2004 - Accidental Expert
  How You Respond to a Problem
    Who did this? Who's responsible?
    That doesn't happen when things go well
  How many time a day do things go wrong (people not attending meetings, or replying to emails)
  Problem => Denial => Lay Blame => Justify => Shame => Obligation => Responsibility
  Lay Blame - pointing fingers (humans do it and are good at it, coping mechanism)
    "You can get stuck there, or you can get off of it" - C. Avery
    Cause / Effect scenario
  Obligation - transient mindset, have to do it, don't want to, but we have no choice
  Responsibility only happens when you refuse to accept obligation
  Quit (transient mental state) can come between shame / obligation
    you've checked out because you refuse to accept responsibility
  Highly engaged customers predict revenue/stock/etc. increases
    only thru highly engaged employees is this possible
  Intention - the winning key
  Awareness - the change key
  Confront - the truth key

Jim Weirich - Grand Unified Theory of Software Design
  Way more than 4 forces in the software universe
    SOLID, Law of Demeter, DRY, Small Methods, Design by Contract, etc.
  Sheldon Jordan - RCA Missile Test Project - mentor to J. Weirich
    Composite Structured Design - Book
      Coupling & Cohesion
        Coupling - (less) None, Data, Stamp, Control, External, Common, Content (more)
  Connascence - 2 pieces of software share connascence when a change in one requires a corresponding change in the other
  Connascence of Name
  Connascence of Position
    Generally good to move from CoP to CoN (array vs hash)
  Connascence of Meaning (ex. 1 = true, 2 = false)
    use a constant to convert to CoN
  Connascence of Algorithm
    use DRY to convert to CoN
  Connascence of Timing (Race Condition) - Threading
    mutex's can protect against this problem
  Connascence of Execution - ordering of steps in an algorithm are important
  Connascence of Identity - duplicate objects (2 sql queries for the same object, AR::Base problem, DataMapper solves this with an identity map)
  Connascence of Value

Ward Cunningham - What if Bacteria Designed Computers?
  Dorkbot
  Invented his own wire protocol called Bynase
  Arduinos are the future
  Uses random numbers and electronic "noise" to communicate between processors

Dave Hoover / Paul Pagel - Apprenticing to Mastery
  Apprenticeship is the only way to achieve mastery
  Picaso wasnt a child genius, he apprenticed
  Open source projects are a great way to learn
  Great programming books generally dont have the name of a language in their title
  A master must also be a good teacher
    intuition is great, but without articulation it's not helpful

Bobby Norton - Test Driven Learning
  Start small, dont take on to much at once
  apprenticeship patterns, walk the long road
  Novice, Advanced Beginner, Competent, Proficient, Expert
  Experts adapt, create and advance the practice
    work from intuition, not reason
    don't need rules
    github.com/bobbyno/shubox

Bob Martin - Craftsmanship Under Pressure
  Holy shit, thermodynamics and crazy astrophysics
  The universe appears to defy the law of conservation of energy
  Estimation -> Manage Expectations
  QA shouldn't find any bugs
  close to 100% code coverage (I don't agree)
  dogmatic about TDD
  Changing code makes it changeable
    each refactoring strips out hard to change areas with better versions
  boy scout rule - leave it cleaner than you found it
  time between writing code and tests should be very very small (or negative: TDD)
  one week of overtime is ok, but 2 months is not
    you will do harm to your code, become complacent and stop caring
  professionals know how to have an uncomfortable discussion (ex: slipping release date or change in scope)
  "when i feel pressure i slow down"
  professionals have a work ethic
    not coding for their own joy (that should be a secret)
    will work for our employer to deliver value
    40hrs are the property of your employer (or customer)
      employer is not responsible for your education (books, conferences, etc.) if they do it's very nice
  "The core of this craftsmanship movement is developers taking responsibility for their own career"
  You should be able to list ALL the design patters, it's your profession!
  You should know many languages, only knowing 1 is a problem
  There is a lot of information that has been accumulated over the decades that you should know, it's your profession!
  Read the works of David Parnis (sp?) and his tables to describe how systems work
  Why can't anyone in this room write quick sort out of their head
  Continuous Learning - our profession has a tendency for the individuals to never stop learning
    we live to learn, and love to learn (at least we should)
  Jugglers and Musicians are over represented in SE's
    both take time to learn and master, but we love to learn
  Step outside your comfort zone
    language and methods included!
    broaden your zone

More notes to come at Octavity from a fellow attendee.