Ted's notes (@thesleepyvegan)

Twitternets: #roa2016

Mike Moore (@blowmage) Slides

• model of mastery
• rubocop (or similar) helps resolve disputes about style easily
• the box: experiencing other people or circumstances as having more power over other people than we do
• get good at working remote
• most important point: truthful honest assessment of yourself and your abilities

André Arkin (@indirect) Code

• inclusivity is more important than diversity
• illusion of a meritocracy
• not a pipeline problem
• if your reason for diversity isn’t to include people, you will never get it. economic arguments for it teeter on exploitation
• including people is an attitude and philosophy of (social) interaction

How to include end users:

• code of conduct — great example is contributor covenant. create a safe space for people
• documentation — write docs aimed at newcomers. use she/they for your pronouns. https://jacobian.org/writing/great-documentation/ tutorials, topic guides, an API reference (useless for newcomers!), troubleshooting docs. links to docs in error messages
• accept issue reports gracefully — huge indicator of how inclusive your project is. start with the idea whatever the reporter says makes sense to that person.
• if you have a support org, be as accepting and open of bugs coming from support to engineers as they are the voice of your users * listen and speak respectfully. anyone representing your project should not harass or be condescending. enforce code of conduct on everyone regardless of how invaluable that jerk is

Including contributors:

• ask people for help in order to include them. contributors do not need to be an expert to help! maintainers especially need newcomer perspectives to understand how to help.
• as a maintainer, be open and honest about what's hard. André mentioned spending first two weeks on Bundler saying "what?! how?! why?!"
• pairing with contributors!
• write developer documentation. TOTALLY DIFFERENT from end user docs. how to get started contributing, how to run tests, criteria for accepting PRs, how to contact people, write a release guide, etc. every project should list things they welcome, eg, typo fixes welcome!
• pull requests are just issues with work done for you. if you need to reject a PR, be gracious: "thank you, i want to understand this and know how to solve your problem in a way that works for everyone"

Apply all of the contributor guidelines to team members. Give positive feedback and ask for help when you need it.

Underlyng principle: respect and empathy. Thinking about how you'd like to be treated is not enough. Think about the context those people are in and what they're struggling with.

Tech is a biased field and only the people in tech can change it!

Tobi Lehman (@habitmelon)

• Lots of physics, math and geometry stuff I don’t understand 😳
• Vectors, real numbers 🔢
• Distance between vectors represents points in space
• Given a model of objects in space, we can write some ruby code as below:

class Vector
  att_reader :components

  def initialize(components)
    @components = components
  end

  def +(vector)
    sums = components.zip(vecotr.components.map{||vi, wi| vi+wi })
    Vector.new(sums)
  end

  def *(scalar)
    Vector.new(components.map{|c| scalar*c})
  end

  def ==(vector)
    components == vector.components
  end

  def dot(vector)
    # some science
  end
end

class Body
  def force_from(body)
    rvec = body.position - position
    # .. more code that looked pretty straightforward -- yay readable :ruby: :smiley_cat:
  end
end

def Universe
  def evolve(dt)
    # about 10 lines of readable :ruby: with some physics math :memo:
  end
end

General physics:

• Summations? -- at least some math sigma stuff
• Newton's law of universal gravitation -- a vector from a body at position j to body at position i
• In gravity, all that matters is the total mass and the center of that mass -- not radius or shape. Even if the sun were a black hole or a singular point of mass, all planetary orbits would remain the same. It could even be a hot dog or a meatball (THANKS JONAN FOR THE MEAT THEME).
• Centripetal acceleration between bodies

UI for seeing this:

• Ruby with websockets pushing physics states to browser with window.requestAnimationFrame to render.
• Super cool animation!
• Newtonian::DimensionError that we 200+-pair programmed through!
• Highly symmetrical examples that are cool to study -- rarely occuring in nature
• Three-body example of planets juggling each other! Super cool!

Summary of physics after Newton -- moving to general relativity and quantum mechanics

Ryan Davis (@the_zenspider) Code

• Never compare floats for equality -- use a constant for 'close enough' and compare within that (assert_in_delta)
• Avoid leaky tests that infect results -- variables mutated within testing
• Use local variables within tests to avoid sharing state between tests
• Use classes to make writing tests easier
• When a test fails, in a naive test runner, the runner quits, so you only see the first problem that occurs; rescue and print what happened.
• Don't show the whole backtrace
• Make sure run returns self. Also, an explicit return is needed from a begin/ensure block to ensure you get the right value.
• shuffle tests for nice randomization and to ensure there aren't test ordering issues
• Done > Good.
• 70 ~LOC.
• A book about this may be forthcoming! :D
• Dr Seuss font!
• Lots of goddamn meat pictures of stuff he cooked
• Better reporting -- next feature he would implement. Abstract reporter for multiple reporters and CI integration, then plugins afterward. More assertions too.

