These transcripts were captured live by a captioner. As such, there may be small errors. If you spot any, please feel free to submit a pull request with amendments.

So, today's topic from me is learning is a skill, and, when I was thinking about topics that I could propose to You Got This, this came to my mind first, because, well, yes, my background is in educational science, but also I think learning is one of the most salient things about working as a developer in this time and age, and that's something that really, really will help you as a person if you feel comfortable with it, and feel at home with learning new stuff every day at work.

My own path I started studying educational science, so learning how to teach others, all kinds of different stuff - from sports, to art, to linguistics, and I also ended up on a programming course which was teaching programming for beginners, and there I became interested in programming myself, and then I ended up taking a three-month bootcamp and starting working as a developer.

After this three-month bootcamp I didn't have any idea of what it was to work as a developer, or what would be expected of me, and I took my first job, and I felt like I was constantly drowning in this feeling of not being good enough, or not understanding where I should, like start learning more stuff, or how I could develop my skills, although there is a lot of learning going on, I think still.

Those first years working as a developer are really like a struggle, and I thought that I could maybe share some thoughts with you all today to make that struggle less painful, and to maybe, like, tell you the things I wish someone would have told me when I started my working as a developer.

So, related to my talk, I have some philosophical thoughts in the back ground that kind of have guided me as someone who is constantly learning at work. The first thought is that programming is a craft, meaning it's not theoretical knowledge, or purely doing, it's like the combination of both, and maybe the experience that ties those two together into becoming a craft, a thing, that, like, you both know about from a theoretical perspective, but also that you do in your daily life as a habit or as a - as your work.

Also, I think that there is a lot of pressure on early-stage developers, and although there is a big hype around more developers are needed all the time, and coding maybe feels like really cool business to get into, I still feel like there is unnecessary pressure on those early-stage devs, and that could be eased by saying some things out loud that maybe aren't usually stated out loud.

Also, I'm a big fan of being lazy, working smarter rather than harder is a really big thing for me, because there is more to life than work. And, therefore, I think it's really important to not stress unnecessarily, and not work unnecessarily, but instead put in those hours where they really count, and where one can, like, impact the most.

So, when I started drafting this talk, I started thinking of what it meant for me, maybe knowing something, or feeling one is mastering a specific topic. One of those themes is maybe becoming familiar with something. Feeling the ease of the work, also habits - those are all things that I feel are kind of themes that come up when one feels like at home with one's work, and one's craft, especially in programming. When it starts flowing, the ease of the work, and the project moving forwards is a big thing, and to get to that point, one has the level of the confidence of the ease of the work going on, of course. There is a continuing learning process in the background, but I still feel like one should be able to feel this satisfaction of the work kind of carrying itself forward.

So, in this topic of learning and how people learn, and how we all can learn as part of our jobs, the whole thing starts with taking a look inside, maybe asking yourself what kind of person you see yourself as. And those questions that could be asked then are maybe, "How do I work?" "How do I react to challenges?" "How do I feel when I know how to do something?" "When was the last time I succeeded in something?" When I was studying at the bootcamp, it was a three-month bootcamp, and somewhere along half of the bootcamp, we all had a scheduled meeting with the coming manager of the work we would be doing afterwards, and I remember it was 8 am on a Friday, and I was really exhausted, it had been a really long week, and we were all facing like really hard pressure to learn a lot of new things really rapidly, and that had been going on for some time. And I came to the office, and I sat down, and the manager was sitting there, and she asked me what was one thing I had done that summer that I felt really proud of.

Instead of coming up with all the things that I felt proud of, or that I would have felt anything in that - like anything like that, I started crying, and I didn't really - I was thinking, I was trying to find something that I was proud of, but I didn't find anything, and instead she started coming up with stuff, like, "Well, you should be taking pride in this and this and this, all these amazing things that you've achieved," but I think once - if one doesn't feel those things oneself, then it's really hard to move forward and to learn new stuff because maybe it tells about one's own state if one doesn't feel the feeling of success or feel the comfort of knowing what one is doing.

These are all questions that you could ask yourself if you have a learning goal in mind, starting with who you are. I also wanted to talk a little bit about the mythology of being gifted. This is something especially female developers, of course maybe also gender-minority developers feel, that it's hard to get into the field because they don't feel that they are technically as gifted as some others, at least even in - I'm from the Nordic, so even from around here, I think there is a strong mythology of men being more logical, and technical than women, and that kinds of holds us back because we don't feel we are gifted enough to start this learning process of learning how to code and maybe sometimes getting a job in tech.

