joemasteylearning.txt

Joe Mastey: (Effectively) building a (self-sustaining) culture of learning
@jmmastey
josephmastey.com

What he's working with is not people who are new to the field. He wants to get people over the course of their careers to get better at what they're doing. The fact that they start learning the algorithms early on is great, but you're supposed to be a better craftsman year after year.

About his company:
- Fast-paced in a good day
- Deadline driven in a less good way
- Dozens of Rails codebases from 1.2 to 4.2
- Hire lots of green developers
- Consumer financial products (!)

About him:
- Software engineer for 12 years
- Teacher for 0 years
- Still want to do lots of code
- Manager of Internal Learning at Enova

Why "Learning as you go" doesn't cut it:
	Picking up a bug and learning from it isn't the best way to do it. Because they pick up bad habits/code from your old codebase, among other problems.

Getting the reasons right:
- Attract amazing engineers
- Reduce attrition, especially of senior folks
- Increase 'bus factor' and cross-role knowledge
- Bring fresh ideas into the organization
- Reduce wasted effort and increase delivery speed

A non-exhaustive list of things that don't work
- "We really just need the CTo and the CEo to make this a priority" - Me, a long time ago (if you tell me to learn, then I'd learn and be good at my job). Shifting the responsibility onto someone else. 
- "We're dedicated to investing in our people, but we're really in a crunch right now"
	
	A learning culture in 3 phases
		- A caviat
			Your people are not my people, your culture is not my culture.
			There is no precise answer
		1. Building credibility
			What does it look like?
				- High resistance to the value of targeted learning
				- Individuals learning as part of their work
				- Disorganized training (usually by oral tradition)
				- One of a few folks driving learning efforts
			What worked
				- Don't wait for permission - take ownership of your company's culture
				- Think opportunistically and get some victories
				- Low time and effort investment, fast returns
				- Focus on improving people at their primary roles
				- Attend meetups
				- Cross-team code reviews
				- Open book policy
				- new hire buddies
				- internal blogging
				- lunch workshops
				- screencasts
				Open book buying policy:
					Idea: if you're willing to ask for the book, I'm willing to purchase multiple copies. 

					Tradeoffs: Making people ask seems to have eliminated abuse. Copies already waiting for you. Expensive...ish? People don't read about 50% of the books they ask for. 

				New hires buddies:
					Idea: Provide each new hire with an experienced technical and cultural helper. Make it someone from a different team.

					Tradeoffs: Awesome friendships between teams. Great pressure relief value. People with the right attitude for it are less common, which makes the time commitment high.

			Dangers!
				- Overcoming intertia is really tough
				- People have a fear of looking dumb
				- Low credibility (people latch onto failed attempts)

		2. Expanded Effort
			What does it look like?
				- New hires learn a lot, existing employees don't
				- People want to learn more, but don't feel empowered to take control
				- Some teams start to learn as a group
				- Small, somewhat organized onboarding
				- A small core of folks driving learning efforts

			What worked
				- Look ahead and start to anticipate needs
				- Opportunities that take a while to pay off start to be possible now
				- Broaden focus to cross-training engineers
				- Rope in more internal collaborators
				- Seed good role models around the department
				- host meetups
				- dedicated onboarding process
				- Half day internal workshops
				- Weekly tech talks
				- new hires as buddies
				- attend conferences

				Juniors as teachers/code reviewers:
				Idea: Have recent hires do code review for new hire training.

				Tradeoffs: Recent hires get even better at code and code review. Their pain tolerance is still low and they remember learning. Less organizational wisdom, less context. 

				Weekly tech talks:
				Idea: Fifteen minutes to talk about what's interesting to you right now. Four speakers per week. Same time, same place.

				Tradeoffs: Watching for one hour is a low commitment. Four new ideas spread to the org every week. People speaking is hard. People will start skipping if you're boring twice in a row. 

			Dangers!
				- Key personnel leaving now can be crippling
				- Perception of "wasting too much time" is a threat
				- Old guard may be too comfortable

		3. Shift the culture
			what does it look like?
				- People start to see learning as a normal part of everyone's job
				- Momentum and reputation start to sustain new learning efforts
				- Dedicated training for new *and* existing engineers
				- Active chaos of new ideas
			What worked
				- Make them forget that learning and teaching was ever not part of their job
				- Everyone in the department gets involved
				- Broaden focus to topics outside of software
				- We can try riskier things without destroying momentum
				- Dedicated training
				- FOSS contribution
				- Apprenticeships
				- Sabbaticals
				- Code spikes / 20% time/ exploration
				- Mentoring as a job requirement

				Dedicated training program:
				Idea; Provide roadmap, context, (tons of) resources, and verification for all the skills we want new hires to master

				Tradeoffs: Necessary for scaling while raising the bar on skills. Huge time commitment. We don't ship on day one. Candidate loves it, and it alleviates Imposter Syndrome.

				Apprenticeship program:
				Idea: Six month concentrated learning program for fantastic candidates who need more technical skills

				Tradeoffs: High time and attention cost. Huge reputation win. New amazing coworkers.

			Dangers!
				- Efforts with long-term payoffs are hard to measure, but their costs are immediately evident (you will always have to work hard to prove it's worth it)
				- Nobody feels personally responsible for pushing on the culture
				- Chaos needs some guard rails or it hurts everyone
				- Losing the learning habit (deadlines again!)

	A parting anecdote
		Between the time the talk was accepted and now, he quit Enova! 

		Please do something. If you're interested in learning more at work, pick something. Coffee and a book club

Tweet: "Cause your young people pain. Haha. Thanks @jmmastey -- I'm going to start encouraging a learning culture in my company! #mwrc"

learningstatistics.txt

John Paul Ashenfelter: Learning Statistics Will Save Your Life!

http://zedshaw.com/archive/programmers-need-to-learn-statistics-or-i-will-kill-them-all/

He wants to make sure we survive statistics. 
The things you will learn:
- Statistics
- How to compare things (it doesn't matter how pretty the code is. Faster is faster)
- One does not simply run an AB test. It's a lot more complicated than that
- If you're thinking about applying for jobs

"There are three kinds of lies: Lies, Damned Lies, and Statistics" - Mark Twain

Standard deviation
Baesian.

@johnashenfelter

mattclark.txt

Matt Clark: How and why of ruby
@winescout
Notch8: notch8.com
LEARN: learn.notch8.com

Craftsmanship analogies:

High fiving. It's a skill that you have to get better at. You have to figure out how to do it, you can pair high-five, you can do some test-driven high-fiving. You should be applying reasoning because there's a failing test.

Ruby holds your elbow. It's unique among the languages that people start programming in. 

There are 3 types of thinking, critical reasoning, evaluating arguments, analytical reasoning, and logical analysis.
When we talk about critical thinking in programming, we're usually talking about logical analysis.

Write an expectation
	Why did it fail?
		Fix problem.

Our habits define us.

SQL then AR

"Look at all the configurati'n I'm not writing"

Constraints

	Constraints are a way that we can get understanding of smaller components of the application without understanding the how or why.

meaningfulmentorship.txt

Mary Elizabeth Cutrali & Danny Glunz: Meaningful Mentorship
@marycutrali
@dannyglunz

Who are we?

What does a mentoring relationship look like?
	1. Phases
		Initiation
			Awkward phase where you get to know each other. We talk about ourselves and feelings/expectations for the relationship. Begin to identify each other as needing attention. What our hobbies and interests are, making sure that it's going to be a judgement-free relationship

		Cultivation
			The meat of the relationship. 2-5 months in bootcamps, much longer traditionally. You work on developing particular skills and developing you protegee 

		Separation

		Redefinition
	2. Habits
		Make a schedule

		Actually do work

		Show up prepared (don't be rude)

	3. Benefits
		Motivational

		Employee happiness



	4. Repeat

		The Mentee becomes the mentor

		You can mentor more than one person at a time. 

michaelries.txt

Michael Ries
@mmmries

Distributed System?
	Made of multiple applications working together

	MX is working on a distributed system. 

	Make a directory
	Publish events
	something something changes


Sample Project
	When a user is deleted, we will cleanup their data

	The directory
		Easily navigable by humans
		Used by production code

	Atlas - The Directory
		Protobuf (data exchange format developers.google.com/protocol-buffers/)
		Map resources to applications
		Private gem

		Message Schema Migrations
			Backwards compatible changes
			Deprecations => Backwards incompatible changes
			(you want to have some kind of deprecation lifecycle)

		Navigable by Team Members
		Used by production code

	Events
		Low Coupling
		Similar to Controller

		When a user gets deleted, we want to make sure other services know about it. The user model shouldn't have to know about the other models, it just wants us to delete the user and other data.

		Stick in rabbitmq. What should amigo really be responsible for? It needs to knwo that if we delete the user, it will trigger something. We're trying to use restful-ish sort of names. 

		Now that Amigo has sent the message, the other applications are going to receive the message. We want some kind of opt-in system as the application goes. You can create the list of who cares about what.

		If firefly doesn't care about users being deleted, it won't get a copy of the message.

		In production, we're not going to have just one instance, we just need to send one instance of Abacus (for example) the message that it's asked for.

		The other thing we don't want to do, is re-implement re-connecting to rabbitmq 18 times. Let's use action_subscriber !


		class UserSubscriber < ActionSubscriber::Base

			def deleted
				user = payload # Atlas::Amigo::User
				delete_accounts_for_user(user.guid)
			end

		end

		class User < ActiveRecord::Base
			include ActionPublisher::Syncable

			... other code ...
		end

		Events
			Low coupling
			Similar to Controller
			Opt-in to messages
			1 message per application

			First we have to make sure Amigo is publishing events we care about
			Then we have to make sure each application receives the message (as appropriate) and do the actions that's necessary

		4 tasks??
			Cohesive Code
			Code Review
			Deploys Overhead

			Deployment costs:
				Developer time
				Developer interruption
				System downtime


			Trebuchet
				Extension to capistrano
				Deploy 1-by-1
				Deploy in groups

			Deploy Small Changes
				Cohesive codebases
				Automate deploys
				Minimize Cost (interruption/time)
				Minimize Risk
				Code Review++


	Make a directory
	Publish events
	Deploy small changes

	Team >> Tech
		Shared ownership
		Teaching / Learning
		Discipline


	End

Replicating the entire system is unfeasable. Stand up a sandbox environment. Your local machine will be talking RPC to this sandbox environment.


	Tweet:

	Thanks for the talk @mmmries! I'm going to develop some kind of distributed system as a side project! #mwrc Also, hockey is funny!

paulhinze.txt

Paul Hinze: Smoke and Mirrors- The Primitives of High Availability
@phinze

Abstraction
	For his money, this is the most important concept in computer science. "Strategic lying" -- The use of simplifying metaphors to manage complexity.

	Abstrahere-- to draw away
	"Don't look over there, look over here." "don't worry about that, just worry about this"

	The internet: abstraction in action
		Let's say you pull up github in your browser. There's a lot happening when you do that, in a way that you don't have to think about it.

		He talked about a lot of shit here, TCP, BGP, etc etc.

	High Availability
		You're facing chaos head-on and saying 'i can react to these things'

		How do we attack chaos?
			Failure happens
				Anticipate
				Prepare
				React

				What could fail?
				What should we do when it fails?
				What did we learn?

	Primitives
		Treat many as one

		Hardware Components Fail
			the modern server is a great case study in redundancy. 

			Servers fail
				"What happens if the server craters?"
				How do we implement the redundancy 

richochetrobots.txt

Randy Coulman: Solving Ricochet Robots

@randycoulman

@codingzeal

Why graphcs, trees, and algorithms?

	Hierical structures.

	Relationsihp maps: Social networks like linked and facebook
	Network routing

What is ricochet robots?

Game that you move robots around and try to hit a target.

Characterizing the problem:

LOTS of possible moves
Branching factor: 9-20 possible moves from each state
The board is always fixed. 16x16

Walls and targets: changes each game

Goal: Changes each turn

Robot positions: changes each move

Representing robot movement:
	The board states are the nodes of the tree and each robot movement is a path to a node

Trees: Every node has only one parent and any number of children.

Search Algorithms:

Jamis Buck's book: Basil and Fabian: Three Ways Through

Depth-first search:

	Cycles:
		Keep track of all the board states we've seen before and not process those again? That doesn't work because we eliminate shortest-path solutions and the tree ends up becoming a graph. 

		Also, a cycle can end up becoming the shortest path to a solution because the robots have to ricochet first

Breadth-first earch:

	Look at each combination to see whether or not the next move has solved the issue. This method is nice because it will always find the shortest solution

	Global visited list works now, we don't have to process states multiple times like we do with depth-first.


Optimization:

1. Do less things: reduce the size of search
2. Do things faster: Less work per state
3. Heuristics: Rules of Thumb
	Less certain; may work in soem circumstances, but not others. 

	Let's heuristically move the active robot first. 


	Do less things: Check for solutions at generation time. If I had a solution at node 16, I'd have to check all 16 nodes first. Checking at generation was almost a factor of 3 improvement. 

	After writing a profiler, most of the time was being spent checking where a robot could stop. Started precomputing stopping cells.

	Another talk said there are some board states that are equivalent. If I'm solving for a single robot, I don't care about the position of the other robots. Treat non-active robots as equivalent.

	Sorted arrays vs set --- arrays are faster.

	Creating a lot of unnecessary objects. I stopped creating new states when the robot wasn't actually moving. 

	Using object identity instead of deep equality was also significantly faster. 


Further optimizations:
	A* Algorithm

	Next state to expand is one with minimum distance so far + estimated distance to goal
	-- You'd have to come up with some way to estimate how far there is to go
	-- If the robots could stop anywhere they wanted to, how far would it take to get to the goal?
	--- Discriminates between how many moves it thinks 

	Better algorithms:

	Collision detection
	Work backwards


	Better heuristics?
	 Somecombinaton of active robot and most recently used
	 Sort movement directions intelligently

	Pre-compute per robot stopping positions
	Use less objects and more primitive types?
	Parallelism


Michael Fogleman for some optimization ideas. 

ryandavis.txt

Ryan Davis, Seattle.rb: Standing on the Shoulders of Giants
@the_zenspid

A history talk, ideas, survey, inspiration. 109 slides. 

900 years ago, Bernard says "We (the moderns) are like dwarves perched on the shoulders of giants and thus we are able to see more and farther".

If I have seen further, it is by standing on the shoulders of giants.

Not a new concept. Every idea we've had, built upon the ideas before them.
When we create a language, why do we build anew more often than not?
Ruby:
- Created by matx in 1993
- Interpreted, file-based 'scripting' system
- Purely OO class-based runtime
- incredibly complex syntax & semantics
- Exensive class library, numeric tower, etc.
- Designed for 'developer happiness'

Fibonacci:

class Integer
	def fib
		self < 2? self: (self-1).fib + (self-2).fib
	end
end

Ruby history:
- Large gap between 1.8 & 2.0 (4 years).

Not much added since 1.0
- Private/Protected

Ruby is a fantastic language, but it could be better.
Has done a great job of taking languages from smalltalk, lisp, perl
Smalltalk- Dan Ingalls
Self - David Under
Scheme/Racket
FONC/COLA

Smalltalk:
- Created in 1972
- Bytecode compiled image-based system
- Purely object-oriented class-based runtime
- incredibly simple/clean syntax and semantics. Only 6 keywords, 4 precedence levels.
- Fully immersive dev environment
- incubator for ideas, this is where many ideas of OO, patterns, mcv, etc came from.
- WAY ahead of its time, still is in some ways

Self:
- Bitecode compiled + JIT image-based system.
- 8 bytecodes
- Classless
- Java hotspot was born here

Scheme & Racket:
- Racket is a type of scheme
- Scheme is a minimal variant of a lexically-scoped Lisp
- Lisp is a functional language based on lists
- Innovation galore: tail call optimizations, numeric tower, hygenic macros, 1st class continuations, etc.

Racket:

- Racket is a maximal variant of Scheme. Huge, incredibly-diverse library.
- Bytecode compiled + JIT file-based system
- Mostly functional multi-language runtime
- Ships with Editor and Runtime

VPRI:

- Viewpoints Research Institute
- 5 year NSF grant to work on FONC: Foundations of new computing
- They want a whole system that can be understood by one brain

COLA:

- Machine-compiled file-based system
- OO prototype-based runtime
- COLA = COmbined Object/Lambda Architecture
- "Designed to be the simplest possible language which can be described in itself"


Xerox is really good at inventing but terrible at selling
Squeat Smalltalk generates and builds itself. 
They decided they disliked coding in C, so they re-wrote the runtime in squeak in an analyzable subset that translated to C.
Lowers the bar for anyone to understand what the runtime is doing, increases the contributor base and increases work on the runtime itself.

Smalltalk has a huge class library. 

Smalltalk is one of the groups that is all about unit tests. When a smalltalk test fails, the debugger pops up.

You write the code in the debugger, repeat until all your tests pass.

Ideas from Self:

	Self is different. There's more of a focus on the runtime than on the language itself
	Birthplace of JIT
	Self is the reason why java and javascript is fast
	Prototyping (classless OO) really started in Self
	This wound up influcing JS and languages like IO
	Prototyping is really handy! Since 1.9 we've been able to add instances to other classes
	Developer tools!!
	Self has a GUI right out of the box. It has an emphasis on the language itself.

Ideas from Scheme and Racket:

	Racket ships with extensive documentation
	Reference, steam-constructor methods, a newbie-friendly guide.
	As much as we've improved all of our documentation in Ruby, Racket's documentation simply puts ours to shame.
	Racket ships with an IDA that's oriented to beginners. It was originally designed to teach high-schoolers how to code.
	There's a REPL integrated and you can even display generated images.
	Documentation is integrated in the IDE
	Structural Pattern Matching
	We don't have the types of things they have in Racket and we're held back as a result
	Racket has multiple language support and they all work together.
	Lambda is king. 
	We need to speed up our method calls by 4-8 times to compete on more than just python/perl field that we're on

	Tail call optimization

Ideas from COLA:
	OMeta: Translators all the way down
	Define your system using basic axioms
	Teach the GUI Euclid's geometry and give it a rule engine rather than giving it a huge library to do GUI work.
	650 kloc gtk GUI library < Rules + Euclid in ~250 LOC
	Runtime ends up being much smaller, more understandable, and more maintainable.
	

Tweet:

Listening to Ryan Davis talk about Smalltalk, COLA, Racket, etc. Seems like we're lacking in the area of built-in developer tools! Thanks for the talk @the_zenspid