My notes from Droidcon London 2019

October 27, 2019

Danielle Emma Vass

Danielle Emma Vass

Cover picture Photo by Pathum Danthanarayana on Unsplash

This year I was very thankful that my employer Pusher sponsored my ticket to Droidcon UK 2019! These are the notes I took at the different talks I attended:

Keynote: Coding Like an Althete - Christina Lee

Christina spoke to us about the similarities between athletes and programmers (who she then refers to as Brathletes as we're using our brains), and some things us brathletes can learn from athletes.

Things I learned:

  • Programmers are more like athletes than I thought; we have team uniforms, we announce when we're leaving and joining new teams, we get compensated $$$, our managers want to get the most out of us.
    • But we don't really have coaches :( Some companies offer nutritional coaches, but what about other crucial performance enhancing elements like sleep?
    • Programmers often only get career feedback once a year - not after every game like sports people.
  • The Monday Morning Quaterback - on monday they look at the game that was played on the weekend to work out everything that went wrong so they can determine which pieces they want to focus on to improve for next time.
  • People don't pursue passions, they do things they're good at which in turn makes them happier. People who have been in a role longer tend to be happier with that role.
  • Sleep is super important. After being awake for 19 hours straight you have the same symptoms as someone who is drunk.
  • Flow is important for people to feel satisfied, less stressed, and perform better but our current offices and ways of working are set not set up to help this. On average people switch tasks every 10 minutes, and half of those switches are self imposed.
  • 5 tips to improve things
    • Make your whole day as flow - schedule time for interruptions / twitter
    • Train your memory - your memory is a muscle - concentration can be grown
    • Block like tasks together to minimise attention residue
    • Write down unfinished tasks - make a plan on how to finish these which reduces the attention residue left by switching tasks often
      • Create a shutdown ritual to transition out of work mode - free time is crucial!
    • Break down large goals into smaller goals - instead of thinking I want to be like Jake Wharton start with I want to understand how build systems work

Supporting Each Other: Growth for Juniors and Seniors - Lara Martín

Lara spoke to us about the similarities between growing junior developers and senior developers, and that both seniors and juniors receive immense benefits from working together.

Things I learned:

  • Focus on the good things people bring and not on all the new things they need to learn. Maybe they had a previous career before joining - are there any things there that could be useful for your team?
  • Both juniors and seniors should be continuously learning.
  • Don’t just criticise but offer suggestions. Criticism should always be in private and praise should always be public. Code reviews are in the public sphere.
  • Be open about what things you don’t know - by opening up other colleagues might also open up that they also don’t know and everyone can learn together
  • How can you help a junior learn, be specific about starting starting tasks - they can work out and check back with what they think they should be doing → ask for guidance if they get stuck

Safe Kotlin - Marcin Moskala

Marcin spoke to us from a chapter from his book, Effective Kotlin, about how to build safer applications in Kotlin.

Things I learned:

  • Mutability - avoid accidentally exposing underlying objects in interfaces - use copy to ensure that the returned item is actually immutable
    • e.g. if your interface has a mutable list of contacts, don't return it when someone asks for all the contacts as they could accidentally add to it themselves.
  • Libraries should explicitly say what types they return, and not infer from what is actually returned
    • e.g. if you have a car interface that defaults to returning a FiatCar object instead of the parent Car object!
  • Use require to check expectations on inputs
    • also you can use check() and checkNotNull()
    • assert is not just in test - we can do that in our runnable code too!
  • Use standard errors over custom errors e.g. IllegalArgumentException instead of a custom error. Other programmers will know how to handle the standard errors better than a random list of custom errors.
  • Offensive programming - explode loudly when something is broken!
  • You need to use both offensive and defensive programming for a safe system design. Context of when to use either is important e.g. a developer failing to initialise a library should explode loudly so the developer knows to fix - however when the library in a production app it should be defensive so that the developers customer doesn’t experience any issue.

Keynote: Get Happy, Get Known, Get Paid - Stacy Devino

Stacey gave us a very energetic talk about how we can get happy, get known, and then get paid!

Things I learned:

  • Love yourself - how can anyone else appreciate you if you don't appreciate yourself!
  • It's okay to say no to things you don't want to do! It opens up your time for saying yes to the things that really matter.
  • Invest in yourself! Ensure you have the best tools for your traid you can afford e.g. a comfortable keyboard, a great chair.
  • Invest in those core/soft skills - skills such as communication are going to be very important as you climb that career ladder.
  • Ensure you have a personal "brand" - what makes you special? Doesn't have to be 100% tech focused. Keep your public social media platforms consistently "on" that brand.
  • Be authentic but also display the best version of yourself. Presentation matters!
  • GitHub all the things you've been working on - even failed projects. It demonstrates to others that you're keen to learn and try new things!
  • Work out what your leadership style is (DISC with a facilitator) how you can get the most out of that style, and what weaknesses you need to be aware of.
  • Hire a career coach to help you work out where you want to go with your career that align with your personal goals too!

The Light Way - Lisa Wray

Lisa spoke to us about how Facebook Messenger Lite works, and why they've chosen their to build it that way.

Things I learned:

  • Messaging has to work offline. Not everyone can be online all the time as it uses battery / data / time to be around.
  • You need to work out out what’s important to measure for your customers. For Messenger Lite that was apk size / startup speed.
  • They used the Database First architecture pattern
    • Transform the data received from the API before it goes into the DB on device - the UI is then simply a wrapper around the DB.
    • Transform on the server can reduce the complexity on the app e.g. creating the group message title. This has the added bonus of that it can then be consumed multi platform!
    • Time proximity handled in the transform is important. To create the message bubbles in FB messenger they use a bitwise mask to represent how it displays based on the message before and after to see if they’re part of a series of messages in close time proximity
    • Complexity is moved to the DB layer not the UI
    • You have to be careful you aren’t constantly writing / reading to the DB when people aren’t using the device if there’s a conversation that’s very noisy
    • Infrastructure should not depend on other infrastructure

The Android Chef - Anastasia López

Anastasia spoke to us about career advancement for chefs, and how there are parallels in expectations between chefs and programmers as we advance our career ladders.

Things I learned:

  • Commis Chefs (Junior developer) are expected to not know everything, will make mistakes, but ask lots of questions!
  • Chef de Partie (Mid developer) are expected to take responsibility for their work, operate more autonomously, and look for things to improve in the team.
  • Sous Chef (Senior developer) are expected to know when to intervene if someone needs support, start planning the menu (or the teams work), mentor more junior team members.
  • Chef de Cuisine (Lead developer) are expected to set the culture and change things.
    • There's a difference between advocating and sponsorship.
    • Take time to find your cognitive biases (there are good resources online for this).

Improve your code with Lint checks for Kotlin - Emma Tresanszki

I attempted to hear Emma speak to us about how to improve our code with lint checks. Unfortunately the room was so full that I ended up not being able to see the presenting screen.

Things I learned:

  • Droidcon London need to think about getting bigger rooms for the "smaller talks"
  • Klint - Pinterest have open sourced their linter which you can use. Mostly suggests formatting how code looks rather than how the code works.
  • You can easily write your own linter e.g. maybe as a team you decide never to use lateinit var and you want the build to fail if one is introduced.

Finally, where would we be without the friends we make along the way?

Recent Posts