I think, for me, I have a feeling that not being mathematically gifted for a long time because of bad experience s at school or something, and really taking that step to start a bootcamp, to take the step to try and start learning these things required someone else pushing me into the thinking that anyone can actually learn, for example, maths or technical stuff without being exceptionally gifted, and also most people who we think, or we perceive as gifted and talented haven't thought of themselves like that. I wanted to dismantle the "I'm not gifted enough myth" to start with.

Here are some phrases or words that could be describing you as a software developer. Maybe some of you would think that maybe not all of these are traits that the developer could have, or like attributes that are developer could have in themselves, but I would argue that these are all just different kinds of personality, or ways of work traits that people can have, and they all can be the properties of a great developer. So, some of us may be are more prone to going full stack and trying a little bit of everything, and not really digging deep into any specific topic, but some might be really only interested in maybe learning everything about accessibility, and others equally valuable, and then it depends a bit about what kind of job you want to take on in the future, but my point was that we all have different personalities and different kinds of traits, and all of those traits can be the traits of a great developer. It isn't that you have to be maybe always very detail-orientated in order to be a developer. If you are brave in move forward fast, that can also be a trait of a great software engineer.

I'm pretty sure most people in society have heard of some different learning styles, or at least somehow faced them at some point in their life, but I just wanted to list this topic one extra time here. So maybe we all know that there are different styles of learning, and by "learning", I mean becoming familiar, getting to know oneself, and a subject maybe memorising, or then trying out new things, if learning a skill, it's more about the doing than the reading. And all of these different learning styles can be applied to learning software development.

So maybe we are those kinds of people who like to learn alone, or maybe we are very social, and there are a lot of resources out there both for just studying stuff by one's itself, or then studying stuff in groups, and meet-ups, and with friends. Also one may be more verbal. For some people it's easier to hear someone explain, to read something, for others, it might be about the seeing stuff fall in their places, maybe seeing visualisations of data, or how CSS elements fall in place on a page. Those are all be different styles of learning maybe the same thing. So I collected some resources of what I want to share. One way of going about learning is reading and listening, so maybe listening to podcasts, or to conference talks, to discussions, or attending different kinds of events as a listener, or then reading news letters, books, all of those are great ways of learning.

More about software development in different kinds of ways. Maybe books are more of the dry philosophy behind the theory - most books, but then again like news letters you can describe to, JavaScript Weekly is a great resource that has hands-on articles that people can enjoy.

Maybe start your morning by going through a newsletter. They tend to pile up in my inbox. I use one morning per week to plough through them. I hope you have better practices for news letters than me. I wanted to lift this topic of visualisations or explanations that have visual support, so, for example, CSS Tricks has a great guide to the CSS Grid, and I think they've really captured the essence of how to combine code with actual physical drawings, visualisations to make explanation really clear.

There is also a YouTube channel called I think Three Blue One Brown, or something, and they have this amazing machine learning explanation videos which go into the mathematical side of data science and machine learning through amazing visualisations. At least, for me, these are one of the main ways I like to learn things. I always remember if I've seen something, maybe a picture of a neural network, how it works, how the different layers interact with each other, more so than by reading that as text.

We are all different in that way, and it's good to maybe explore some different things, and find what works for oneself. One way of learning is also through doing hobby projects, or hands-on things, so I think all pretty much all developers who have had to work with CSS have at some point encountered Flexbox Froggy, a game where you're placing a frog on a petal by using CSS Flexbox. That's a really great way to learn it. I think that's something I hilariously enough go back to a lot when I work with front-end stuff. Other great ways of doing is, or projects that one could start is, for example, the advent of code, or maybe like going through the different kind of tutorials offered by the frameworks themselves.

Just one more word about that the advent of code, it's a coding calendar that is available every year in December, and it has challenges for each day, and it's like obscurely difficult, I think myself I've done like the five first tasks, or something, but it takes so much time to try to do every single part of of that code, I don't know what kind of person manages to work full-time and do that at the same time, but I wish I could complete it one year.

Here I took a screenshot the of the Django documentation, so just maybe maybe make the point that there are a lot of frameworks that have tutorials and documentation, or tutorials as part of the docs that are a really nice way of doing own projects. Also community, friends, mentors, reaching out.