Aja Hammerly (@thagomizer_rb)

Lots of dinosaurs! And kitten pictures!

Why do self-teach and how?

• The ferret point: getting bored.
• Whatever we learned is insufficient. We need to learn new things. This makes it fun!
• "Lifelong Learning" -- tech and elementary school slogan
• Learning a little bit about C so you can say "Yes I understand pointers and I still don't care" was one of the most important things in her career
• Learn the "Thinky stuff" -- programming paradigms (OO, FP, declarative, logic) and database types (relational, object, document)
• Build a scaffold from paradigms and abstract principles

How to do it!

• MOOCs (udemy, coursera, universities, etc) provide structure and lots of free help. Big MOOCs tend to have higher quality. Downsides: sometimes $$, feels like school. Read the syllabus first! Avoid being a guinea pig in a first run of a MOOC
• Set aside a time for learning.
• Study groups: in person accountability and friends. If you don't have friends this is hard. Meet every week. More details from Ryan Davis' Nerd Party 3.1 talk. People who didn't do their homework had to cook for the people in the group ("penance work"). Keep it small -- six-ish people.
• Games and puzzles: Rosalind, Project Euler, Exercism. Rosalind is bioinformtics problems and they build on each other so time for refactoring. Easy to schedule this in, satisfaction from finishing work. Similar to interview questions -- helps training for interviews! Big tech company interviews are like this Consider a local competition to encourage puzzle participation with prizes
• Books: exercises and short chapters are nice. Aja's favorite books in this picture

Giving a talk is a great way to learn a topic! Aja give a talk about Prolog at Cascadia Ruby Conf.

• Standing on a stage forces you to finish
• Provides more opportunities from demonstrated competency -- jobs, consulting, more talks
• Bad thing: deadlines and pressure. Give yourself a couple months to write it and have a plan.
• Pick a topic you are willing to learn about.
• Do NOT propose a talk you do not want to give!
• Keep your proposal and abstract simple -- 101/102 level of advanced beginner level has highest reach. Audiences want to hear 80% of material they know.

Not finishing != failure. You still learned a lot! Do not feel bad if it does not see if your work light of day

Learning things at work

• Hackathon thing at work. Inspiration time. FedEx day. Inspovation.
• Prototyping. Timebox so managers will say yes. Do not say "I want time to learn xyz." Say "I want z time to prototype solving x problem"
• Internal apps give you freedom to try new things. This helped Aja a lot in her career.
• Testing at a higher level than unit. Content generation? Integration? Load testing? Code is often throwaway.
• Own your time doing this by saying "this is why it helps me be better and more productive." Don't make excuses to your boss because the time learning is worth it.

Find an accountabilibuddy! Accept setbacks!

Allison McMillan (@allie_p)

Having a kid is overwhelming like learning to code. There are many parallels:

• Googling stuff when you don't understand. Learning to skim through results.
• There is no stack overflow for being a parent
• Earned dogmatism when people feel like they are experts. For example: "Don't let your child cry it out" "Practice TDD" "Anything other than breastfeeding is terrible."
• Debugging
• Tempermental
• Pairing is encouraged

Struggles in both:

• "How do you keep doing it while learning, being a great mom, great employee and at least an adequate wife?"
• Parents struggle to keep up in an industry that values a GitHub resume, keeping up on latest developments, etc
• Such a busy schedule for parents that there isn't time to build the things you need for a new job
• Not having an impressive GitHub, side projects or code from your job you can show is hard
• Without the things above, in an interview, you have to rely on your code challenge. This takes time away from your family and is very difficult for parents.
• Single parents have it even harder
• Attending community events is very hard for parents to make the time -- and possible cost for babysitting
• The lack of sleep from parenting can make it hard to focus on code during the day
• Mothers often run into scheduling issues with hard stops/starts due to child care
• In a survey, no fathers said it had hurt their career -- only helped or neutral effect. One father said it built empathy and helped with client relationships
• In the same survey, one third of mothers said having a child hurt their career.
• Parents took significant time off work. From a survey, little concern about difficulty among senior technologists reentering the work force. This is a huge privilege we should recognize.

Hugely insufficient parental leave:

• No mandatory leave in US.
• Maternity: four weeks can be common but it's still super difficult, evne for an uneventful birth.
• Paternity: two weeks is common. This places an even larger burden on mothers.
• When making policies, think about whether you want parents back who aren't ready to be there
• Pumping can take 32-34 minutes including cleaning, travel time to room for pumping
• If there are women pumping in the bathroom, seriously consider how you prioritize women in the workforce.
• WFH and partial transition (part time) can help a lot. Partial transition makes an enormous difference. Same for schedule flexibility.

