It’s not as simple as following a tutorial

Earlier this evening I joined a friend of mine Anaya on a live stream. We’ve been (attempting) to stream on Twitch weekly, as she’s been trying to learn Laravel and needed some motivation.

Anaya is already a developer. She mostly works in TypeScript and her day job is predominantly writing Playwright tests, but she’s above average tech-savvy when compared to someone who doesn’t work with computers for a living.

It took us 2 hours today to get her up and running locally – a process that typically takes about ten minutes if everything goes smoothly. In fact I timed it once for a talk, and I was able to get a local site running in under 3 minutes (including installing Laravel Herd). I’ve written a tutorial (which we were following) on how to do this process for absolute newbies, with the hope that we could start teaching Laravel as part of the She Codes Australia one day workshops. So how come it took us 2 hours, when it should be easy?

The answer was so dumb I low key wanted to cry when we worked it out – it turns out that Norton Antivirus had come pre-installed on her brand new gaming machine, and it was blocking composer. A stupid mistake that probably shouldn’t have taken us that long to work out, even with wine. But it made me think to myself just how important it is that programs like She Codes exist.

The thing is – when I first started learning how to build websites I was embarrassed to ask for help, so I tried to do it myself following tutorials. And just like with our experience today, everything that could possibly have gone wrong happened. By the end I was so disheartened, I figured that I was too dumb and didn’t try again for another six or so months (and when I eventually did, it was only with a whole lot of encouragement from my wonderful husband). When I finally did get back into it I wouldn’t even try without him on standby to double check everything I did, because my self-confidence had evaporated.

It wasn’t until I met two of my best friends in the world (now my co-hosts on the Raft of Bitches podcast) in a happy accident that I became involved with She Codes, and found a tribe that could help me learn in a judgement free environment. I learned a lot from Kate and the amazing community she built, and I realised today how fortunate both Anaya and I were to have experienced the She Codes way of learning (and teaching). So I thought I would put together some lessons that being part of the cult community has taught me.

It’s never too early to mentor

When Kate and Ricki first encouraged me to come along to one of the one-day workshops, it was not as a student, but as a mentor. They didn’t force me to, but they were super encouraging and made it clear that if I was able to successfully complete the tutorial(s) (which are publicly available) solo, I would be fine mentoring – particularly as I used at least some of the coding languages in the tutorials in my daily job. That was on the Friday, and I mentored for the first time on the Saturday, after a Friday night spent smashing through the tutorials in preparation with wine in hand.

They were (of course) right, and I’ve been mentoring ever since. I remember at the first workshop I ever attended, one of the participants said something about how refreshing it was to have mentors who could meet her at her own level, instead of explaining things in language she didn’t understand.

Lesson 1: The best mentors have shared context, and can meet the learner where they are. More knowledge doesn’t automatically make you a better mentor.

Hand Off Keyboards

While having a husband who is both a developer and an IT guy is super handy, it’s easy to see him get frustrated sometimes when I’m aimlessly clicking around the screen like a muppet. It’s tempting for him to just take over and fix the thing for me – and it’s tempting for me to let him. After I started mentoring with She Codes I started pushing back on this, because the only way to learn is to force myself to do the uncomfortable things.

One of our golden rules at She Codes is ‘no hands on keyboards’ – unless something goes really wrong, we ask mentors to talk through troubleshooting step by step with learners, instead of fixing problems for them. Us typing something into command line to magically fix a problem teaches students that they don’t know magic and therefore cannot be a developer. Teaching them to Google a command, and how to access the command line themselves, empowers them by taking the mystery out of it.

Lesson 2: Empower problem solving, don’t solve problems.

Try turning it off and on again

When we are running the one day workshops it can be… a little bit chaotic. We have up to 100 students, 30 mentors, anywhere from 3 to 5 tutorials across multiple coding languages, and a mashup of every type of laptop under the sun. Things are inevitably going to go wrong, and our goal is for everyone to walk away with a win. Anaya and I nearly fell into the trap today of forcing ourselves to push through something that obviously wasn’t working, and it took us way longer than it should have (given we have both mentored plenty of workshops) to go back to basics and uninstall/reinstall things. While it didn’t actually solve our problem, it did rule some stuff out, and it also gave us a clue as to what the real problem was.

