Category Archives: Conferences

the effective remote developer – live blogging at qcon

Posted on by
Reply

The Effective Remote Developer
Speaker: David Copeland @davetron5000

See the list of all blog posts from the conference

David has worked for 4 years remotely. Most people are remote.

Definition of remote

  • “You are remote if you do not often interface face-to-face with the people you work with”
  • hard – lone wolf – only one person is remote
  • easy – everyone is remote
  • also – multiple offices

Definition of effective

  • Productiving value
  • Agency – don’t just want to be closing jira tickets
  • Inclusion – don’t want to be that guy in Alabama that people send work to
  • Rewarding

Not easy; takes constant upkeep

Benefits

  • Freedom & flexibility – no commute, acccess to own kitchen, live where want
  • Company has access to wider pool of talent – slowing down ability to liver by restricting to specific area

Must build with people you don’t know and maintain trust with people that don’t.

Trust

  • “the half life of trust is six weeks – it must constantly be replenished”
  • Communicate frequently and clearly – Turn big projects into small ones. Everyone knows what working on. Get early feedback. So shows value delivering. Provide more context. Read what wrote and revise at least once. Use bold/underline/whitespace for clarity.
  • Be responsive, but set boundaries – publish your working hours (including time zones). Put in email signature and comment if meeting outside working hours. Developer a worklow where you aren’t heads down coding for hours; develop mental SLAs for communication. Specific affirming (positive) feedback is useful.
  • Assume good intentions – we are not good at critiquing. remember the reviewer is trying to help even if sounds cold and harsh.
  • Help others help you – go to chat or video for people who don’t communicate well over emai. Find out how everyone best communicates. Be specific in what type of feedback you want

Base level of technology

  • Easiest thing, but need to be successful
  • Chat system that is easy to use
  • Video conference that supports multiple people
  • Better mic than laptop mic

Types of communication

  • Coding – Think about smallest viable change. Write better change requests so can judge your changes. Learn to screencast (quick video) and diagram.
  • Synchronous – ex: video chat. Experience people as a human when not present. Be prepared. Formulate opinion in your mind. Use nouns instead of pronouns more than you think in case a few words drop. Also, pause more frequently and ask for feeback. “Any questions before I move on”. Don’t multitask; pay attention – best case is missing info; worst case is getting called out or having to ask. Have regular backchanel for tech issues.
  • Asynchronous
  • Socializing – If quiet in office, people still know who you are and that humanizes you. If remote, you are a producer of emails. Use time before meeting starts to socialize. Have one on ones with no agenda. Like scheduling time to stand around the water cooler. Travel to meet others in person. Accept that will miss happy hours

Remember computers are terrible and nothing works. Can bond over shared bad experience.

When interview, do chat and give take home project (add a few features) then pair program remotely to add another feature. Then fly onsite to interview. Have hired a few without flying in

Dedicated area at home to work.

Many of these tips are helpful even without remote developers.

data as dna: building a company on data – live blogging at qcon

Posted on by
Reply

Data as DNA: Building a Company on Data
Speaker: Cathy Polinsky @cathy_polinsky

See the list of all blog posts from the conference

“90% of the world’s data has been created in the past 2 years” – has been true for a number of years because in the age of data

Key Points

  • If the data is not visible, it is meaningless – need to be able to visualize, understand and interpret the data
  • Does everyone have access to the data – be sure to strip/mask sensitive data or aggregate data (mimimal sample size so not sharing PII data)
  • Determine what data/questions/metrics are important – need to know what optimizing for

Testing

  • Showed Amazon example of when they had two many tabs.
  • A/B testing failed because people were used to the original.
  • A/B testing doesn’t help for short term effects.
  • Don’t look at results too early
  • Be explicit about what important to you
  • Iterative testing is important
  • The colser you are to your goal, the more important it is to evaluate your goal metrics
  • Don’t want too. much or too little data – Goldilocks

Personalization

  • Personalization is not new – even the shopkeeper in a physical store made recommendations
  • Stitch Fix is a personalization company. A personal human stylist curates 5 pieces for you to try on at home. The stylist uses big data and algorithms to help.
  • Tune through feedback.
  • >Most retailers have broken feedback loops. No reason for consumer to share if too expensive, if didn’t fit right, etc. Need compeling self interest to give you data. Best way is if used to make experience even better.
  • Need to show trust nd use data responsibly to get data and get customer to continue to give you data

Hard to predict what computers can’t do. Ex: driving, understanding human speech

Freestyle chess – humans paired with computers being pure computers or pure humans. Use best of human and computer skills. Also had superior technique for how to use computers. Strategy matters!

Humans goo an interpretting query or suggesting things. Review edge cases of output.

choose your own adventure: chaos engineering – live blogging from qcon

Posted on by
Reply

State of Chaos Engineering
Speaker: Nora Jones

See the list of all blog posts from the conference

Known ways for testing for availability

    Unit test
  • Integration test
  • Regression Test
  • Chaos Engineering – much less common. Doesn’t replace need for “traditional” tests

Chaos Engineering

  • Most people know what Chaos Monkey is; far less know about Chaos Engineering. The former is a tool’; the later is a strategy. The former is mature; the later is emerging
  • “chaos” means different things to different companies. Common things: experimenting, distributed system, make system stronger through experiments
  • Goal is to run chaos all the time, not just on deployment

Why to start

  • Can’t keep blaming your cloud provider. Need to own failure
  • Failures will happen anyway. Why are we afraid of that?
  • Computers are complicated and they will break

“Chaos Carol”

Introducing chaos

  • think about where you are now and expected response
  • How many people should know the chaos is intentional? Helpful to know running an experiment.
  • Define “normal” system and behavior
  • Relate chaos to automated tests, SLAs and customer experiments
  • Start in QA, not Prod. This estabilishes a baseline
  • Only run during business day

Ways to create chaos

  • Start small – graceful restarts or degregedation
  • Randomly turn things off
  • Recreate things that have already happened – good once reach a steady state

Culture and implementation

  • People need to understand revealing problems is good (vs causing problems)
  • Start with opt in so people have control
  • Monitoring is important. Use dashboards to communicate
  • Automatically shut down experiment if goes too far astray
  • Have your incident/Jira/PagerDuty tickets gone down
  • Don’t forget about your company’s customers. Focus on business goals and not causing customer pain

Cascading failure

  • Try later on
  • Start in QA
  • May fail in unexpected ways – the tool broke QA for a week
  • Problems lie dormant for a long time

Testing

  • FIT – Failure Injection Testing
  • F# library: https://github.com/norajones/FailureInjectionLibrary
  • Types of chaos failures – exceptions, latency
  • After FIT, focus on minimizing blast radius and concentrating failures
  • Targeted chaos – important to have a steady state before introduce so know what caused by introduction

The choose your own adventure was a fun series of choices to think about viable options. Or not viable in some cases.