Molly Struve had a long winding journey to SRE... and other things I learned recording her DevJourney

This week, I published Molly Struve's #DevJourney story on my eponymous Podcast: Software developer's Journey. Among many other things, here are my main personal takeaways:

Long winding journeys make up for the best stories!
Again, Molly's journey is a perfect example of how diverse the entry paths into our industry are.
All engineering domains have the same core disciplines of problem solving. Those skills are transferable. Don't assume that because you are not in the IT-Industry now, that you won't be able to break in tomorrow.
A quote I love: "Do what you love, the rest will follow"
And another one: "we are creating things everyday, this is a privilege". Indeed, and I have a hard time picturing another job for myself!
Molly was pretty bold when searching for her first jobs ; and she stands by it: "Be bold, ask (what you need/want), you never know what other people are really thinking"
Once again (this is a trend with 75% of the guests) Mentors made a great difference. Molly's first mentors were not just correcting and teaching, but also encouraging, giving a lot of positive feedback, pointing out what she could improve, but also what she did well. They took time to do 1-1s with her.
"There is nothing more crushing than not getting the mentoring you need"
When I asked how to screen for this, Molly advised to ask about mentoring in job interviews. There should be methods in place: pairing, reviews, PR feedback etc. If you ask the juniors about their experience, you usually get a very good image.
Molly's push toward SRE came from her stepping up to own the Elastic-Search piece of the puzzle at her former company "Kenna Security". I love how she noticed a problem (a senior leaving the company) stepped up, owned the problem, did a great job of it and then got rewarded by being able to doing it full time. This deeply resonates with the way I encourage people to work.
I like Molly's definition of SRE. Being a good "Site Reliability Engineer" means conceptualizing the system as a whole, knowing how the different pieces interact and coding so that the system performs at its best. This is a coding job, not that of an infrastructure or operations engineer.
I asked Molly about the difference between the job of an SRE and the responsibility of the dev team toward non functional requirements. Molly said that the SRE team should not be the reliability-police. In order to empower the other developers to care for the non functional requirements, Molly advised to invite developers to work with the SRE Team for a while before going back to their team, taking the SRE Mindset with them.
A quote I love: "Making things faster than people think they can is the best" :)
I am amazed at how natural it was for Molly to speak about her failures. We all know we should be celebrating mistakes. But she was particularly open and stoked about it: "We were transitioning from MemCache to Redis [...], I broke a few things, and I learnt a lot. [...]. When you break things, that's when you learn!"
"One of the most important aspects of mentoring is for the mentee to learn your thought process and how you walk through stuff. [...] When something breaks, even seniors have no idea. We start with the tools we know". <3
"Always give more positive feedback than what the person needs".
"When you start somewhere, take it all in and don't put expectations on yourself because there is probably no expectations from anyone else"

Thanks @Molly for sharing your story with us!

You can find the full episode and the shownotes on devjourney.info

Did you listen to his story?

What did you learn?
What are your takeaways?
What did you find particularly interesting?