Solutions (many targeted at employers):

• Parental leave (paragraph above)
• Parenting slack channel can help and is super easy
• Parent groups at work to connect new parents with those who've taken leave and returned -- safe space for discussion
• Train managers on what to expect when new parents come back to work -- for many managers, it's the first time they've had to help. Lots of quotes about bosses being a big part of success when returning to work.
• Realistic expectations. Recognize KPIs/goals need to be revisited when parents return. New goals need to be realistic and will likely be less ambitious.
• Nice mother's room with comfy chair, fridge, power, fridge
• For new parents: get rid of parent guilt. Don't feel bad when you do something you love. Not everything can be perfect.
• Emoji for being away for pumping (🍼💪) so people know when/why you're gone
• Lightning talk about what it's like to be a new parent built empathy and helped colleagues understand
• If you need to leave your company, leave your company. If companies treat parents well, employees won't leave. All survey respondents who said companies cared about work/life balance said they wouldn't leave soon. Most who reported issues had already left the job where they had children. (Admittedly, most survey respondents were senior engineers who have more flexibility.)

Struggles are not unique. People need to face that and admit it.

Parents: high fives ✋

Advice for people who work from home:

• Separate space with a door for working
• Child care

Anyone who wants to take the survey should tweet at Allison @allie_p -- it's just five questions

Justin Searls

Why the hate?

• You write tests because you need stuff to work and trust.
• Tests get slow and become a burden. Teams become slaves to their builds and tests.
• An ounce of prevention is worth a pound of cure.
• Work Harder Comrade isn't the right approach
• Testing is always job #2. Shipping is #1. This impedence mismatch is an issue.
• Move your crappy tests to an old folder and create a new awesome tests folder

Important parts of testing:

• Structure
• Isolation - communicates concepts of what you're doing
• Feedback - are tests happy or sad, fast or slow?

Big objects: Lots of branches. Lots of depenencies. Lots of complexity

Rule of product. A method like valid(a,b,c,d) means we have abc*d number of combinations, so if it's boolean, 16 test cases.

Testing makes writing big objects harder to deal with. Stop adding on to big objects. Justin's approach: Limit every object to 1 public method and at most 3 dependencies. Lots of small objects.

How will we deal with all of these well-organized, comprehensible small things?!?! It's okay to program in easy mode.

Always use given/when/then or similar stanzas so it's easy to skim tests to see structure. rspec-given by Jim Weirich. It's been ported to minitest, jasmine, mocha and lots of places. Very easy to read and point out superfluous code. Too many givens mean too many dependencies. Too many whens mean your API could be simpler. Too many then means your code is doing too much or you're breaking the command separation idea.

Logic in tests is bad. if/when/etc have issues. Who tests the tests?

Sometimes tests that need to be DRYed up point to non-test code that also needs to be DRYed up.

Sandi Metz qquint test: How are things organized? Can I tell what's under test? Lexically are things organized in the same order as the non-test code?

Tradeoffs of a big test library like rspec vs simple test suite with your own helpers.

Naming conventions: always name the thing under test subject and the expected thing results. When there's no consistency, it makes it easier to see what parts of the code deserve more attention and are special snowflakes.

Test data should be minimal and meaningful.

Create separate tests suites for all of the different kinds of things we have in our system. Whole talk about this Justin gave, Breaking up with your Test Suite: https://www.youtube.com/watch?v=vkAfGHd7sZY

Isolation:

• What level to test? suggestion: test at highest level with real data and test at lowest level with all collaborator interactions stubbed
• Too realistic
• Outside in and mocking http://is.gd/discovery_testing
• Careless mocking can be terrible. Don't go too far because it confuses tests and makes things very hard.
• Deciding when to test within the framework and not is a hard choice

Test feedback:

• "Assertion failed" is a terrible piece of feedback. You have to read test and debug to figure it out. Use better assertions. Ideally you can figure out the problem just by looking at the test failure output.
• Slow feedback loops are difficult. Every second you spend waiting for tests or deciding what to do means you have less you can get done in that day. Non-code and distraction time multiplies when tests are slowest, so the effect compounds.
• Data setup is often the biggest obstacle. You can have different test data strategies to get better feedback.
• Test times and builds can fly off the rails easily and turn into a geometric curve. This happens a ton 📈

Question: for lowest level of testing, isolate unless 'pure function' -- do you have any additional thoughts about testing specific to functional programming?