I think we have an active female and gender-minority Slack community for people working in tech. That's one of the communities I interact with on a daily basis. We also have other communities, maybe I wanted to lift our Python community to the Python community of our city, and these are great ways of getting out after work, maybe finding some new friends, and also asking those questions that one maybe doesn't dare to ask at work. I also had an amazing experience of reaching out to the Slack community and asking if someone wanted to peer-programme with me in a experiments way on Gatsby which I wanted to try for a long time or I didn't want to do myself, or muster up the will power to do it myself. One of my friends spent a Saturday peer-programming a small Gatsby app with me. It was really fun.

I encourage people to find those communities and friendships that you could maybe get outside of your own comfort zone a bit and also find something fun to do learning-wise. Then I wanted to go a bit more deeper into the programming as a craft. I think so maybe the philosophy behind what it is to know how to code, and what it is to be a developer, I think it's also very much an identity question. One can see oneself as a developer, and of course I really understand those people who feel like they don't want to have anything to do with coding, or programming, or any kind of software or data science stuff during their free time because that's what they do during their work days.

Then again I feel I've been working as a consultant for the first years of my career, and now I'm working as an in-house developer, and especially during my time as a consultant, I was really heavily emphasised that, as a programming consultant, you're not only a developer but you should be kind of also a messenger of that culture of continuous learning, and personal development, maybe you have your own interest, you're staying on top of those.

For example, small things like reading a newsletter once a week doesn't take that much time but it is a habit that will make you a better developer in the end, and not like, maybe not spending a lot of time, because time is also a valuable asset that we don't - that we're not supposed to waste, but spending time smartly and doing those small things that make you a little bit more informed than the general public about your stuff. Maybe it's reading one newsletter per week, or to one conf every three months, or something like that, but that's part of the craft personship I see is connected to programming, and that will really, really support one in one's clear, just having a little bit of extra there.

As I said, it takes a lot of time, and time is not something that we all have an endless amount of, especially those of us who have family, or who maybe are students so are working part-time, or studying, and those things, and maybe to all of those of you who are junior developers, and who are stressed out with not having enough time, not having enough energy maybe to keep learning at the pace that you would want to yourself, I wanted to say that part of being a developer is also having confidence in that you keep working, you keep doing your job, you keep doing your studies and you get better. It doesn't happen like overnight, or instantly, or anything like that, but if you keep doing it, you put you to in those small amounts of time or larger amounts of time if you have that opportunity.

It does pay back, even though it sometimes feels like you're pushing and pushing, and the cart is not moving anywhere. That time is definitely going to count in the end. I also wanted to mention a little bit about setting goals. A question I would ask you who are learners or students, maybe learners on the job, what are the concrete goals you want to set maybe this month? Or maybe this week? And one of my friends who gave a great presentation about getting overwhelmed in tech - that's also something I think a lot of us experience.

One of his points one of the key ways to get overwhelmed as a software developer is that you will try to be full stack, of course, it's okay to be full stack, that's fine, but also like if you aren't able to narrow down what you are learning, it really might feel, because there is like an endless ocean of stuff, from infosec, to front-end, to CSS, and there is so much, and they're so different from each other, that if one doesn't set a specific goal, narrow goal, then it's really, really frustrating, because it can be really frustrating not to - when one is moving on all of these different areas, it might feel that it's going really slowly, even if it's going at a good speed.

Maybe a mentor could help you set the goals. Maybe a colleague of yours, or somehow another mentor. Maybe you could find a mentor working in the field who you would want to kind of follow career-wise, so, maybe a mentor could be one help to setting those career goals, or to those study goals. And asking one's self why are these the goals one uses? Of course it might be a goal to learn Rust or Haskell. Haskell been my learning aspiration for a long time, but, realistically, if one of your goals is to get a job and thrive at your job, then I'm afraid there are very few jobs that Haskell or Rust might be helpful in, at least for now. At least for now, no-one knows what the future holds.

I would encourage people to critically evaluate why are these the things I wanted to learn, and how would you practically apply those skills you gain? Because they go away if you don't apply them like all of the university exams, it's just long gone one month after the exam if you don't use it practically. In assessing your learning, yes, maybe peer-programming could be a good way of doing that, hobby projects that you can show up, showcase, I would say put everything on GitHub or whatever other public portfolio you want to have. Don't be shy. Just put stuff out there and ask for feedback. That's really valuable. Also maybe ask a mentor.

