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.
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:
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.
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:
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:
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.
Paula also wrote a blog post with a summary and some resources.
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:
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:
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:
For building rituals, you want an emergency toolkit for when you’re in a bad moment. This might include:
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.
What’s the definition of ethical technology?
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:
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:
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?
If you say “junior”, what are you suggesting? You’re saying that:
You only have permission to learn if you’re:
This is a false dichotomy.
Here’s how to build a structure for learning:
Provide context for problems:
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:
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.
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?