Hey, everybody. Thank you for tuning in today. Let's jump right in and talk about learning. In order to do so, I want to put us in a bit of a mindset. Picture this, right: you've been working at this fresh early-stage start-up, let's tall it DevTool Ltd, working there as a software developer doing your thing, and there is a big codebase that you're confronted with, and, as you're onboarding, you're learning about how things are done -- sorry, hit my mic! About how things are done at this company, or things are changes very quickly, starting next week, we are going to do something else, and then the big pivot comes and there are new goals and strategies, and, as you're processing all of that, my goodness, you're given a new task,and then it is all plopped on you, and you're given the green light to go ahead and you start wondering, you feel a little overwhelmed. You think goodness, where do I start? And, well, today, I'm going to start by telling you a little bit about me! [Laughs].
Yes, hi, my name is Ramón, pronouns he/him. Originally from Chile but I've been living in Austria for a very long time. I'm a Developer-Advocate at Suborbital. I do some code instructing that I really, really enjoy, and just such a big fan of community and core skills as part of those because I feel they help us grow as software developers. Of course, I do lots of coding and live streaming which I highly enjoy. I will kick us right away ... [laughs]. The photo on the left that is me giving a talk about a Dance Dance Resolution, a controller I made with an Raspberry Pi. I'm sure I will find a link somewhere!
Let's talk about a grand statement to kick us off. Now, this might sound perhaps obvious, but I really want to be super clear: you're not going to know something before learning it. We have to start somewhere in the learning process. So much so -- let me cross out that "you". None of us know something before we start learning it. It's a natural part of the process.
I do not know about you, but something I experience quite often when I'm learning something is that initial stage of being overwhelmed by a new problem, and not having any idea what I'm doing. And just feeling maybe a tiny bit of despair in thinking like I don't even know where to start and it is all overwhelming, and this happens to all of us in some point or another, and, later on in our careers as well.
But you do reach a point, don't you, where after going at the problem for a little while, and you start recognising patterns, you start thinking, hold on, this problem reminds me of this concept I learned at another point in my career. As you go through that, everything starts to fall into place.
Eventually, you're confronted by what I lovingly call an a-ha moment. In my line of work, this is critical, almost like a currency. If I can accumulate those a-ha moments that I impart on others and myself, it's just the biggest feeling in the world. But what happens? I have that a-ha moment, I revel in it, and in my next task, quite often, I'm back to square one. I have no idea what I'm doing.
And I'm going to be a little bit nerdy if I may, and bring up a video game that really made me think of this. This is perhaps one of my video games of all time. It's called Celeste, a beautiful story about this woman who climbs Mount Celeste. See faces lots of challenges and discovers who she is. It is a jumping running game. It allows you to adjust the difficulty for your needs. But something I experienced playing this game was something that I feel in my day-to-day at work, especially when working in tech, which is that every new level, which would be a square level with one part, with one challenge I have to beat, I find myself thinking my goodness, I have no idea how to beat this. I'm never going to beat this level. And I just sort of get frustrated, and I spend lots of time in it, and, after a while, things start clicking, I start learning patterns, I start recognising patterns from previous levels and eventually, I beat that level, and it is the best feeling in the world. Only to get to the next level, and it's the same thing all over again.
I want to tell you a story. This year, my friend Jess and I started teaching free software development bootcamps. She started doing web development ones, and I've been doing JavaScript ones. We've. Doing this by getting - *we've been doing this by guiding people three Free Code Camp. It is incredible. And as I was doing it -- I've got a link here with a time stamp, that might be interesting for folks -- I was in the middle of doing the camp exercises when I came upon this exercise you see here.
This is a screen shot from the live stream where I was doing the record-collection exercise. And as I was going through it and showing my problem-solving skills, and all of a sudden, out of nowhere, I got stuck. And I'm not talking like a little stuck, I'm talking like really stuck. Let me tell you all, getting stuck live when you're trying to teach folks stuff, for me it was an absolutely demoralising experience. And I did eventually figure out the solution, and I was able to give folks the solution they needed, and teach along with that, but I was very frustrated. I spent 25 minutes or almost half an hour on that exercise.
I remember turning off the stream light and going to plop on my sofa and thinking, "My goodness, I have no idea what I'm doing!" And the experience I got from that was afterwards somebody sent me a DM and they said, "Hey, Ramón, that looked really hard. Congrats on getting it done. I just want to say thank you." "Thank you for showing us that even folks who have been doing this for a long time get stuck too." And this to me was revelatory, because it showed me, it reminded me, of that experience, that cycle of not knowing what I'm doing to recognising patterns, to eventually fixing the problem. And how easy it is to get caught up in the moment and I forget, hey, maybe I don't have all the answers after all! But I forgot, I do formulate them over time. I want to take a moment also to plug a talk that is given at this bootcamp, which is from Dr Barbara Oakley and Zack talking about learning how to learn, semi-related to this topic today, but I highly recommend it as well.
But what about learning at work? Because, sure, we can learn in our own time, but in our jobs, is it expected of us to learn? And I want to say, yes, absolutely. In fact, we all do it at least once in our jobs. Hopefully, our jobs will provide us with a good all-encompassing onboarding experience. And every time I've been onboarded on to a new codebase, on to a new team, on to a new project, I've found myself thinking quite often my goodness, I have no idea what I'm doing.
This year, when I was going into my new job, and this is a job where I have to do developer advocacy for web simply as a technology which I knew very little about and my point was to learn in public, and do what I can to make the community better, I had a revelation once again: it's not that I have no idea what I'm doing, it's that I don't know what I'm doing yet. And that is a valuable perspective. Because then I can start finding holes in the cursive knowledge that plagues us all as developers. This is where they forget what it is like to come in from the outside because they've been working on it for so long. What can we do with that "yet"? We can start asking questions and we can start questioning things.
Moreover, when we are getting onboarded with the new technology, and I would even say further out into our working experience, what a powerful notion it is to come into a new experience thinking, okay, I get it, but what if I, for example, say I'm doing some CSS, what if I make it blue instead of red? Or what if I make this purposefully break? I spent eight years teaching children to code, and one of the most important lessons they've taught me is that in order to -- one of the best ways to learn is to break stuff.
Because, really, you're going around, you're like with kids, we are coding games, right? They were just putting hundreds of thousands of enemies on screen, and then kind of going, hold on, my computer no longer works! Why? Because they're overloading the computer. What a valuable lesson that is. And when you do that, that experience brings in new ideas. When you're sharing those new ideas, it can be scary to be confronted with questions, isn't it? Maybe you thought at some point in your career, hey, I could take up public speaking -- PS, you totally could! If that microphone, picture of a microphone doesn't say it, it is totally the place where you can come in and share your ideas, and share your knowledge, but what happens? I have had this fear.
I have it to this day, where somebody's going to ask me a question that I don't know the answer to. And to realise how liberating and empowering the three words, "I don't know" are. Where you can show that, as a technologist, we don't have all the answers all the time. I even say more so than that, we have the experience to add a comma and three even better words on to that, "I don't know, let's find out" and going on a journey of discovering, learning, and collaboration that makes, and this is something we do as a community all the time. But of course, if you're alone, and you're stuck on a problem, what do you do about asking for help? So I want to ask everyone a question. How long do you wait before reaching out for help? And I find that there are two camps here. One are the folks who reach out immediately for help, and others are the folks that take -- I mean -- I'm in the latter camp, where I take far too long, it's my anxiety, I feel I'm going to be a bother or a detriment to my team, and this can go on for ages as not forever.
There is a balance there, because if you take too little to reach out ought your early learning stages, we risk not learning how to solve problems, we risk from practice, from risk not practising enough, we take too long, and then we -- but, if we take too long, of course, we risk holding a timeline, holding a team, holding a project back.
So one piece of advice I would love to share with you is to have heuristic, and try to be as consistent as possible with it. For example, for me, I say half an hour. Half an hour, and then I'm done. Then I will go as ask for help. Then the question becomes "How can we be as helpful as possible when asking for help?" Here is one thing I've learned.
One is asking narrow pointed questions. Of course you can come in and say, "This doesn't work, can you come take a look?" Or, and this is very different, you can say, "I'm having some trouble logging in, since updating to this latest version of a package, could you come and take a look?" This already puts the helper in a right frame of mind for being able to help you.
Same goes for sharing what you've tried. Eliminating those possibilities so you can get right to the point, and letting your helper eliminate those possibilities. Showing some steps to reproduce the problem -- again, super helpful, "I tried this, I tried that."
Let's talk about peer-programming. Peer-programming has been demonstrated and studied to show that it is an effective way for two people to bring out the best after piece of code when collaborating. I even go as far to say if you can, get an ensemble going. You've got your driver, your navigator, and a couple of people around you to collaborate and learn together, because then the learning goes exponentially.
One thing I want to remind you, as Erin said, this is a non-stop learning process. And as tech changes, it might seem like well, I'm going to learn React as the first thing I do, that way, I'm set for life, and I have had that mentality as well early in my career, but I found the pieces of technology I learn can build on top of each other. When I was teaching kids to code, I wrote a bachelor paper about pedagogy, theories of learning and teaching, and came upon constructivism, it is modularly built, they contribute to one another rather than passively absorbing information.
I found this applied to my technology understanding as well. When I started developing software, I was making Mac apps with Objective-C. Then I starting doing Ruby on Rails which got me to Coffee Script. Then on React, and Vue.js and then Rust, but, my goodness, what an incredible way to have these technologies and some of their competencies transfer over. For example, with Objective-C, I learned memory management, which has been tremendously helpful for some of the more trickier parts of my coding. And in the future, what I really want to drive home, who knows what we're going to be doing next, honestly? Before I go, I just want to assure you once again, we don't know everything before learning it. We don't fully understand something before knowing it.
You don't know it before you learn it. I want to show you that experimenting is vital to learning. And knowledge, again, constructivism says our knowledge is built on existing knowledge. And depending on your situation of course, I understand in come contexts, it's going to be easier than others, but this is one for Ramón of the past, always know you can ask for help. And I want to leave you with one thing, because, when I started writing this talk, for today, for you, let me tell you, I had a very similar experience of having no idea what I was talking about.
Here is some further reading about the things that informed me about learning. There are links to the talks that I mentioned, as well as a little plug for Celeste. It's a fun game! There are my slides there as well. Folks, with that, I say you've been wonderful, and I look forward to answering any questions you might have.