I recorded this talk for the previous round of LeadDev Together. You can access it here (requires signup).
All the penguin imagery in this talk are photos my mom took in Antarctica.
Tag: talks
-
Preparing a Talk in Pieces
Preparing talk can be really overwhelming. As a rule, I expect to spend an hour preparing for every minute I spend speaking. When a slot gets over 30 minutes… that starts to look like very nearly a full working week. This is an intimidating amount of time to find and clearly being organised and starting early is key.
Step 1: Topic
The beginning of any talk – what is something that I think I can prepare something about, that will be interesting, useful (and entertaining!) to the people watching it? This normally starts from conversations with friends or at work, usually things that I turn into blogposts to test whether people will be interested. Generally I start thinking about a topic the year before I expect to give it.
Step 2: Structure
This is always the hardest part for me, and until I have figured this bit out, I have no idea where to “begin”. How am I going to break the topic down? How will the pieces build upon and relate to each other? Like a UI, I build my talks on grids so this bit is really important.
Normally I figure this out on a long walk – or six. I spend weeks thinking out and angsting, carve out time to wander around (or swim!) and think about it. And eventually it becomes clear and I frantically drop it in a Simplenote document. Phew.
Because I have someone else make my slide decks, at this point I can get them involved in putting the deck together. My MVS (minimum viable slides) are one for each point in the structure, and a template for any other data or photos I want to show.
Step 3: The Pieces
Once things are broken down, I have less-intimidating pieces I can think about individually. For the talk I just prepared (YOLO Releases Considered Harmful) I wrote a blogpost about each section and published one a week in as I prepared. This meant I was carving 2-3 hours for each post, getting the ideas out and getting feedback. It meant even when everything was hectic and I felt like I didn’t have the time or headspace to think about The Looming Event, I could still feel like I was making progress on it.
Step 4: The Intro
This is where things start to feel overwhelming again. I try to step back from the pieces and remember why I wanted to give this talk in the first place. What does it have to offer this audience? How can I make it clear that I am a good person to give it, but subtly, because I will never get on stage and recite a list of accomplishments. How can I introduce the metaphor that ties the whole thing together?
This bit keeps me awake at night talking to myself (very healthy). It’s another time to take a long walk -or go swimming! Last time I felt like I broke through this bit on a day when I spent ~5 hours walking all over Milan.
Step 5: Putting it Together
Now I need a bit more headspace to put things together and think about it as one thing. I put all my pieces in a document, add my intro, and start going through it. At first I read it normally, but soon move to reading it aloud. Is this the way I would say it? Does it flow? I edit it to make it flow, to remove things that are unnecessary, and start putting it with my slides to see how they go together. I check my timing to make sure it’s looking reasonable, and figure out what extra slides I want.
Step 6: The Ending
Now that I’ve looked at it all together – how do I finish? The ending needs to tie it all together and connect to the intro. A good time for another long walk…
Step 7: Practise Practise Practise
The most important bit! I give my talk again and again until it seems natural.
-
Upcoming Talk on Effective Mobile Engineering Teams
I’m working on a talk about running effective mobile engineering teams – I’d love to know what questions you have about this, what you worry about when it comes to mobile teams in your organization, and what you’ve found most helpful to communicate about them. Comments or email or DMs on Twitter welcome!
Title: YOLO Releases Considered Harmful – Running An Effective Mobile Engineering Team
Organisations often worry about their mobile teams. Sometimes they are a bit separate. There’s often this inexplicable hostility to mentions of “React Native”. Why do bug fixes take so long to get to production, and what are all these certificates for, anyway?
In this talk we’ll cover the realities of shipping compiled code, the woes of the app stores, and the infrastructure challenges we haven’t figured out yet. You’ll leave with a better understanding of the realities your mobile teams may be struggling with, and some strategies for how to help them – and your organisation – build an effective mobile team that ships regularly. And yes, you’ll finally understand the React Native argument, too.
-
#iOSDevUK – Luke Rogers: The Logic of App Design
Credit: DeviantArt / michexist Design is a skill you can learn, the same way development is a skill you can learn.
Design is not about making it look pretty, small percentage of it. About working out hierarchy, working out what is important.
Brainstorm what the user should be able to do.
- Not “have analytics”
- Instead “watch a video”
Order it, figure out what is most important. Useful later on in forming the importance in the UI.
Cut out features that you can leave out of v1 at least.
Study other apps. “Good artists copy and great artists steal”, “everything ia a remix” – Kirby Ferguson.
Idea that being creative means having original thoughts. We all sample consciously and unconsciously all the time.
Broaden the way you think about the problem. Most apps are just organising information in a structured way. Can pull from a wide range of apps.
iOS look almost exclusively designed by Apple. Android, almost exclusively apps designed by google. They know the platform best and have thought about it a lot.
Search is an interesting thing to study on iOS. Messages app has hidden search bar, have to scroll. Similar location in email but initially visible. App store and podcasts put search in the tab. Seems inconsistent, but with good reason. Depends on how central use case it is. Main task in app store, less common task in messages.
Reuse is good “things that look similar are similar and should behave in a similar way”.
One have a wireframe, can move to the computer. Like Sketch, more for app design. 35GBP one off purchase.
Not all of your design needs to be exciting. Some things should be functional above everything else.
Nothing is set in stone, everything is iterating the whole time.
Familiar button, because traced over a similar one. Means user are going to understand.
Prototype in keynote. has some great features, helping mock up transitions. Can export a mob, make the size the same as an iPhone screen, make a clickable PDF with clickable buttons. You can run it on your iPhone or iPad.
Keynote iOS is landscape only, need to do everything at 90 degrees. But worth it to get something you can give to people to play with.
Also, XCode. Exported central image and made it scrollable. Can look and see how it would behave.
Consider empty states. What happens when things (e.g. location) are turned off. For error states, look at what other people do. Important when things are going on that users don’t feel frustrated or lost.
Important to get feedback throughout the whole process. Beta testing. Not just about ironing out bugs, also about taking on user feedback, finding out what is confusing them, and being prepared to change stuff.
Valuable time to sort things out before launch. After launch, make sure you have a way for the user to send you feedback. Users invest in the product, make it easy for them to send you feedback. Inform what is important in the next phase of the app.
Process:
- Brainstorm
- Study and remix
- Rough sketch
- Mockups
- Prototype
ITERATE
Principles:
- Focus on structure
- Sample and remix
- Don’t be arrogant – don’t think you know better, listen to feedback. don’t have to implement everything but take it onboard and consider it.
-
Valerie Taylor – Keynote at GHC 2013
Starts with comment that the 1994 GHC had 600 attendees, it’s wonderful to see it at 4800.
Visited Anita Borg because of research, talked about GHC. Talked about under-represented groups. First Systers of colour. 10-15 women talking about Systers of colour.
First GHC was the first conference that was technical, but at the end of the evening, they danced.
Systers of Color started as a small listserv, wasn’t very active. But in 2004 in Chicago, the women of colour luncheon had over 100 participants. So they had gone from 15 to over 100. Great to see the many different communities at GHC.
There are differences in groups, but some commonalities, at the San Diego WOC lunch they talked about issues – women from Indiana and women from India both talked about accents. Found commonalities in the issues.
What is meant by cultural diversity? Diversity – culture of human behaviour that honours people for who they are, what they know.
Made many mistakes. Reflect on conclusions – three things. Engage, Embrace, Enhance.
Engage – taking time to learn about others. Tells story of going on a hike with Anita and realising that Anita was learning from her, culturally, and about her background.
Embrace – embraced her background, embraced her whole self.
Enhance – embrace others, get something bigger. Need to not isolate or leave people out when you get them in the room.
At Purdue, there was herself, a white male, and a male from India. The white male asked her if she was from the projects? No. Was she first generation? No. Was she in a gang? No. Eventually he asked what was her background, and was sorry for asking the way he did – that was all he knew. They talked about his background too, and became good friends.
Did mediation training as a Texas A&M department head. Thought that mediation training was about resolving issues between conflicting patties. But actually, mediation is getting conflicting parties to come to their own solution.
Learned that conflict is about emotion. “But that is not logical, why do you feel that way?”
Language – the adjectives you use, the difference between saying “good question”, and “wow, excellent question”.
Learned what it really means to listen – repeat what someone is saying.
It’s really important when engaging someone to learn about their background and experiences.
Talks about a specific project, a collaboration on performance and power modelling, (to do with) top super computer – 17 megawatts. Needed to first learn about each other, and build a common language.
Her mother’s advice – “let’s work with what we have”. Others want to ask for more – have to find a middle ground.
Having International students, some of them have the background where it is inappropriate to question their elders – and she is considered an elder. To embrace/enhance that, has students present with each other. Saves her comments for last – so they are not seen as the answer. Wants everyone to have the opportunity to speak and ask questions.
Talks about workshops, starts with the discussion, for the hearing impaired, look at the person not the interpreter. Slides, leave up for a minute before talking, so that the hearing impaired can look at the slide, then look at the interpreter.
Name, comment, and question start a discussion. This makes it more engaging – good for everyone involved.
Job change, with very little transition time or overlap with predecessor. Began to respond, realised that she hadn’t taken time to engage with staff. Looked at how to engage everyone in the unit, which has been more fruitful.
Maya Angelo said “We all should know that diversity makes for a rich tapestry, and we must understand that all the threads of the tapestry are equal in value no matter what their color.”
Everyone brings unique experiences and background to that tapestry.
Everyone brings something unique to the conference and field.. Challenge is to take time to engage in dialog, learn about background and experiences, use new knowledge to enhance what you’re doing.
Evolving as we add diversity to the field of computing.
-
Pycon AU: Planting Open Source Seeds
Credit: Flickr / AJITH ACHUTHAN I found this talk by Kenneth Reitz one of the most interesting at Pycon. There was a comprehensive breakdown of the different strategies people take to create and nurture (or not) open source projects, and tales from maintaining them. You’re probably better to just read Kenneth’s notes, but for what it is worth – here are mine!
Started with the story of the Facebook SDK which allowed developers to access Facebook APIs from Python. It was rarely updated, and one day just stopped working. So developers opened issues, and it ended up on hacker news – the issue got 50 comments. So… Facebook disabled the issue tracker.
This was the worst possible scenario. The project wasn’t open source, it was public source.
Public Source: Company puts out a chuck of code with an Open Source License on it, hoping that it will be useful. This is better than closed source, but can easily end up abandoned due to lack of interest or change of focus. The motivation for sharing is unclear.
GitTip is a platform for sustainable crowd-funding. It takes open-source to the extreme, striving to be the world’s first truly “open company”. It’s run by Chad Whitacre who said “I’m not building Gittip. I’m building a community that’s building Gittip.”
Extreme Open Source means:
- There’s a GitHub issue for everything.
- Major decisions are voted on GitHub.
- Interviews with journalists are live-streamed.
- All formal discussions are publicly documented and shared.
Shared investments: Shared ownership, and extreme transparency. New contributors can follow a documented process. It is low-risk, with a high bus-factor.
Requests is HTTP for humans – one of the most installed PyPI projects. It’s different because project decisions are made by Kenneth (the owner).
Dictatorship project: Totalitarian “Benevolent Dictator for Life” (BDFL) owns everything. They are responsible for all decisions. Feedback is encouraged, but users shouldn’t have any expectation of change. Their extreme opinions will guide the project, and they will be able to make quick, precise decisions.
Downsides: Low bus factor, risk of burnout is high. If the BDFL loses sight of goals, the project will be ruined.
Lessons from a Dictatorship Project
Be cordial or be on your way.
Contributors:
- Be as respectful as possible.
- Remember, they don’t owe you one moment of their time.
Maintainers:
- Be thankful.
- Contributors are the lifeblood of your project.
- Ignore non-constructive suggestions.
- Remember that some people take things too seriously.
- Be cordial.
- Contributors take what you say personally.
- Take the opportunity to educate the user.
- Remember, you could be their first interaction with an Open Source project.
- A little kindness goes a long way.
You could be their first interaction with an Open Source project – this is a really important point! Don’t scare people away from Open Source!
Burnout
Sustainability is the biggest challenge in Open Source. Everyone has limited time, and it is easy to become a bottleneck.
Wesley Beary: “Open source provides a unique opportunity for the trifecta of purpose, mastery and autonomy. By recognising the power of these factors, we can keep ourselves motivated and continue to increase our impact.” (Worth reading the entire article there).
Learn to do less. Lead-Contributors triage issues. This saves a lot of time. Focus time on larger issues, and help make the best of their time and efforts. Faster for contributors and users – only good things happen.
JUST SAY NO.
This is really difficult. Sometimes people send crazy features disguised as practical pull requests – they are trying to help. But it is a use case, not for library. If you say yes too often, the project will be ruined – tragedy of the commons.
Pieter Hintjens: “Simplicity is always better than functionality”
- You cannot support every use-case, look for the 90% use-case, not the 100% use-case.
- If a new pull request adds complexity – say no.
- Plugable, modular system – pass it in as an argument, and everyone wins.
- Simple code is good.
- Code solves problems created by humans.
- Less code = less to maintain.
- Negative diffs are the best diffs.
- Complex code is bad.
- Tight coupling.
- Technical debt.
- High maintenance.
- Self-serving, rather than project based.
Open Source makes the world a better place – please don’t make it complicated.
Audience Question: “Is forking ever a good thing?”
Answer: Sometimes – see Hudson/Jenkins – forking might be required for political reasons. But don’t fork instead of contributing, talk first.
-
WISE Talk: 3 Things That Make Me Luckier
Commentary (I didn’t have slides) for the talk I gave for UO WISE.
I thought I was going to come and have an informal chat about how interviewing at Google is not that scary, and then I saw Krystal’s tweet.
[blackbirdpie id=”55757050474532864″]
I freaked out a little, to be honest. Like, woah – I need to be inspiring? I don’t feel inspiring!
The thing is, I used to help organize these talks, so I know what I used to look for out of them.
Life advice.
Because I’ve long felt that if I had more information, I could do better at life. We had some great speakers, and I got some very useful advice. But – I do not feel qualified to give anyone life advice. Because honestly, I think that any success I have comes down to working really, really hard, and being lucky.
The thing is, there have been studies of people who consider themselves “lucky” and some interesting observations have came out of it, from an article in the Times:
I gave both lucky and unlucky people a newspaper, and asked them to look through it and tell me how many photographs were inside. On average, the unlucky people took about two minutes to count the photographs, whereas the lucky people took just seconds. Why? Because the second page of the newspaper contained the message: “Stop counting. There are 43 photographs in this newspaper.” This message took up half of the page and was written in type that was more than 2in high. It was staring everyone straight in the face, but the unlucky people tended to miss it and the lucky people tended to spot it.
Which tells me that lucky people see things that unlucky people don’t. So, I’m going to talk about three things that I think make me luckier.
- Get the right people on the bus.
- Gaps are opportunities.
- Bravery is not always what you think it is.
1. Get The Right People on the Bus
Credit: Aires Dos Santos / http://www.fotopedia.com/users/airessantos In Good to Great (Amazon), this is identified as something that good companies do, to take them to great. They get the right people on board.
I also think it’s true of yourself. Who’s on your bus? Are they the people you want on there? I think we’ve all been there, whether it’s the drama junkie, or the drunken friend who you carry home every time you go out.
For a while, I was hanging out with the wrong kind of people, and I started changing that. It was amazing how much happier I was, how much more energy I had, and how much more I got done. The drama was hugely affecting me, for all I tried to stay away from it. We’re hugely influenced by the people we interact with. It’s important that they are good people.
2. Gaps are opportunities
Credit: flickr / Darkroom Daze Wherever there’s a gap, somewhere where you think “that should be happening”, but it isn’t – I think that’s an opportunity. To do something, to create something, to bridge a gap. The most exciting things I’ve done have come out of gaps I’ve seen.
3. Bravery is Not Always What You Think It Is
Credit: xkcd People said I was brave to move to Canada. The truth was the opposite – I was afraid to join the real world, so I hid from the real world in grad school. Now I live in the real world, I wonder what I was afraid of. Seeing someone else as brave is not the full story, you don’t know what they’re running away from.
There’s that quote, it was in The Princess Diaries (Amazon), but originally by Ambrose Redmoon.
Courage is not the absence of fear, but rather the judgement that something else is more important than fear.
What this means to me is that being brave doesn’t mean that you’re not freaking out. I freak out all the time. Every time I start a new adventure. Every time I stand in front of a bunch of people to talk about something. Every time I’m somewhere where I know no-one. Every time I hit “post” on something that is non-trivial and honest.
It’s easy to say, X is braver than I am, I could never do that. It’s a cop out – people can be brave in different ways. People think I’m brave because I say “yes” – but I think people who say “no” are brave, they commit to one opportunity when I hedge my bets with many. They are not as terrified of missing out as I am.
Anyway, I don’t think being brave means you have to be sure. I don’t think it means that you don’t get to be really scared. It definitely doesn’t mean that you won’t push yourself. It doesn’t mean being unrealistic about chances of success – or failure. Being brave is seeing all that, and deciding to go ahead and do it anyway. For the hell of it, or for the challenge, or for the adventure. Or, for me, because I’m too afraid to say no.
But these are just my three things, and like I said, I’m completely unqualified to give life advice. So pick and choose what you think is worth considering, and then make up your own list of things that make you lucky.
-
#TEDxWaterloo
Credit: flickr / Trevor Haldenby (from TEDxWaterloo 2010) My mind was blown at TEDx Waterloo – the Uncharted – on Thursday. Seriously, it was SO AWESOME. I was extremely excited and it was more awesome than even I had prepared myself for.
Vincent John Vincent (from GestureTek) talked about gesture-based computing. It’s incredible what they’ve been doing and for how long, and made me think about the implications of the Kinect – the start of affordable, gesture based computing.
Michael Nielsen spoke about the Open Science movement. I really loved this talk, because I agree that research, particularly publicly funded research shouldn’t be locked away. It should be as open as possible. We need to have a culture change, where the rewards of publishing a mediocre paper do not exceed the rewards of furthering human knowledge through open initiatives.
Shelley Ambrose spoke about the need to have “curious” conversations, particularly her experience in selling Canada to New Yorkers. Her talk was a reminder that we communicating is more about listening than talking.
Colin Ellard gave an amusing talk about how we come to get lost, and our relationship with space.
Miriah Meyer talked about visualization in biology. I really loved how she talked about taking an engineering approach to visualization.
Shawn Qu spoke about solar power and reusable energy.
Ben Grossman played a hurdy gurdy.
Jean-François Carrey was the youngest Canadian to climb Everest. His dedication to achieving that goal, and the ways he went about it made for a great talk. “I put it on a t-shirt so then I had to do it”, was pretty memorable. But the things he had to say about your support network, and getting people to buy in to your goal were great too.
Abby Sunderland told the story of her around the world attempt. This girl is seriously cool, fixing boats and attempting something that ambitious. The way she spoke about dealing with failing (I’m sure there’s a different perspective on failure when you nearly die), was very down to earth. Rogue waves will hit, and you’ll have to deal with it.
Vicki Keith inspired with her tales of teaching and of setting – and achieving – crazy, audacious, hairy goals. This woman is a legend, I cannot at all comprehend swimming butterfly for 80 kilometers (and over 63 hours). And it all started with an obnoxious ballet teacher and this search for something she could excel at. I love it! The advice about starting being the hardest part, and creating your own reality in which you goal is possible, even if it seems impossible to others, was uplifting.
Roberta Bondar was hilarious. I laughed so much during her talk! But the way she related the change that astronauts find on their return to earth with our ability to respond to change and challenge in other areas was really cool.
Edwin Outwater talked about Rebel music, illustrating his points with a live band on stage. Pretty awesome!
I feel inspired, and invigorated, and really grateful to be living in #wrawesome. So many cool people – not just the speakers, but also the attendees. This is a really amazing place to live!
