Notes from You Got This 2019

Posted 28 January 2019
Tagged with conferences

About a week ago, I was at You Got This 2019, a conference that bills itself as an event for “juniors on skills needed for a happy, healthy work life”. I’d seen the schedule on Twitter, thought it looked interesting, and decided to attend on a whim. All the topics had a strong focus on wellbeing, not technical content.

This post has my lightly edited notes from the conference and the sessions.

General vibes

Everybody I met was friendly and nice.

All the talks were good, and perhaps more notably, consistent. Usually when I go to a conference, there’s at least one or two talks that leave me feeling a bit “meh”, and that wasn’t the case here. Every session was interesting, well-presented, and left me with at least a few new ideas.

The emphasis in the introduction was that these are “topics we should be talking about more” – which is precisely why I decided to go.

I care a lot about running inclusive events, and have a long list of ideas for doing so. For a first-time conference, I was pleased by how many of them they hit:

When I arrived, I was asked if I was happy to appear in photographs – and if not, I could wear a bright yellow lanyard. In the introductory remarks, we were all reminded not to take photographs of people with yellow lanyards.
All the food was vegan and delicious (except the milk for the coffee, I think), including ice cream in the afternoon break. They said several times “if you have other allergies, talk to us”, so I’m assuming other food was available if you couldn’t eat the default options.
The Code of Conduct was prominently featured in the signs, tickets, and the introductory remarks.
There was a dedicated quiet room.
All the talks were live captioned by somebody in Scotland, who was even kind enough to engage me in a brief conversation on their screens.
The ground floor bathroom was gender neutral, and had free sanitary, dental and haircare products for people to take. Apparently this is a feature of the Monzo offices, where the conference was held – very nice indeed! Sanitary products are the most important, but dental and haircare are useful too, and a new one to me.
The entire day was MC’d by Scary Boots, who helped warm up the audience, support the speakers, and keep us all laughing. Especially notable when somebody was having A/V issues.
There was an inclusion programme, including a variety of scholarships for people who couldn’t afford tickets, travel or childcare. And when I bought my ticket, there was an option to pay over the ticket price, contributing to the scholarship pool.

And here’s some stuff that felt a little odd:

I only saw a handful of name badges, and mostly on speakers, who are more likely to be recognised. I’m not sure why they weren’t given to everybody.

The badge design itself was quite good – rather than pre-printed with wallet names or companies, they were blank with a large space for “name” and “preferred pronouns”.
I’m told the venue was wheelchair accessible, but I didn’t see anybody using a wheelchair. The food and breakout spaces were downstairs, and I assume there was a lift, but I didn’t see it. (Better signposting!)

I also felt the spaces were a bit small, and felt crowded during the lunch break.

No conference gets inclusivity perfect, and the gold standard for me is still AlterConf London – but this was pretty good, overall. I’d happily attend again.

If you read the post and think sounds interesting, there’s a sequel planned for January 2020, with a mailing list on the website.

The talks

These are based on my handwritten notes, which are the bits I found most interesting, not a comprehensive summary of the talks. They’ll give you a flavour, but they’re not a substitute for watching the talks.

Impostor syndrome, perfectionism and anxiety, by Jo Francetti

She started with a story of “Mo”, a young developer who was feeling overwhelmed at work, and the sort of things she was feeling. Wondering if she knows enough, if she’s being judged by her co-workers, overworking and ruining her mental health. It was a good way to set up the topic – a sort of “Do you recognise this?” moment.

Editor note: I was wondering how she chose the name “Mo”, and can’t believe it took me to now to spot it.

There are some common issues, which she went through in turn:

Impostor syndrome. An explanation of what it is, how it manifests.

A new concept to me was pluralistic ignorance, in which nobody believes something, but everybody believes that everybody else belives it. For example, nobody believes that a task is easy, but everybody believes that everybody else finds it easy, and thus impostor syndrome sets in. (“Everybody else finds this easy but I can’t do it.”)

Another new one on me: Schrödinger’s impostor syndrome. The contradiction of

My peers are all more intelligent and accomplished than me.

and

My peers are so gullible that I’ve tricked them into believing I’m one of them.

Open and frank conversations around our challenges can help combat impostor syndrome.
Perfectionism. Expresses itself as catastrophic thinking (an alternative wording to “black and white thinking”), paralysis and procrastination. The result is anxiety, overwork and stress.

We need to remember that perfect is the enemy of good – we’re not expected to come up with a perfect answer every time. If you give yourself time to solve a problem (with an explicit deadline), you can work through it.
Anxiety. Don’t neglect your mental health! Be kind to yourself, and don’t just look externally for validation (it’s fleeting).

Knowledge sharing can take many forms: blog posts, answering questions, speaking at conferences.

