Have you ever felt that tutorials are the worst?

Teach through your bruises

Could be a great idea. I know it is for me, as I often do tutorials, and while I solve different tasks, errors occur in real time, and people can get a feeling of the real deal. This way they can see the exact moment I messed up and how I approached and what strategies I took on those challenges.

Do you want me to show you something embarrassing?

Let's be honest, you and everybody else want to peek behind the curtains and see someone else's mistakes. That's how you usually start my mentoring. My approach is to show it like it is with all the goods and all the bads of being a web developer. My aim is to light up their curiosity and hopefully yours.

Courses, on the other hand, at least most of them, only show you the happy path, the happy story. Don't get me wrong; I've watched a lot of courses and practised through them. And this is how I exactly know what the courses are about. They are about revealing to you, mostly knowledge; most of them are not about clinical experiences or real-world scenarios. They are a product of imagination.

The bug that almost killed the launch of the website

I'm sure you want to hear this story. I remember in my early days that I needed to build the website very fast with a tight deadline, and the client was very verbose about it. He repeatedly reminded me of the importance of having the website ready before he would present it to his clients and investors. Back then I was working with Windows and only touched Linux systems here and there. So the bug was related to file names, particularly to how some of the images were named. You see, the Windows system doesn't care about case-sensitive namings. If a name has uppercase letters and lowercase letters in Windows, that's exactly the same; it doesn't matter. However, for Unix or Linux systems, if you have the same name with different casing, like uppercase and lowercase, those names are different from one another. So as I developed my website on Windows, I could see all the file names and files being present in the browser without any issue. However, when I zipped the solution and sent it to my client, he couldn't see some of the images. And we're talking one on top of the other. Something like, No, I can see the images; they're there. I did send them to you. No, I can't see some of the images. I'm looking at them, and they're not there. And we went forth and back until at least I had to accept that some things are not working as expected. The solution was to either uppercase all the filenames or lowercase all the filenames, and then it would work the same on Windows or on Linux.

And I turn this pain into a teaching moment.

I'm sorry to say that I don't have, like, tens or hundreds of those stories, and I'm happy to say that I have thousands and thousands of stories like this. This way, next time I onboard a junior, I'm ready to share some of the knowledge that will help them have fewer headaches and be successful in their delivery.

So why is this working better than bootcamp?

As I've mentioned earlier, most boots can teach you the happy path. Of course, you might be asked to build a to-do app or style a button. Of course, click on a button to submit, maybe show an alert pop-up, and add some golden stars next to the product for review.

Most of the time you don't practise encountering bugs and how to approach them, how to deal with the unhappy path. And that's what real life looks like. That's where web developers spend most of their days.

And best of all, when somebody that's a junior has zero experience, someone that looks up to you, when they see you struggling too, they get the feeling that failure is normal, and it feels like it's not put on a high pedestal; it's something they can grasp, they can achieve, and they can go through. It's something that's teachable and most of the time even fun.

My hope is that this new portal I'm building will keep an experience diary.

Be it a bug diary or a success diary. From my point of view, I want every weird error in every serverless timeout, something logged and shared so I can benefit from it. I want every CSS bug that shows weirdly in Safari or in Firefox to possibly have a screenshot.

Note to myself as I'm writing this, I believe I should write 3 bullet points:

• What I thought was happening
• What actually happened
• What I should have noticed earlier.

By the way, just as a quick reminder, when I enter juniors, my aim is not to teach them how to avoid bugs and how to stay away from errors. That's a dumb idea. I make it my mission to help them embrace bugs and treat errors as their friends. Bugs and errors are not the enemy; they are feedback.

And to be honest, they always make great campfire stories.