965 lines
37 KiB
Org Mode
965 lines
37 KiB
Org Mode
|
#+TITLE: Abstractions II
|
|||
|
#+OPTIONS: prop:("Speaker" "Twitter" "Email" "Slides") num:nil
|
|||
|
#+STARTUP: indent
|
|||
|
#+COLUMNS: %20ITEM %Speaker %Slides
|
|||
|
|
|||
|
* Day One
|
|||
|
|
|||
|
** Kill All Mutants
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Dave Aronson
|
|||
|
:Slides: https://bit.ly/kill-mutants-abstractions-2019
|
|||
|
:END:
|
|||
|
- Mutation testing
|
|||
|
- mutates code with the goal of generating test failures
|
|||
|
- checks for meaningful code and strict tests
|
|||
|
- each change to our code should make at least one test fail
|
|||
|
- at least one unit test failing on a mutation is "killing the mutant"
|
|||
|
- First proposed in Richard Lipton's "Fault Diagnoses of computer
|
|||
|
programs" (1971)
|
|||
|
- Difficult to interpret results, and very CPU intensive
|
|||
|
- Python - cosmic-ray, mutmut, xmutant
|
|||
|
- JS - stryker
|
|||
|
|
|||
|
** Maintaining a Legacy [[file:20200711113241-haskell.org][Haskell]] App as Not-Yet-Experts
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Libby Horacek
|
|||
|
:Slides: https://slides.com/emhoracek/haskell-24
|
|||
|
:END:
|
|||
|
- Migrated from a haskell app in in frames within wordpress to a
|
|||
|
haskell app serving wordpress content via the wordpress api
|
|||
|
- The "Genius-Oh-No Cycle"
|
|||
|
- Chesterton's Fence
|
|||
|
- Understand why a thing is the way it is before you try to change
|
|||
|
it
|
|||
|
- ~3% of functional programmers are women
|
|||
|
- Things that helped
|
|||
|
- [[file:20200711113447-pair_programming.org][Pair programming]]
|
|||
|
- [[file:20200711113336-tdd.org][TDD]] (invert the cycle)
|
|||
|
- RFCs
|
|||
|
- Can be totally casual
|
|||
|
- Sketch out a larger idea and ask for input from the team
|
|||
|
|
|||
|
** Measuring the Human Impact of Software Best Practices: A Story of CSS and Empathy
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: jnf
|
|||
|
:Twitter: @_jnf
|
|||
|
:Slides: https://speakerdeck.com/jnf/measuring-the-human-impact-of-software-best-practices-a-story-of-css-and-empathy
|
|||
|
:END:
|
|||
|
- "The Tyranny of Pay-as-you-go Internet"
|
|||
|
- Worked at Mighty Ai (training data as a service), acquired by Uber
|
|||
|
- Stuff in the talk happened before Uber
|
|||
|
- microaggressions and microaffirmations
|
|||
|
- "you guys" vs. (friends, folks, participants, peeps, illustrious
|
|||
|
heroes, party people, yinz)
|
|||
|
- microaffirmations, a guide
|
|||
|
- https://brown.edu/sheridan/microaggressions-and-micro-affirmations-0
|
|||
|
- active listening
|
|||
|
- recognizing and validating experiences
|
|||
|
- affirming emotional reactions
|
|||
|
- micro-tasks in a webapp to generate vector images
|
|||
|
- $0.03 to $0.05 USD
|
|||
|
- Large base in Venezuela
|
|||
|
- community members raised concerns about data transfer
|
|||
|
- forgot ota internet was paid by the megabyte
|
|||
|
- didn't know the ost per megabyte
|
|||
|
- didn't know there was such flux in data access costs
|
|||
|
- asked them to take a literal loss in order to participate in the
|
|||
|
beta test
|
|||
|
- *I assumed an experience largely consistent with my own*
|
|||
|
- CSS is a /tax/
|
|||
|
- 1.3MB of css vs 34KB after refactoring
|
|||
|
- Movistar pricing: 0 MB included, each MB is $5 (5,00 Bs (bolivars))
|
|||
|
- 92 deployments, only 9 changed the CSS, every one of them
|
|||
|
re-generated the bundle and busted the cache
|
|||
|
- 8 downloads @ 1.3MB (52Bs) instead of 2 at 34KB (0.34Bs) /just
|
|||
|
for CSS/
|
|||
|
- This is an /ethical/ issue
|
|||
|
- ask, listen, believe, then act
|
|||
|
** “Testing” - You Keep Using that Word, but I Don’t Think It Means What You Think It Means!
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Samuel Brown
|
|||
|
:Twitter: @SamuelBrownIV
|
|||
|
:Slides: https://bit.ly/testabstract
|
|||
|
:END:
|
|||
|
|
|||
|
- Testing is generally re-defined by every organization to fit their
|
|||
|
culture and needs
|
|||
|
- Easy to explain why an acceptance test works, harder to explain what
|
|||
|
the utility is that you get out of a unit test
|
|||
|
- An opinionated view of testing
|
|||
|
- *automated* testing is the single biggest factor in determining
|
|||
|
how fast you can ship code
|
|||
|
- You have to build up tests in layers and spend time in the right
|
|||
|
places
|
|||
|
- Teams that test write code with better structure focused on
|
|||
|
interfaces and low cyclomatic complexity
|
|||
|
- Pit of Despair - AKA "Test Environment"
|
|||
|
- Don't want to be dependent on the state of the environment to test
|
|||
|
that your code works
|
|||
|
- Useful for UI/UX exploratory testing, load testing, deployment
|
|||
|
testing
|
|||
|
- What can we do
|
|||
|
- Unit tests :: Test the smallest units at the function/method level
|
|||
|
- Integration/Component tests :: testing the composition of *two*
|
|||
|
functional units or external dependencies that achieve a larger
|
|||
|
operational function (*reduce* the number of variables, not
|
|||
|
*increase*)
|
|||
|
- E2E/Acceptance/UI/API Tests :: Testing features with all required
|
|||
|
components integrated together /but some can be mocked/
|
|||
|
- Test Pyramid
|
|||
|
- low cost, fast run vs high cost, slow run
|
|||
|
- automated unit, automated integration, automated ui/api, manual ui/api
|
|||
|
- Fun tests
|
|||
|
- Writing good tests can be as challenging as writing good code
|
|||
|
- You will write more (2-3x) test code than feature code
|
|||
|
- Testing can be cathartic
|
|||
|
- Strategies for testing
|
|||
|
- Legacy code by Michael Feathers
|
|||
|
- Consider frameworks and libraries that lend themselves well to testing
|
|||
|
- Findexamples for what you want to do
|
|||
|
- Keep functions small and purpose-built - If it is hard to test,
|
|||
|
it's probably too big!
|
|||
|
- Limit conditional logic in a single function to 3 levels at most
|
|||
|
- Test ALL error conditions respond as expected
|
|||
|
- Use stubs, mcks and test doubles to simulate expected inputs and outputs
|
|||
|
- Limit integration/component tests to two actors (mocks for all others)
|
|||
|
- Create interfaces for components so that they can be mocked
|
|||
|
- Store test-case data with your tests
|
|||
|
- It's NEVER too late to start writing tests
|
|||
|
- Lightning Sand - AKA Microservices
|
|||
|
- The idea is to be (and stay) loosely coupled to the rest of the
|
|||
|
architecture, minimizing dependencies when testing is key!
|
|||
|
- Strategies for Microservice Testing
|
|||
|
- Don't be QA for services you depend on - trust their interface
|
|||
|
- Use service mocks for external dependencies
|
|||
|
- Write testing libraries/harnesses that other teams can use
|
|||
|
- Automate all of your tests - Without a UI you only need robots
|
|||
|
- What about non-functional tests
|
|||
|
- Every organization needs to evaluate whether that testing is
|
|||
|
necessary and correct for them ($$$)
|
|||
|
- Collect detailed metrics at service boundaries
|
|||
|
- Abstract out service-level concerns like back-pressure, retries
|
|||
|
and complex routing
|
|||
|
** How Games Can Inspire Great Application UX
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Scott Jenson
|
|||
|
:Twitter: @scottjenson
|
|||
|
:Email: scott@jenson.org
|
|||
|
:END:
|
|||
|
|
|||
|
- *NOT* gamification (don't be on the addictive side of things)
|
|||
|
- Video games like the word "juicy" (visual impact on input)
|
|||
|
- Video games create tension, apps remove it
|
|||
|
- Ralph Koster (Book: [[https://www.theoryoffun.com/][A Theory of Fun]])
|
|||
|
- Applying the lessons in the book to UX
|
|||
|
- Games present story, players create narrative
|
|||
|
- Standalone features vs a journey
|
|||
|
- The Mac story arc
|
|||
|
- Sound
|
|||
|
- promise
|
|||
|
- model
|
|||
|
- depth
|
|||
|
- Our story isn't the user's narrative
|
|||
|
- Games are fractal, not linear
|
|||
|
- Games are made of games
|
|||
|
- Each level has its own motivation, feedback, and learning
|
|||
|
- The deeper you go, the more profound the effect
|
|||
|
- The Learning Loop
|
|||
|
- Intent -> Action -> Result
|
|||
|
- Mental model -> affordance -> feedback
|
|||
|
- "Fun is just another word for learning" - Ralph
|
|||
|
- Mario 1-1
|
|||
|
- move (jump over) -> opening (jump into bricks) -> attacking
|
|||
|
(jump onto an enemie)
|
|||
|
- "That's how we make games at Nintend: we get the fundamentals
|
|||
|
solid first, then do as much with that core concept as our time
|
|||
|
and ambition will allow. As forthe courses and enemies, those
|
|||
|
actually came at the very end, they were done in a single burst
|
|||
|
of energy..." - Shigeru Miyamoto
|
|||
|
- Nintendo does this /all the time/
|
|||
|
- "Desktop has much better loops than mobile" - Ralph
|
|||
|
- Affordances
|
|||
|
- BotW stamina wheel - training you to take the better path
|
|||
|
- [[https://pdfs.semanticscholar.org/ce60/77a469497e464ead9f38e39ac5b0d9ec2b44.pdf][The SonicFinder, An Interface That Uses Auditory Icons]]
|
|||
|
- Mobile import is impoverished
|
|||
|
- Pinch
|
|||
|
- Tap
|
|||
|
- Long press is a hack!
|
|||
|
- Can't find any examples of gracenotes in apps
|
|||
|
- "It's not the flashy trick that matters, but the rigourous
|
|||
|
application of multiple types of feedback in both important and
|
|||
|
trivial ways" - Ralph
|
|||
|
- Hintiness
|
|||
|
- Hints =/= Affordances
|
|||
|
- Affordances reinforce the loop you're on
|
|||
|
- Hints move you to a new loop
|
|||
|
- Navigation (Disney weenies, always seeing a central place in a
|
|||
|
park, ensuring sight lines)
|
|||
|
- Hintiness prevents "bottom feeding" (getting stuck at one level,
|
|||
|
not making progress and doing new things)
|
|||
|
- Simple, light, patient examples showing how things can be done
|
|||
|
- Pacing
|
|||
|
- Games work incredibly hard on the first step
|
|||
|
- Here is a toolbox vs learn *this* first
|
|||
|
** Game Development in Eight Bits
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Kevin Zurawel
|
|||
|
:Website: https://famicom.party
|
|||
|
:Slides: https://bit.ly/gd8b-abs2
|
|||
|
:END:
|
|||
|
- 256x240 resolution with 64 colors
|
|||
|
- 1 background layer, 1 sprite layer
|
|||
|
- Backgrounds
|
|||
|
- 30x30 grid of tiles, 1 byte per tile
|
|||
|
- 2 pattern tables of tiles, 256 tiles each (one for sprites, one
|
|||
|
for backgrounds)
|
|||
|
- 64 colors. 8 of them are black (blame NTSC)
|
|||
|
- 8 4-color palettes, 4 for sprites, 4 for backgrounds
|
|||
|
- The first color of all pallets is the same (hardware limitation)
|
|||
|
- Sprites
|
|||
|
- 256 bytes of sprite ram, 4 bytes per sprite, 64 sprites at a time
|
|||
|
- No more than 8 sprites per scanline
|
|||
|
- solved using flickering
|
|||
|
- Level data
|
|||
|
- Make use of default color
|
|||
|
- abstract elements (pipe, height /x/)
|
|||
|
- run-length encoding
|
|||
|
- "set decoration" - three-screens-wide default background (SMB)
|
|||
|
- Physics
|
|||
|
- Don't use physics (simple algorithm)
|
|||
|
- Collision detection
|
|||
|
- Contra uses point vs rectangle detection
|
|||
|
- The player is always the point, where it can be hit it is a
|
|||
|
rectangle in relation to the point
|
|||
|
- The NES does not have a random number generator (3 optionsin
|
|||
|
increasingorder of stupidity)
|
|||
|
- Tetris: Do it with math (16-bit fibonacci linear feedback shift register)
|
|||
|
- FF: (Nasir Gebelli, contractor) a lookup table of 256 random numbers
|
|||
|
- Contra: a single global 8-bit value that increments by 7 whenever
|
|||
|
the game is idle
|
|||
|
- The demo uses prerecorded /actions/, it can play out differently
|
|||
|
- Saving progress
|
|||
|
- Password systems
|
|||
|
- DQ2 in Japan used a "poem"
|
|||
|
- FDS
|
|||
|
- Shut down due to ease of piracy
|
|||
|
- Battery-backed memory
|
|||
|
- "Hold reset" - power issues could lead to corruption
|
|||
|
- Write multiple times with CRC
|
|||
|
- "Embrace the stupid"
|
|||
|
- Is it close enough, and much more efficient?
|
|||
|
* Day Two
|
|||
|
** Duolingo: [[file:20200711113638-microservice.org][Microservice]] Journey :ATTACH:
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Max Blaze
|
|||
|
:Attachments: DuolingoMicroserviceJourney-MaxBlaze-2019-08-22.pdf
|
|||
|
:ID: e90babcd-5d41-4b70-b8d7-d22a28e18e8c
|
|||
|
:Slides: [[file:data/e9/0babcd-5d41-4b70-b8d7-d22a28e18e8c/DuolingoMicroserviceJourney-MaxBlaze-2019-08-22.pdf]]
|
|||
|
:END:
|
|||
|
- first microservice in 2016
|
|||
|
- making many changes to the product, many releases per day
|
|||
|
- centralized dashboards/logging
|
|||
|
- Terraform for infrastructure as code
|
|||
|
- First microservice in ECS in 2017-2018
|
|||
|
- Why move to microservices?
|
|||
|
- Scalability problem with teams
|
|||
|
- Slow and difficult with a monolith
|
|||
|
- Desire to use multiple languages (monolith in python, wanting to
|
|||
|
incorporate scala, nodejs, ...)
|
|||
|
- Flexibility
|
|||
|
- Velocity
|
|||
|
- Reliability
|
|||
|
- Cost savings
|
|||
|
- What to carveout first?
|
|||
|
- Not the largest chunk
|
|||
|
- Start with a small but impactful feature
|
|||
|
- move up in size, complexity, and risk
|
|||
|
- consider dependencies
|
|||
|
- First thing was the reminder service 🦉🗡
|
|||
|
- Using circuit breakers to make microservices independent
|
|||
|
- Why docker?
|
|||
|
- Kind of the only game in town
|
|||
|
- Why docker with ECS?
|
|||
|
- task auto scaling
|
|||
|
- task-level IAM
|
|||
|
- needs to be supported by the aws client library (e.g., boto)
|
|||
|
- cloudwatch metrics
|
|||
|
- dynamic alb targets
|
|||
|
- manageability
|
|||
|
- Microservice abstractions at Duolingo
|
|||
|
- Abstracted into terraform modules
|
|||
|
- Web service (internal or external)
|
|||
|
- load balancer and route 53
|
|||
|
- worker service (daemon or cron)
|
|||
|
- sqs and event-based scheduling
|
|||
|
- data store
|
|||
|
- monitoring
|
|||
|
- CI/CD
|
|||
|
- Github -> Jenkins -> ECR/Terraform (S3) -> ECS
|
|||
|
- Load balancing
|
|||
|
- ALB vs. CLBs
|
|||
|
- ALBs more strict when handling malformed requests (defaults to
|
|||
|
HTTP/2 (headers always passed in lowercase)
|
|||
|
- Differences in cloudwatch metrics (continuous in CLBs, discrete
|
|||
|
in ALBs)
|
|||
|
- Standardizing microservices
|
|||
|
- develop a common naming scheme for repos and services
|
|||
|
- autogenerate as much of the initial service as possible (?)
|
|||
|
- move core functionality to shared base libraries
|
|||
|
- *provide standard alarms and dashboards*
|
|||
|
- /periodically review microservices for consistency and quality/
|
|||
|
- Monitoring microservices
|
|||
|
- includes load balancer errors
|
|||
|
- pagerduty integration
|
|||
|
- includes links to playbooks
|
|||
|
- emergency pages, warnings go to email
|
|||
|
- schedules and rotations are managed by terraform
|
|||
|
- Grading microservices
|
|||
|
- Cost reduction options
|
|||
|
- Cluster
|
|||
|
- instance type
|
|||
|
- pricing options
|
|||
|
- auto scale
|
|||
|
- add/remove AZs
|
|||
|
- using "Spot" (spotinst) to save money on ephermeral cluster instances
|
|||
|
- drains ECS services
|
|||
|
- spreads capacity across AZs
|
|||
|
- bills on % of savings
|
|||
|
- ECS allows oversubscription of memory, *WE DO NOT RECOMMEND THIS*
|
|||
|
- AWS Limits
|
|||
|
- EC2 has a hard-coded maximum # of packets(1024/s) sent to an amazon
|
|||
|
provided dns server
|
|||
|
- Nitro is not caching DNS requests where Xen was
|
|||
|
** Mentoring the way to a diverse and inclusive workplace
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Alexandra Millatmal
|
|||
|
:Twitter: @halfghaninNE
|
|||
|
:Email: hello@alexandramillatmal.com
|
|||
|
:Slides: http://alexandramillatmal.com/talks
|
|||
|
:END:
|
|||
|
|
|||
|
- Developer at Newsela (Education tech company promoting literacy in
|
|||
|
the 2nd-12th grade space)
|
|||
|
- The tenants of mentorship are similar to the tenants of inclusive
|
|||
|
companies
|
|||
|
- Mentorship doesn't work for folks of under-represented backgrounds
|
|||
|
- Finding very similar entry level jobs, very homogenous teams, no time to
|
|||
|
support learning
|
|||
|
- Skill-building and diversity appear related
|
|||
|
- What if strong mentorship /begets/ diversity & inclusion?
|
|||
|
- Good mentorship / good diversity
|
|||
|
- Supporting and retaining engineers with underrepresented identities
|
|||
|
- be welcoming and inclusive in the recruiting process
|
|||
|
- post openings on "key values"
|
|||
|
- company must list their values
|
|||
|
- conveys people and tech values on the same level
|
|||
|
- candidates filter jobs based on their prioritized values
|
|||
|
- referrals can cut both ways
|
|||
|
- can increase the homogenous nature of the workplace
|
|||
|
- maybe direct referall bonuses into donations to inclusive
|
|||
|
groups that attract and talent
|
|||
|
- affinity groups
|
|||
|
- caucuses across departments working with management
|
|||
|
- standardized review process
|
|||
|
- stanford research into review proceseses
|
|||
|
- men overrepresented in the higher tier, women in the middle
|
|||
|
- standardizing removed the bias
|
|||
|
- clear definitions of roles and responsibilities
|
|||
|
- do they have ownership
|
|||
|
- are these employees getting a seat at the table for decisions
|
|||
|
- representation in leadership
|
|||
|
- are there people there that look like me?
|
|||
|
- is there a clear model of advancement? allyship in leadership?
|
|||
|
- investment in internal & external advocacy
|
|||
|
- signals that copmanies understand the systematic barriers to
|
|||
|
inclusion and diversity
|
|||
|
- sponsorship - "super mentorship"
|
|||
|
- stark differences in valuation of the above bulletpoints between
|
|||
|
underrepresented groups and well-represented groups (women vs men,
|
|||
|
lgbt+ vs straight men)
|
|||
|
- Supporting and leveling up junior engineers
|
|||
|
- recruiting process / relationships
|
|||
|
- the candidate should be receiving feedback on their performance in
|
|||
|
the recruting process!
|
|||
|
- Gives them constructive advice and context
|
|||
|
- apprenticeships and clearly defined entry-level positions
|
|||
|
- is there a clear path for growth?
|
|||
|
- clear and structured onboarding
|
|||
|
- please do not make their point person a person they report to
|
|||
|
- need to go to information from somone that doesn't involve
|
|||
|
company politics
|
|||
|
- information should exist outside of leads/managers heads
|
|||
|
- define onboarding procedures in a shared space
|
|||
|
- learning groups
|
|||
|
- space to ask questions and demonstrate leadership, particularly
|
|||
|
with peer-to-peer learning
|
|||
|
- formalized mentorship
|
|||
|
- ensure that compensated time is resulting in measurable goals
|
|||
|
for the junior engineer
|
|||
|
- recommend them for opportunities
|
|||
|
- standardized review process
|
|||
|
- reframe junior-ness as an opportunity, not a deficit of skill
|
|||
|
- Mentorship with diversity and inclusion in mind
|
|||
|
- this work is really hard
|
|||
|
- easy to fall into a pattern of saying you're making progress
|
|||
|
without measuring to make sure that's the case
|
|||
|
- intent is only half of the picture
|
|||
|
- the other half is /sacrifice/ to make real, measured investments
|
|||
|
- mentorship should begin during the interviews
|
|||
|
- [[https://www.wired.com/story/for-young-female-coders-internship-interviews-can-be-toxic/][wired article on young women's interview experiences]] (today?!)
|
|||
|
- place serious focus on developing mentors
|
|||
|
- forces mentees to manage /up/
|
|||
|
- mentorship is a two-way street
|
|||
|
- have you ever seen someone become a better collaborator after
|
|||
|
mentoring a junior engineer?
|
|||
|
- mentorship is leadership and it's learned
|
|||
|
- have clear growth objectives for the mentor and the mentee
|
|||
|
- mentorship should happen on compensated time
|
|||
|
- rethink the peer group
|
|||
|
- slack channel for juniors spread across different offices
|
|||
|
- wasn't an organic space to share knowledge
|
|||
|
- a black junior woman engineer's peers aren't just other black
|
|||
|
employees, or women, or other limited groups
|
|||
|
- What's the value to the company?
|
|||
|
- make a business case for mentorship
|
|||
|
- that will drive diversity and inclusion
|
|||
|
- mentorship can
|
|||
|
- build brand halo among candidates
|
|||
|
- distribute management responsibilities
|
|||
|
- build its own workforce
|
|||
|
- distributes business knowledge working on real business projects
|
|||
|
- fosters relationship building and belonging
|
|||
|
- practices wielding expertise, fosters bonding over work
|
|||
|
|
|||
|
** Sextech: The good, the Bad & the Bias
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Alison Falk
|
|||
|
:Twitter: alisonfalkpgh
|
|||
|
:Slides: https://bit.ly/MillatmalAbstractionsII
|
|||
|
:END:
|
|||
|
- Deepfakes
|
|||
|
- people onforums requesting deepfakes of coworkers, etc.
|
|||
|
- takes few photos
|
|||
|
- women are most typically targeted
|
|||
|
- silenced, made less credible due to the video
|
|||
|
- no criminal recourse
|
|||
|
- currently thriving
|
|||
|
- nonconsensual / revenge porn
|
|||
|
- laws are vague (interstate implications)
|
|||
|
- sexting & development of sexual identity not reflected in the law
|
|||
|
- this gets caught under the net of sharing child pornography
|
|||
|
- Just because you can doesn't mean you should
|
|||
|
- harms sex workers
|
|||
|
- sex trafficing is only 19% of human trafficing
|
|||
|
- 25% of sex workers sexually assaulted by officers
|
|||
|
- multiple times during stings
|
|||
|
- arrests inflate statistics
|
|||
|
- 90.8% of victims are deported
|
|||
|
- Bias
|
|||
|
- don't need to reach orgasm to procreate? considered a vice, not
|
|||
|
family planning
|
|||
|
- approved / not approved.com
|
|||
|
- approved vs non approved ads
|
|||
|
- silencing of minority / repressed groups
|
|||
|
- payment processors
|
|||
|
- sex industry is the first adopter of new tech
|
|||
|
- kicked off, considered a liability
|
|||
|
- shadowbanning
|
|||
|
- facebook's recent patented content filtering algorithm
|
|||
|
- SESTA/FOSTA
|
|||
|
- doesn't punish traffickers, makes websites legally liable for any
|
|||
|
user generated content found to "knowingly assist, facilitate, or
|
|||
|
support sex trafficing"
|
|||
|
- interferes with sex education
|
|||
|
- pushes sex trafficking further underground
|
|||
|
- based on moral panic (National Center on Sexual Exploitation,
|
|||
|
formerly Morality in the Media)
|
|||
|
- hurts the most vulnerable in our community
|
|||
|
- Root of the problem
|
|||
|
- education <=> laws -> media/tech
|
|||
|
- who receives accurate sex education
|
|||
|
- searches on sex tech aren't showing any of these issues
|
|||
|
- teach children to know about their bodies so they don't allow
|
|||
|
others to make decisions about their bodies
|
|||
|
- sextechspace
|
|||
|
- resources online
|
|||
|
- What can you do today
|
|||
|
- support orgs like @decrimNY, @decrimNowDC, @TheBADASS_army
|
|||
|
- use your platform to spread awareness
|
|||
|
- advocate for agency and consent
|
|||
|
- make sure all stakeholders are at the table
|
|||
|
- "If you are not intentional about being inclusive, what you will do
|
|||
|
is perpetuate exclusion"
|
|||
|
|
|||
|
** Passing the Torch Without Dropping The Ball: Lessons in Documentation
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Mary Thengvall, Rain Leander
|
|||
|
:Twitter: @mary_grace, @rainleander
|
|||
|
:END:
|
|||
|
- TL;DR: It's not just a question of clocking out and handing over the
|
|||
|
keys
|
|||
|
- Advocato shirts!
|
|||
|
- Getting sick, switching roles, moving on
|
|||
|
- Why should you care about a transition plan?
|
|||
|
- Taking time off without worrying
|
|||
|
- Transitioning into a promotion
|
|||
|
- Delegate: documented things allow other people to volunteer
|
|||
|
- Are you going to do that forever? document it and let someone else
|
|||
|
take over
|
|||
|
- The handover document
|
|||
|
- the overview
|
|||
|
- project goals
|
|||
|
- reading list
|
|||
|
- dramatis personae
|
|||
|
- who are the stakeholders/elders?
|
|||
|
- learn from them, and document!
|
|||
|
- who's the quiet person that gets stuff done?
|
|||
|
- who needs a bit more time to ramp up?
|
|||
|
- knowledge needs to be documented and disseminated with care,
|
|||
|
perhaps a bit private
|
|||
|
- not toxic, just necessary
|
|||
|
- the regular tasks
|
|||
|
- wish list
|
|||
|
- that which remains undone
|
|||
|
- the inventory
|
|||
|
- budget
|
|||
|
- credentials
|
|||
|
- the keys to the castle
|
|||
|
- +eDit edIt+ Edit
|
|||
|
- what's no longer accurate?
|
|||
|
- what's missing?
|
|||
|
- what's confusing?
|
|||
|
- revisit it, keep it fresh
|
|||
|
- Prioritize
|
|||
|
- what's urgent?
|
|||
|
- what's important?
|
|||
|
- what can only you do?
|
|||
|
- what's the low-hanging fruit that's easy to ramp up on?
|
|||
|
- What works for you?
|
|||
|
- don't be scared to make changes
|
|||
|
- or to say no
|
|||
|
- be sure the community agrees with your changes
|
|||
|
- Share your stories
|
|||
|
|
|||
|
** The Times They Are a-Changin': A Data-Driven Portrait of New Trends in How We Build Software, Open Source, & What Even is "Entry-Level" Now
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Heather Miller
|
|||
|
:Twitter: @heathercmiller
|
|||
|
:END:
|
|||
|
- Tracking the shift in focus in open source Scala
|
|||
|
- Things that are changing fast
|
|||
|
- how we build software
|
|||
|
- open source
|
|||
|
- our idea of software engineers
|
|||
|
- what should they know?
|
|||
|
- How people are getting into tech
|
|||
|
- hiring is difficult
|
|||
|
- there's a massive gap between jobs available and people to fill
|
|||
|
them
|
|||
|
- a large portion of professional developers are new
|
|||
|
- we need to adapt, culturally, to make room for lots more newcomers
|
|||
|
- frameworks and reuse to reduce friction?
|
|||
|
- existing devs are burning out
|
|||
|
- "With companies unable to fill open positions, current employees
|
|||
|
are expected to fill in the gaps"
|
|||
|
- Increased diversity would help
|
|||
|
- Also immigration, remote workers
|
|||
|
- [[https://dl.acm.org/citation.cfm?id=2702549][Paper: Gender and tenure diversity in github teams]]
|
|||
|
- increased diversity = increased productivity
|
|||
|
- How do we stop people from disengaging?
|
|||
|
- Women disengage earlier than men
|
|||
|
- Open source adoption
|
|||
|
- Dramatically increased since 2010
|
|||
|
- Open source became the default choice
|
|||
|
- Low-cost with no vendor lock-in
|
|||
|
- Open source components exist in 96% of applications scanned and
|
|||
|
analyzed by Synopsys in 2018, with an average of 257 components
|
|||
|
per application. 36% of code bases were open source components in
|
|||
|
2017, 57% in 2018.
|
|||
|
- OSS projects 62% self-funded, 49% employer-funded
|
|||
|
- "Truck factor"
|
|||
|
- 64% of top projects on Github relied on 1-2 devs to survive
|
|||
|
- Ecosystem and community are everything
|
|||
|
- Leo Meyrovich - [[https://dl.acm.org/citation.cfm?id=2509515][Paper on programming language adoption]]
|
|||
|
- Most important factor is an ecosystem / open-source libraries
|
|||
|
- Professional developers want an active community
|
|||
|
- All these puzzle pieces need polishing
|
|||
|
|
|||
|
* Day Three
|
|||
|
|
|||
|
** Analysis of the Feeling of the Attendees to a Talk in Real Time
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Juantomás Garcia Molina
|
|||
|
:Twitter: juantomas
|
|||
|
:END:
|
|||
|
|
|||
|
- Google cloud functions triggered by Google Storage, Pub/Sub, or REST
|
|||
|
- Using google vision API to detect facial featuers and emotional
|
|||
|
responses
|
|||
|
|
|||
|
** Identity Expression: Coming Out of the Work Closet
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Matthew Rogers
|
|||
|
:END:
|
|||
|
|
|||
|
Coming out of the Closet
|
|||
|
- Coming out doesn't just happen once, it happens a /lot/
|
|||
|
- "Spheres of existence" you have to come out to
|
|||
|
- Friends
|
|||
|
- Peers
|
|||
|
- Family
|
|||
|
- Digital
|
|||
|
- Public
|
|||
|
- *Work*
|
|||
|
- Story
|
|||
|
- The comment is made
|
|||
|
- Affected how I work, which affects my coworkers
|
|||
|
- Negative effect spreads
|
|||
|
- Expands further while training/interacting
|
|||
|
- It isn't always cut and dry
|
|||
|
- The fear of "what if" can be damaging all its own
|
|||
|
- In 30 states, LGBTQ+ workers aren't fully protected under the law
|
|||
|
- PA included
|
|||
|
- Professinal risks
|
|||
|
- Fired outright
|
|||
|
- Passed over for promotions or projects
|
|||
|
- Refusal of reference for next job
|
|||
|
- Personal risks
|
|||
|
- Uncomfortable or dangerous work environment
|
|||
|
- lost source of income
|
|||
|
- Forced to change field or location
|
|||
|
- Ther's risk to the business witself when employees hide part of
|
|||
|
their identity
|
|||
|
- Productivity
|
|||
|
- Say that 10% of your day goes towards identity concealment
|
|||
|
- adds up to 6 weeks of lost productivity every year
|
|||
|
- Communication
|
|||
|
- less likely to engage
|
|||
|
- avoid people
|
|||
|
- crosses levels
|
|||
|
- Creativity
|
|||
|
- stress + anxiety
|
|||
|
- requires vulnerability
|
|||
|
- Collaboration
|
|||
|
- needs creativity + communication
|
|||
|
- not getting the best work
|
|||
|
- What if things went the other way?
|
|||
|
- Productivity :: fewer distractions from your work
|
|||
|
- communication :: problems caught, efficiency goes up
|
|||
|
- creativity :: flourishes in safe + comfortable environments
|
|||
|
- collaboration :: becomes easier and more routine
|
|||
|
- Why focus on such a small group of people
|
|||
|
- ~4.5% of the entire population
|
|||
|
- Just a method of expressing identity, not limited to just queer
|
|||
|
people
|
|||
|
- 4.5% queer
|
|||
|
- 6% practicing non-christian faiths
|
|||
|
- 19% have a disability
|
|||
|
- 22% persons of color
|
|||
|
- 47% female
|
|||
|
- Isn't this just about feelings?
|
|||
|
- this holds personal and professional importance with real mental
|
|||
|
healthy implications
|
|||
|
- Your "Selves"
|
|||
|
- Private
|
|||
|
- Home
|
|||
|
- *You*
|
|||
|
- Your core self
|
|||
|
- Public
|
|||
|
- Work
|
|||
|
- Dissonance
|
|||
|
- Your genuine self suffers as you put your energy into maintaining
|
|||
|
a separate self or concealing part of your identity
|
|||
|
- Personal Consequences
|
|||
|
- drives down those four factors
|
|||
|
- is mentally exhausting
|
|||
|
- it becomes a cycle
|
|||
|
- Business consequences
|
|||
|
- Quality of Product
|
|||
|
- Employee Satisfaction
|
|||
|
- Company Culture
|
|||
|
- Bottom Line
|
|||
|
- What can I do now?
|
|||
|
- Introduce yourself using your pronouns
|
|||
|
- Says you care how other people want to be addressed
|
|||
|
- Start ERGs (Employee resource groups)
|
|||
|
- People with shared experiences
|
|||
|
- Acknowledge and celebrate Black History Month, Women's Month,
|
|||
|
Pride Month, etc. Let people feel *seen*
|
|||
|
- Don't ask to touch anyone's hair. *Ever*.
|
|||
|
- Accommodate variations in holidays and scheduling around religious
|
|||
|
practices
|
|||
|
- *Don't get embarrassed* if you mess up. Apologize, correct
|
|||
|
yourself, and learn.
|
|||
|
- Replace words like "wife/husband/boyfriend/girlfriend/etc" with
|
|||
|
partner
|
|||
|
- Be careful asking about personal and private relationships in
|
|||
|
general
|
|||
|
- Look into unconscious bias training. Use HR.
|
|||
|
- Look around the room
|
|||
|
- Different perspectives and experiences simply work better
|
|||
|
- When you don't know, research. Ask questions, if you must. Just
|
|||
|
*don't assume*.
|
|||
|
- If you are in the closet at work, *open the door a little*
|
|||
|
- Make sure you're not blocking someone else's exit
|
|||
|
|
|||
|
** Overcoming Challenges: An Attitude of Iteration
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Eric Johnson
|
|||
|
:END:
|
|||
|
- "The Look" (first date story)
|
|||
|
- If you're different and it shows, it's assumed every problem in the
|
|||
|
book belongs to you
|
|||
|
- "You're not good enough for her" or "That's the saddest thing I've
|
|||
|
ever seen"
|
|||
|
- (context: one finger on each hand, one toe on each foot, 4/5 kids
|
|||
|
share this trait)
|
|||
|
- "Man, I'm /different/"
|
|||
|
- "Things are gonna be a little /challenging/ for me, aren't they?"
|
|||
|
- *We are all challenged*
|
|||
|
- How you deal with that challenge is the model by which everyone else
|
|||
|
is going to deal with it
|
|||
|
- 50/50 chance of the genetic condition being passed on (5 fingers, or
|
|||
|
/something else/)
|
|||
|
- /You/ have to make the choice of how to deal with it
|
|||
|
- Can't force children to make a decision, they have to make it on
|
|||
|
their own
|
|||
|
- /It is a blessing, not a curse/
|
|||
|
- /It is what it is/
|
|||
|
- It'll never be what it isn't
|
|||
|
- No excuses
|
|||
|
- "I can't do x /yet/", not "I can't do x"
|
|||
|
- We have to adapt
|
|||
|
- Never tell kids they "can't do x",but "it's gonna be hard, you're
|
|||
|
gonna have to figure it out"
|
|||
|
- Have fun
|
|||
|
- Sometimes life is hard, but you've still gotta go on. you try again,
|
|||
|
and you try again.
|
|||
|
|
|||
|
** Beyond The Sunset: How To Wring The Maximum Joy From Your Last 10 Years In Tech :ATTACH:
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Vanessa Kristoff
|
|||
|
:Twitter: @vanessakristoff
|
|||
|
:Email: Vanessa.kristoff@gmail.com
|
|||
|
:Attachments: Beyond%20the%20Sunset%20-%20Vanessa%20Kristoff%20Abstractions%202019.pdf
|
|||
|
:ID: 3edffe50-d4bb-4a56-84d9-ab8de0fa3ec3
|
|||
|
:Slides: [[file:data/3e/dffe50-d4bb-4a56-84d9-ab8de0fa3ec3/Beyond%20the%20Sunset%20-%20Vanessa%20Kristoff%20Abstractions%202019.pdf]]
|
|||
|
:END:
|
|||
|
|
|||
|
- "Pre-tirement"
|
|||
|
- 55 years old
|
|||
|
- Ageism is real
|
|||
|
- "Will they fit the culture" BS
|
|||
|
- But Don't be "that person"
|
|||
|
- "better back in the day"
|
|||
|
- Job satisfaction over time
|
|||
|
- U-shaped curve
|
|||
|
- http://www.andrewoswald.com/docs/jooparticle.pdf
|
|||
|
- Imposter Syndrome
|
|||
|
- No, seriously, for reals, after all these years, you are NOT an
|
|||
|
imposter
|
|||
|
- Hard to have fun while struggling with this
|
|||
|
- We are the Village Elders
|
|||
|
- That comes with responsibility
|
|||
|
- We should be helping people
|
|||
|
- It's just a job
|
|||
|
- You should know that by now
|
|||
|
- Sponsor a Newbie
|
|||
|
- Teach your coworkers what grace is, by example
|
|||
|
- Sponsor vs mentoring
|
|||
|
- mentoring is "tweaking" them to fit in
|
|||
|
- sponsoring is promoting them
|
|||
|
- Give whimsical talks at conferences
|
|||
|
- Optional: create tag clouds referencing CORBA
|
|||
|
- You have knowledge that not everybody has
|
|||
|
- Pretend to be an Extrovert
|
|||
|
- Doing so will help the folks you're extroverted with
|
|||
|
- This is why that imposter thing is important
|
|||
|
- Sign up for the messiest possible coding
|
|||
|
- what do you have to fear? NOTHING
|
|||
|
- Don't stop learning
|
|||
|
- Volunteer to write UI code or backend code or try that Haskell
|
|||
|
thing
|
|||
|
- Join a new industry
|
|||
|
- Use your network for good
|
|||
|
- You have contacts
|
|||
|
- Your people need contacts
|
|||
|
- See how that works?
|
|||
|
- Gossip and complaining
|
|||
|
- It's not adding value to your work life, so just stop it
|
|||
|
- Make a plan
|
|||
|
- start NOW thinking about what you'll do
|
|||
|
- how will you fill/structure your time?
|
|||
|
- you will need a social life once you're retired
|
|||
|
- Get your house in order, literally and figuratively
|
|||
|
- Marie Kondo that crap
|
|||
|
- Use your employer health care (if you have it) while you can
|
|||
|
|
|||
|
** How Live Coding Changed My Life
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Jesse Weigel
|
|||
|
:Twitter: @JesseRWeigel
|
|||
|
:END:
|
|||
|
|
|||
|
- Volunteer live coder for freeCodeCamp
|
|||
|
- How I got started
|
|||
|
- Paid for private github repos rather than letting folks see my code
|
|||
|
- "I make a lot of mistakes and I am a full time dev. Maybe it would
|
|||
|
be helpful for beginners to see that."
|
|||
|
- First streams were really bad and nobody watched
|
|||
|
- Asked for help on the freeCodeCamp forum
|
|||
|
- The community
|
|||
|
- all ages, locations, and skill levels
|
|||
|
- eager to learn and contribute
|
|||
|
- overwhelmingly positive
|
|||
|
- always learning and trying new ways to do things
|
|||
|
- VERY diverse watchers
|
|||
|
- Consistency is key
|
|||
|
- Set time for the streams
|
|||
|
- Keeping it positive
|
|||
|
- Thank for negative feedback
|
|||
|
- Ask for clarification if it's not constructive ("what can I do
|
|||
|
better?")
|
|||
|
- People with situational anxiety, etc. feeling safe
|
|||
|
- Video about depression, mental health issues
|
|||
|
- What I've learned
|
|||
|
- So much collaboration
|
|||
|
- Pull requests!
|
|||
|
- Confidence building
|
|||
|
- Viewers too, gaining confidence over time
|
|||
|
- Viewers get jobs!
|
|||
|
- How you can start
|
|||
|
- Make a youtube or twitch channel
|
|||
|
- Broadcast and share your screen (OBS)
|
|||
|
- Start coding!
|
|||
|
- Advice
|
|||
|
- Adapt based on feedback
|
|||
|
- show your mistakes
|
|||
|
- show your face
|
|||
|
- don't be afraid to say I don't know
|
|||
|
- It's okay to say nothing (or better yet thank you) when someone
|
|||
|
tells you something that you already knew
|
|||
|
- it may not be new to them, they could be excited and want to
|
|||
|
help
|
|||
|
- Always be positive and encouraging
|
|||
|
- Give encouragement, not solutions
|
|||
|
- Things to avoid
|
|||
|
- talking badly about another language, framework, library,etc
|
|||
|
- laughing at a question (assume every question is serious)
|
|||
|
- getting angry
|
|||
|
- coding and reading the chat at the same time
|
|||
|
- negativity (there is already enough negativity in the world)
|
|||
|
|
|||
|
** Debugging Our Feelings :ATTACH:
|
|||
|
:PROPERTIES:
|
|||
|
:Speaker: Jamie Strachan
|
|||
|
:Twitter: @JamieStrachan
|
|||
|
:Attachments: Debugging%20Our%20Feelings-Abstractions.pdf
|
|||
|
:ID: 627b046b-e412-4121-9ac5-c0f7af49daeb
|
|||
|
:Slides: [[file:data/62/7b046b-e412-4121-9ac5-c0f7af49daeb/Debugging%20Our%20Feelings-Abstractions.pdf]]
|
|||
|
:END:
|
|||
|
|
|||
|
- Working at odds with professional development and depression
|
|||
|
- Cognitive Behavioural Therapy
|
|||
|
- "Feeling Good" by Dr. David Burns
|
|||
|
- parallells with developer life
|
|||
|
- Experiences -> 👩 Thoughts -> Responses
|
|||
|
- "There is nothing either good or bad, but thinking makes it so" (Shakesspeare)
|
|||
|
- We can change how we feel if we change how we think
|
|||
|
- Input -> 💻 Code -> Output
|
|||
|
- Starting a project, getting overwhelmed, distracted, guilty, nervous
|
|||
|
- Similar to application in an incorrect, incomplete state. Not what
|
|||
|
we wanted yet.
|
|||
|
- We test our output
|
|||
|
- We trust our feelings
|
|||
|
- Emotional reasoning
|
|||
|
- Because I feel something, it must be true
|
|||
|
- Not rational
|
|||
|
- Would be like looking at the app in that state, "I guess I'm
|
|||
|
done."
|
|||
|
- Feelings should be
|
|||
|
- +positive+
|
|||
|
- helpful
|
|||
|
- reasonable
|
|||
|
- rational
|
|||
|
- good at /rationalizing/, working our way /back/ from the
|
|||
|
feelings, not super helpful
|
|||
|
- Mind reading
|
|||
|
- We respond to what /we/ think /they're/ thinking
|
|||
|
- Leads to impostor syndrome
|
|||
|
- Test the feelings instead. Ask the question, don't guess.
|
|||
|
- All-or-nothing thinking
|
|||
|
- Perfectionism
|
|||
|
- Test
|
|||
|
- Antiperfectionism sheet
|
|||
|
- Task, Effectiveness, Satisfaction
|
|||
|
- Testing helps identify problems, but doesn't fix them
|
|||
|
- Code won't get any better without changes
|
|||
|
- Editor for thoughts
|
|||
|
- Notebook
|
|||
|
- two column technique
|
|||
|
- left hand side: automatic thoughts
|
|||
|
- thought patterns that are causing us to feel that way
|
|||
|
- "I'm overwhelmed" -> thinking, "this is going to be hard"
|
|||
|
- "Guilty" -> thinking, I'm a procrastinator
|
|||
|
- Nervous -> thinking, I'm not going to finish this on time
|
|||
|
- right hand side: rational responses
|
|||
|
- fortune telling
|
|||
|
- we've predicted the future, and are responding as though
|
|||
|
it's true
|
|||
|
- I can't know this
|
|||
|
- it could also be fun, educational
|
|||
|
- labeling
|
|||
|
- fancy term for name-calling
|
|||
|
- reduces people to one trait
|
|||
|
- "I've always been a procrastinator, I'll always be a procrastinator"
|
|||
|
- I'm not any one thing (I'm procrastinatING)
|
|||
|
- I don't always procrastinate
|
|||
|
- fortune telling
|
|||
|
- takes away our autonomy (it's inevitable)
|
|||
|
- I have control over the outcome
|
|||
|
- there are other options
|
|||
|
- Thoughts can have a "home field advantage" in our heads
|
|||
|
- How does this change when it comes from someone else?
|
|||
|
- It doesn't
|
|||
|
- Still just an experience, just your thoughts
|
|||
|
- "No one can make you feel inferior *without your consent*" -
|
|||
|
Eleanor Roosevelt
|
|||
|
- Magnification and Minification
|
|||
|
- Disqualifying the postitive
|
|||
|
- [[https://scontent.fakc1-1.fna.fbcdn.net/v/t1.0-9/68566036_10157557143404198_4347573004629180416_n.jpg?_nc_cat=107&_nc_oc=AQlSWxEozmxHxlCrAqSBkrAgw36nZo5LIgQEXM_4-_cAMjq40YTtDIdZCUDpjqdSKQY&_nc_ht=scontent.fakc1-1.fna&oh=7680c5d2de15765ec963f4e059bdae6c&oe=5DD47835][Accepting a compliment]]
|
|||
|
- pause
|
|||
|
- say thank you
|
|||
|
- Using the two-column technique, have someone to role play them with
|
|||
|
- We don't always extend sympathy to ourselves
|
|||
|
- "Should" is the worst word in the english language
|
|||
|
- Try "I /want/..."
|
|||
|
- Test your feelings
|
|||
|
- Get your thoughts out of your head
|
|||
|
- Get help
|
|||
|
* Not Attended
|
|||
|
** The Mental Impact of Tech Interviews
|
|||
|
:PROPERTIES:
|
|||
|
:Slides: https://docs.google.com/presentation/d/1y4SwAuJcYgCJ-5lSpF560QBWaMBIrlLFA5BrMH-UKFw/edit?usp=drivesdk
|
|||
|
:Speaker: Zack Zlotnik
|
|||
|
:END:
|
|||
|
* Misc :noexport:
|
|||
|
|
|||
|
** Acquaintances
|
|||
|
|
|||
|
*** Kevin Zurawel
|
|||
|
- 8-bit talk
|
|||
|
*** Jess Bees
|
|||
|
- art installation
|
|||
|
*** Jamie Strachan
|
|||
|
- manager/speaker
|
|||
|
*** Adrian P. Dunston
|
|||
|
- Manager
|
|||
|
- Fallout
|
|||
|
- Star Trek
|
|||
|
*** Ariel (Ari) Rivera
|
|||
|
- Milkshakes
|
|||
|
*** Nate Smith
|
|||
|
***
|