And, yes, one more topic that I wanted to cover is feelings. Maybe this is something that I see female or gender-minority developers lift a bit more than the general dev community, maybe it's changes - I hope it's changing - but I hope in the future more and more technical people could be talking about feelings without feeling awkward. So these are all gifs that I had in my Slack discussion with my tech lead during one day. I think they described very well how my emotions go during a day at work. I'm not a very emotional person in my private life in the sense that I tend to be quite steady, but at work somehow I realised when I started working that there is just so much - I think it's because it's hard, it's difficult, there is a lot of frustration, there are a lot of feelings of helplessness, maybe, feelings of, "I'm never going to get this to work, this isn't going to go anywhere", a pull request has been hanging for weeks, and then sometimes you feel like you get something done, and you're really happy about it, or then you just feel very grumpy when something doesn't work out the way you want it to work out.

Those are all things that really impact you as a developer, as the code you write, as something that how you interact with your colleagues, and I think it's really important that we notice this, that our feelings are part of our job - maybe for some, maybe more, for some less. Especially, as junior developers, it can be hard, difficult, frustrating, and that is okay - that's very okay.

Kind of accepting that one feels stuff, and one is accepting that one - yes, sometimes, it feels really bad at work, but that feeling will pass, and maybe of course if it doesn't pass, then it's time to do something about it, or change your role, or ask why you're not feeling good. But also not being afraid to feel bad some days, because that's just part of the job. Sometimes you hear people say that you learn faster by failing. I don't agree. I think of course it's important to fail sometimes.

In Finnish there is this idiom that says your failure is a gift, and [alarm sounds]. That's the electricity that went back on. Sorry! I believe that, as learning coding, as learning software engineering, it's really, really important to have those experiences of success, positive learning experiences, not only feeling bad, because one doesn't know enough, but also feeling really good when one learns something, or when one gets something to work perfectly.

So also like give yourself those experiences, like do projects that are easy enough, go and stay in your comfort zone when you feel like that. Don't force yourself to fail all the time, because that's like emotional ly really hard. Feelings matter. They impact how you work. They impact how you learn. They impact if you are eager to take on new stuff, eager to learn more things, or, if you just want to go home and cry.

This is a screen shot I took from a discussion between me and one of my friends. My friend is a very talented software developer. Just graduated in the technical field. And I think she, as many other developers occasionally have these feelings of - of not being enough, just not having like even though one is pushing oneself and one is doing a lot of learning outside of work and pushing oneself out of one's comfort zone at work, one can still feel really - I mean, maybe vulnerable, maybe - yes, incomplete.

Those are all things that we all as developers, or at least the majority of developers feel, and kind of noticing that we all feel that way, noticing that others feel that way, and supporting those who do feel that way, like if your friend tells you they're very stressed out, if your colleague tells you they feel like this, I think it's important for us also to, instead of kind of making them feel like we don't have this problem, make them fell like it's only them that feels this way, we can also open up and share that, that, yes, this is indeed a feeling we all have occasionally. It's not like there are some super human developers out there who are only winning every day, and feel great, and always succeed in everything they do. And have the energy to be super coders, and do all these fantastic open source projects, and read, and everything, but we all feel very tired occasionally.

I'm glad to say there is a talk coming up about burnout after this, so I will definitely hang around after that. So, look at your own - ask yourself how you feel. What is something you can feel proud about? What do you feel stressed about? Are you sad to go to work? Are you happy? Curious? Excited? Excited about something new, about something that's going to change? It could even be worth it to monitor during one week all of these feelings and emotions, just to jot down each time you feel one of those, that what is the feeling, and how often do you feel it? If you notice that you felt really stressed out every day of the week during the past three weeks, then you know that there is something that you need to change, and, of course, my talk is not about emotions, but my talk is about learning, and learning will not happen if the emotional side is not okay, so take care of yourself emotionally, monitor your own emotions, and accept that they're part of your professional identity, whether you want it or not.

One of the conclusive points I have is it is said in Finnish that something takes butt muscles, which means it takes time, and that is actually everything. Becoming a great developer is about - well, small habits, but also just staying at it, not giving up. I think that's also one thing that a lot of minority developers feel such pressure, maybe their own created pressure, or maybe it's external pressure, but the pressure forces people out of software engineering jobs, maybe into less technical jobs, because they feel like they will never be good enough, but, actually, just sticking around year in, year out, instead of back ing down will make you in the end one of those senior developers who are sitting there and knowing a lot of stuff that all the juniors are looking up to.

So don't give up. Hang around. Stay determined. I think that's also what learning is about. At least in this specific case, learning a skill or a craft. So that's all I have to say about learning. Thanks for listening, and please come and shoot me some questions later.