A lot of mentors really struggle with this, like uninstalling and reinstalling a bit of software is a failure on their behalf to solve a problem – which is just silly. While it might not solve the problem it probably won’t hurt, and might give you some hints on what ISN’T the problem. Also if I had a dollar for every time something seemed to not work and then magically did when I restarted a docker container I’d have a pretty good wine fund.

Lesson 3: Don’t fall for the sunk cost fallacy. Sometimes the best thing you can do is throw it in the bin and try again, and learning to do so is healthy.

Nobody knows everything

…But you might not realise how much you know that you didn’t know you knew. Most of what we do as mentors is help students figure out what to Google. First time mentors will often try to Google solutions and then instruct the students on how to fix something, and I’m sure I’ve been guilty of this myself… but it’s the least helpful thing we can do. It’s healthy to admit we don’t know things, and looking them up together with a learner teaches them two things:

Lesson 4: You don’t have to know everything to be successful, professional developers are out there asking Google/Claude/ChatGPT as well.

The other thing it teaches them is how to search for the solution – and I think this might even be more important than the self-confidence thing. The reason it’s easier for me to look up the answer to a problem than someone learning JavaScript for the first time? Because I have a much wider basis of knowledge to leverage in finding the answer. I can probably rule a bunch of things out straight away instead of having to look at every search result. My search term is more likely to return useful results than someone who doesn’t know how to describe the problem in the first place. These things only come with experience, but we can share some of that experience and explain why we approached it that way so that our learners can benefit from that experience too. Things I can think of that I’ve shared include:

  • Just copy and paste the error into Google
  • There’s a ‘copy as markdown’ button on the error page – you can paste that in to ChatGPT
  • That link is over five years old, generally we want to look for something more recent
  • Specify that you are on [operating system] because that might be relevant
  • Tell ChatGPT that you’ve already tried [XYZ]

If you are a developer, these are likely things you already know, and do, when you’re troubleshooting something. Even if you’re not a developer but your job requires you to troubleshoot tech on a daily basis, this kind of thing might be the norm for you. But for a lot of people, the research skills that are required for self-driven learning (particularly of development) are not something that they inherently have. So teach them.

Wins are important

When Anaya and I started out streaming we agreed on a maximum 2 hours at a time, because any more than that and our heads would explode. Even though we spent 117 minutes of the 120 minute stream not getting the bloody thing to work, it still felt like a success in the end because with only 3 minutes left to go, we managed to figure out the problem and get it working.

Hilariously, the app we’re building (the one I’m writing a tutorial for) is for a ‘Win Wall’ which is how we celebrate achievements at our 1 day workshops. We ask everyone – students and mentors – to write down any wins they had on sticky notes. Kate has several thousand sticky notes at this point (she periodically uploads the wins here) and I thought it would be a cute idea for a tutorial.

Learning anything new is hard. Make sure you get (or give) the dopamine where you can, even if it is something small. Whether it is learning a new concept, getting ‘Hello World’ to print to the screen, uninstalling Norton-fucking-Antivirus from your new gaming computer, or being able to help someone by explaining to them the thing you just learned – celebrate it.

Lesson 5: If you insist on beating yourself up for things outside of your control, it’s only fair that you also congratulate yourself for the things inside your control.

Find a Tribe

I wouldn’t be where I am today if it wasn’t for a bunch of excellent humans who adopted me and gave me somewhere safe to learn. If you are learning, hang in there – your tribe exists and you will either find them, or they will find you. If you are experienced and you have learners in your life, take a moment to appreciate how much you’ve had to learn in your career, and how much harder it would have been if you had tried to get to where you are now without ever having had someone to ask questions of.

And next time you are tempted to mock someone on Stack Overflow for asking a stupid question – remember that you didn’t know the answer to that at one time either and everyone has to start somewhere.

You can follow Anaya’s journey learning Laravel at https://www.twitch.tv/leafsapien/ and you can find me on https://www.twitch.tv/jominney.

If you are crazy enough to want to hear more, you can subscribe to my blog here!

Thanks for Visiting!

If you enjoyed my rambles and would like to know when I write more rants, or when I run events, you can join my mailing list!

I’m a busy gal so I won’t be spamming you, I send out emails less than once a month (and probably not even that unless something really cool happens).

As a special gift, when you subscribe you’ll be emailed my favourite cat video.