A big part of this talk was Sascha talking about his struggles with depression and exhaustion, and what felt a lot like burnout. (I don’t remember if he actually used the word “burnout”.)

He talked about how he built a new frame of mind, and that “we’re more than just a walking tech stack”*. In other words: we shouldn’t define ourselves solely by our technical work or our technical skills. As part of that, he talked about his experiences with therapy, which made me happy. (I think therapy is a really useful tool, I’ve been to therapy multiple times, and it’s good to hear it discussed on stage.)

A key attribute of a successful team is psychological safety – people feeling like they can take risks, and b supported by their team.

“Tech enables us, but it doesn’t define us.”

How to find knowledge you can share:

Keep a TIL (Today I Learned) record
Focus on learnings, not failures
Ask colleagues what they’d ask you about (i.e. what do they think are your areas of expertise)
Document the journey, not the goal

I really liked the framing of this talk: the introduction was “Hi, I’m Sascha”, and a list of technical skills and background. Then at the end of the talk, another slide “Hi, I’m still Sascha”, which had a similar list that covered much more of his life.

There is more to you than your profession.

Where did all my money go? by Paula Muldoon

Notable for starting and ending with a violin recital. (Although not the first time I’ve heard music on stage at a tech conference!)

Some general advice:

Budgeting is useful
Have a spreadsheet of your main expenses
You Need A Budget is great
You can say no to something (like a dyed yellow lab coat, or candles)

If you want to get your spending under control, there are two key steps:

Understand your beliefs about money.

For example: “I’ll never have enough money”, “I’ll always have enough money” or “money is evil”. You might believe all, some or none of these – whatever, knowing your beliefs is useful.

Some useful resources:
- The Seven Stages of Money Management
- The Profit Boss podcast (especially for women)
Talk about money! It's often a taboo topic.
Take some practical steps.

You want to understand your current money habits – but exercise self-compassion. Don’t beat yourself up over everything you think you’re doing wrong.

Suggestions:
- Have a spreadsheet. Calculate all the numbers: exactly how much you're earning each month, and your regular bills (rent, utilities, tax, etc.). What's left is your budget.
- Automate everything. If you have to remember to pay bills, there's a risk you'll forget and take a hit to your credit rating.
- Max out your workplace pension. (Note: I scribbled down "needs research" next to this, because I'm not sure how I'd do this, what it means, and suspect the best thing to do with pension stuff is probably more complicated than simple.)
- Use bank accounts that help you track your spending, like Monzo or Starling.
- Get free credit reports from Experian and Equifax.
- If you have a credit card, keep your credit limit at an affordable level. (I've heard conflicting advice on this one. My credit limit is several times my monthly salary, and I rarely max it out -- but by paying it off regularly it's slowly inched up, and might be useful in an emergency. Hasn't bitten me so far.)
- Advanced moneying: have side gigs, negotiate a pay rise.

Paula also wrote a blog post with a summary and some resources.

Junior.next(), by Tara Ojo

Slides: https://speakerdeck.com/tyeraqii/junior-dot-next-yougotthisconf

I love the phrase “career crushes”.

Everyone has to start as a junior, so how do you progress?

If you’re a junior looking to progress:

State the obvious (both as a way to affirm what you already know, and spot subtle mistakes in understanding)
Collect evidence of your progress, celebrate your achivements
Teach other people, stretch yourself
Share your opinions
It’s okay not to know (and to ask for help)

There’s a sweet spot of “stretch” between comfort (easy, minimal learning) and panic (bad, a source of stress) – that’s where you want to be.

You want a mixture of base knowledge skills and depth in specific areas.

If you’re a supporter trying to help a junior:

Mentor your junior
Create opportunities for them
Give regular feedback. Good feedback is specific and achievable, e.g. do more/less of X, start/stop/keep doing Y
Pairing sessions
Ask open questions that let them show their understanding, and give the opportunity for further discussion
Invest time in them

Self-care beyond the hashtags, by Taylor Elyse-Morrison

Looking at the #selfcare hashtag. What is it?

Taylor is a “ritual builder” – helping people build rituals.

In order to care for yourself, you need to listen to your body. You want stillness, observation, reflection. Be consciously aware of your body.

When you reflect:

Pick an interval
Ask “When did I experience tension?”
Ask “When did I feel supported?”

For building rituals, you want an emergency toolkit for when you’re in a bad moment. This might include:

Breathing exercises
Calling a loved one
Get outside and experience nature
Dance
Craft
Writing or journalling
Giving thanks

Self-care means listening to your body and responding in the most loving way possible.

Our self-care needs will change with time, so keep listening and responding.

Morality and ethics, by Sam Warner

What’s the definition of ethical technology?

At a minimum, it doesn’t make the world a worse place
But better, it should benefit the largest number of people in the largest possible way

Notions of good/bad are fuzzy; one possible alternative is effective altruism.

Tech is a relatively young and immature industry, but “we shouldn’t be ashamed of being immature if we mature well”.

A Stack Overflow survey (admittedly not representative, with “some demographic challenges”) – a majority of developers think they should think about the ethics of the software they build, but only a minority think the ultimate responsibility lies with them. We should be empowering developers to feel like they have that responsibility (and power).

Three principles of ethical software:

People come first
Create accessible and useful services for everyone
More diverse teams give better visibility ethical factors

We all make mistakes; what matters is how we get better. (The speaker used an example of Facebook – Mark Zuckerberg didn’t realise he’d create the monster he did – but some of the early iterations of Facebook were pretty sketchy, so I’m reluctant to give Zuckerberg a pass.)

A useful resource: the Ethical OS toolkit. A checklist of useful things to think about when building ethical software. (I wondered: does it cover online harassment and abuse?)

Things to think about:

Unethical software isn’t more profitable
Don’t hide behind contracts
You can make a difference (e.g. Project Maven, in which Google’s engineers successfully protested a contract with the US DoD)

Understanding and building independence, by Violet Peña

Slides and notes: https://violet.is/files/you-got-this.pdf

We are problem solvers.

Independence is the ability to understand and construct solutions. It’s not about working alone.

Here’s a framework for solving problems:

Have a plan.

Check you understand the problem: the data, the conditions, the unknowns.

Break your plan down into steps. How long will each step take? How can you track progress?

Be honest with yourself and your team. Are you progressing?

Be aware of how you’re performing. It’s okay to say “I need more time”, “I need more help”, “I need to do something differently”. (And she had us all say them out loud to get used to saying the words!)
Use your tools.

Use the tools you have, but don’t be afraid to change modalities; to try new tools or technologies if needed.

Find a related problem (similar data, conditions, unknowns), and try to solve your problem in a similar way.
Ask for help.

It’s a great thing to do: it builds your knowledge, shows your respect for your colleagues, shows you don’t have a massive ego.

You want to “build a Voltron” – a group opf people who can help with particular topics.

You should ask for help when you’re stuck, can’t get past a particular problem, or need a rethink.

The more certain you are somebody has seen this before, the earlier you can ask for help.

How do you ask for help?
- Give context
- Ask a specific question
- Tell them what you've already tried
- Thank them for their time/help

The power of junior developers, by Sam Morgan

Two topics:

Be suspicious of the word “junior”
Advice for people who want to support junior developers

If you say “junior”, what are you suggesting? You’re saying that:

Learning isn’t for everyone
You’re old school (there are some industries where being conservative about change is good, e.g. healthcare or aviation safety; this is not true in most companies)
You undervalue skills

You only have permission to learn if you’re:

Young
Early career
Not expected to deliver

This is a false dichotomy.

Here’s how to build a structure for learning:

Provide context for problems:

Run whiteboarding and diagramming sessions.
Link to the domain – every ticket should link to an end-user case.
Treat everything as a learning exercise
Provide your time and expertise to help people

Set goals:

Mentioned: A theory of goal setting and task performance, by Edwin Locke
What can I say about myself?
A good goal is specific, aspirational, expected and believed. (i.e., somebody else should believe you can achieve it, and then say so!)

Provide resources and help:

Provide a summary of reading, what you’ve learnt, prepared exercises. If a junior asks a question and you point them at a 400-page book, they won’t read it and they’re no better off – give distilled knowledge.
Be socratic, i.e., ask questions. Don’t just answer somebody’s question straight up: it robs them the chance to ever learn the answer. Instead, increase their power to ask questions, and lead themselves to the answer.
Build a link library of useful advice, tips, technical info.

There are several types of question somebody might ask/opportunities for learning, and they need to be treated differently:

Concrete. If the internet can answer it, ignore it – or help them find the answer themselves (e.g. “what is the JavaScript syntax for a function”)
Concepts. These can lead to interesting conversations and discussion (e.g. “what is a function?”).
Skills, processes, behaviours. These are learnt by pairing, observing, feedback (e.g. “what is a good amount of code for a single function?”)

Have a structure for feedback:

Require intentionality. Ask: What do you want feedback on?

This allows you to get feedback early, rather than waiting for perfect or completed specimens, and early feedback is better.
Keep it tight. Don’t overwhelm somebody with information, or provide comments on irrelevant areas.
Demand iteration.

When they’ve addressed your feedback, they should come back for more. The model of “get feedback once, then finish” is an odd one, and not so helpful (exams are weird).

A question for the junior devs in the room: how are you going to transform the businesses you work in?