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.

Today, I'm going to talk about You Know Nothing ... or do you? I will try to make this talk as accessible as possible, thank you for the organisers who provided some great resources on how to do that. If there is anything in here that you can follow, I tend to speak very fast when I'm nervous, so, yes, just stop me when I do that.

And now a question for you. Who in this room is not a developer? Give me a quick raise of hands. Okay. Some people. This talk is narrated from a technical perspective - my perspective. The thing is I'm convinced of the gist of it is applicable regardless of your chosen profession. Please don't feel excluded when I mention technology things. Replace it with what your profession uses.

I am Sascha. I'm a Full Stack developer, technical solution architect - that's a fancy way of saying I deal with customers! I work at grandcentrix if Cologne. We are mostly working in IT projects. During my career, I did a whole bunch of things. I build things in services, and Java and when Node wasn't cool. I wrote websites, CSS, pure JavaScript. CM, Swift, better development in C, and ... employer, and, yeah, you can find me on Twitter.

I'm going to take a variety of thoughts, it can be writing blog posts, asking questions on the message board, recalling videos or podcasts of maybe step by step things, and speaking at a conference as I'm doing now, it can be most important teaching your colleagues, so, when we have a issue of questions, I think we all agree that knowledge-sharing is important because we are relying on it on a day-to-day basis, either getting help from a colleague, or by reading an article on social media.

I've tried to find up-to-date numbers of how many stories published last year, so, there's that. 7.5 million posts published in 2016. I'm pretty sure there are more last year. A lot are free. This weird thing that people are using. I'm sure you find a lot of articles on there. Okay, that's really helpful, thank you. More than that, Wikipedia relies on people who freely share their knowledge. There are 35 million registered users and nearly 47 million articles in all languages, I must say, in English, it's nearly six million which is still very impressive number. The yes, ... . And StackOverflow. It's like a question and answer board where you can ask questions and get answers - no surprise there. 85 per cent of developers say they use it nearly daily or weekly. So, definitely it plays a huge role in our industry. There are also ten million users for 26 million answers from nearly 70 million questions, so a lot of volunteers again giving you the knowledge away freely.

That's a lot of knowledge, right? Wooh! That can be intimidating. You read all these answers of questions, and you think "Oof, this man those this stuff, or this person. What could I possibly contribute to that? They seem so smart, they seem to have all the answers.." in our day-to-day lives, we struggle to keep up with our ever-moving industry, JavaScript, TypeScript, whatever. Every week, something new pops up, and every day, we have to learn this new hot thing, and then try to keep up, and we learned things, and maybe we ask the question, and they say, "Are you using Angular, or OS 2005? You should use React, or whatever." "It's not written in Go? Sheesh!" This affects our perception of how a Java developer looks like. We should come to the conclusion that a good developer knows it all, he knows it all, and he's incredibly productive, he dishes out high-quality code all the time. A fast learner, can he possibly deal with all the things that are popping up?

Yes, ... productivity, right? Yes, we think, okay, I'm just telling people, and, some day, going to be great, and can finally start now on the blog post. We don't want to be the person that writes, like makes a suggestion, just weird, or not feasible because of some thing. So we don't, the Stack Overflow question, don't offer help, don't prepare workshop in the company, don't record a video, don't write a blog post. Maybe we don't even get input during a meeting. And who can blame us? Like I said, we're living in a fast-moving industry, and that means we have to learn all the time, but, statement, we have to write some code to actually deliver the work. We have to earn our money.

This is stressful, really stressful. So we don't bother with sharing. It's okay, I'm going to keep learning, I'm going to write code, and then at some point, I'm going to be ready. And maybe you're writing a blog post, publish it, may be you record a video, and just never upload it because you're afraid of someone making fun of you. Does that sound familiar? Certainly it does for me. And, yes, it's if I found somebody, welcome to the club, because I'm today here to talk about my story. I'm in this industry for like five years, a bit more, eight if you want to count my training time, and spoiler: this doesn't end.

There's no point in time, "Now I'm ready and I can share my knowledge finally." There's always something new you have to learn. I always try to absorb knowledge as fast as I could, and, as it turned out, I'm pretty good at it. But it leads to exhaustion. I was always tired, all the time. But I kept pushing. I actually put more on my plate. Can you still hear me? The sound just changed. Good. Okay, yes. Try to get like a certificate, or a Microsoft Azure platform, or put it on my CV. And it leads to depression. I'm still working on it. Today, I tell you what I painfully learned during this time, therapists really can ask these testy questions, so maybe you don't make the same mistakes.

You see, I didn't - you recognise, I know everything, I'm awesome, instead, I developed a new frame of mind. I changed my perspective on my work. I changed how I view the things I do, and the next two slides, I'm trying to convey what that means. We've got to make a small detour from knowledge-sharing. Please stick with me. It comes back to this again. So, let's dive right into it.

We take the industry, or whatever industry you're working on, we focus a lot on tech skills, design platforms, specific languages we're using, technology, Kafka, whatever, you can name it. We call the people who are good at these add code ninjas or rock star developers. Let me ask you, what does this tell us about a person? We see this tiny part of a person? His ability to write JavaScript, and say yes, this is a developer who really knows his JavaScript. But all the other parts other than their ability to write JavaScript? Their interests, hobbies, so on, and so forth. Only everything put together actually forms the whole person, which is more than the sum of their parts. A complete package.

Together, like the ability to write JavaScript, the higher the whole person. Let's do an experiment. Please think of somebody you respect, like truly respect. It can be somebody you know personally, a YouTuber, a blogger, whatever, a social media idol. Cool if they have something to do with technology, but they don't have to. What do you respect about them? Your ability to - their ability ability to write awesome code? Is that what you respect about them? Maybe they have great communication skills, they can break down a complex topic and explain it to you? Or are they empathetic and patient and you can come to them with an issue. It's always a 80 working environment with them. Maybe their interest is a variety of topics, and they prompt you to learn new things. I could go on here, and probably lots of other things that you respect about them, loads of other qualities.

The point I'm trying to make here is that you're not a walking textbook. We're more than that. At grandcentrix where I'm working, we look at the CV and see basic order, but we try to find out, does he know how REST works. Does this person fit culturally in the company? You can always learn on the job using ... a language you've not heard of. You can't expect people to know it. At the end of the day, when you go through our application process, the whole team votes if they want to have you on the team. You have to see if they fit in the company.

If it's a small company, you can say the guy in Germany, I don't care what they're doing. Google has a similar realisation, and they have teams who are super smart people, I think we can agree on that, but just didn't perform. Teams that just didn't deliver on what they ought to do. They wanted to find out why. In 2012, they started a project, a research project, to answer a very simple question: what's the secret to a successful team? In over two years of research, over 200 interviews with employees from 180 active teams, they came up with 250 different attributes, and they couldn't make sense of the data.

Like, there's nothing in here which correlates why this team is successful and this team is not, until they discovered something called psychological safety. What is that? Psychological safety is the shared belief held by members of the team that the team is safe for interpersonal risk-taking, a sense of confidence that the team were not embarrassed, reject or punish someone for speaking up. What does that mean in practice? It means that you have a protected environment to exchange ideas, to talk about maybe stupid things which might not be so stupid after all, you have a culture on failure so you don't ask who is at fault, who can we fire, but how can we fix this?

There's a lot more than this. There's a great article from the New York Times which I tweeted on my Twitter account, which is really cool. The point I'm trying to make here is that not the best or smartest people form the best teams, but the people with the best soft skills. That's not only applicable in tech, it applies to every industry. "No, I don't have soft skills! How could I possibly be a good developer then!" We're getting there.. the you should maybe call it a core skill. Everybody needs some degree.

There are stats which say that only two per cent of projects fail because of technological issues, and about 70 per cent fail due to communication issues. So, core skills matter. Why stop here? We just established tech skills matter of course. You have to write, you have the ability to write some code, but also soft skills/core skills matter. Why not other skills? I'm talking about skills you do in your free time.

An example of some things I discovered I learned while not coding which are very useful. For example, I play a lot of League of Legends, or I used to! If you don't know League of Legends, it's an online game you play with four other potentially random people, and you play against five other people and try to beat them. This is a very stressful team situation.

When somebody makes a mistake, for example, they die, it's not very helpful when you say, "I got you ..." [Laughter]. They're not going to play better after that. So I learned, okay, maybe have to be more calm with people, motivate them. We had some games where we turned it around, and another team was screaming at each other at the top of their lungs, and even though it was dire for us, we won in the end. Some skills I learned there. Another area where we do role-playing games. I run two games for groups, and, when you do that, or if anybody here doesn't know what role-playing games are, you have a game master who describes the world, and the other participants are playing one character and saying what this character does, so, when you are the game master, you have to have very clear communication because things you say, it's the only thing people in the room have to actually judge what they want to do now.

You have to be very patient because you're going to give hints to your players that you think are obvious and they're going to miss them all! And you have some degree of organisation because you should remember what happens five episodes ago, it's really cool when somebody back then bites you on the arse now. So it's like a good group of skills to have when you run a role-playing system game.

So I would like to hear from you what are the skills you think of you're required not in your work but other areas, tweet me on Twitter or something like that. Like your dancing classes, for example. That would be really cool. Let me reiterate. You have to have some degree of experts, otherwise you can't work in this industry. Tech does not define us or even necessarily make you a great developer. Okay. Now you might be asking, "Why is this guy telling me all this?" What does it have to do with knowledge-sharing? During therapy, I'm going to get there, I discovered that I nearly exclusively defined my value by my tech skills, the degree of my tech skills.

I also held myself to unattainable standards, as we discovered. And I had discussions with colleagues, and it turns out they often feel similar. As a consequence to you when you do that, which is when you define your work by our tech skills, every critique strongly undermines our self-confidence. Knowledge-sharing becomes risky. It's like building a house on stilts. It can work, it can hold but when comes a guy with a sledgehammer, bang! All it gone. But when we recognise that all our skills are important, all of them can possibly contribute to doing a great job, you have a great foundation to build on. The guy with the sledgehammer has a hard time bringing the house down. You write an article about how to use Docker in a specific environment, somebody comes along and says, "That's stupid." Hammered away, and when you're Aldershot Town, but when you recognise the other things to build myself on, and it's not so bad.

But I urge you: don't try to be a rock star developer, try to be a wholesome developer, or design, or whatever. But how, you might ask? How can I do it? I have some tips and tricks which helped me in the last year. Maybe they will help you. You can try them out, I don't know. I thought I would put them here. Let's start with a fun one, actually.

I asked colleagues what they would ask me, so they have a question which area would you come to me to ask it? Also, I included the questions not only to this about tech but any particular area they could think of. There was a funny response from one guy who asked me about Ruby on Rails. I've never written a single line of Ruby in my life. People think I'm a productive person. When I thought about it, I'm lazy when it comes to typing. I try to automate things. So this taught me two things: it taught me, I see knowledge in particular areas, there was something in there which wasn't surprising, playing games, for example, but it taught me that our perception of knowledge can be faulty.

Remember, that one guy with Ruby on Rails wasn't true, and our perception of people might be wrong, and maybe they don't know Docker as well as we think they do. Another thing which I would urge you to do is focus on the learning and not the mistakes. Like oh, my God, it was a mistake, instead, try to think, okay, what did I learn from this? Maybe I can do better next time.

On the same note, you did the best you could with the knowledge at hand. When you think about it, writing code is actually just distilling knowledge. You write down your current understanding of a problem, the next time when you think, oh, my God ... so don't be hard with yourself, but think what did I learn today? You can make it into a blog post. I did it like this, and now I learned and this and this, and I will do better next time.

Keep a ... record and not only focus on tech. Write down any time you learn something, write it down. We have these moments daily. Maybe write something down, I realised, I learned something, and this can also be seeds for blog posts in the future. Like, this is something which I've learned, actually pretty cool. And then, when you finally get around to start maybe working on a video blog post, whatever, document the journey enough to go, because they're mostly is the ultimate version of something is the best way to do things. Instead, start to document what mistakes you made, what pitfalls you had, the questions you had and the answers.

Write it like you would have to see the article for the past use, or the reference, what you would have liked, because this is mostly what is very helpful coming to the topic. And then at the end, the final nugget which helped me be calm is meditation. It helped me to calm down in moments where I - where it was very dark for me. There were moments before this conference I'm going to call you and cancel everything, I can't do this!

And, yeah, after all of this, I would like to reintroduce myself to you, but I'm Sascha, I'm a husband, a farmer, a role player, and a developer, I'm a vegan for nearly six years now. I'm an atheist interested in theology, so please don't ask me what society I'm going to ... . I'm compassionate to work at life. There's a talk from me last year where I talk about compassionate coding. If you're interested in that, you can look it up. I'm a technology person. Like I said, I'm a Full Stack Dev in real director life programming. I want to understand how something works and using - I don't want just to use it but I want to understand how it works. I try to read a lot. Science fiction, role-playing games, thought-provoking stuff. I have a lot of other interests in other areas, splays exploration, mindfulness, and I'm also very interested in productivity, as it turns out. And there's more to me than just being a Full Stack Developer who writes Elixir. I'm 100 per cent confident there's more to you than the profession you've chosen.

Thank you for listening. You can find me on Twitter, or you can go to my website. And please tweet me the tweets you think you have acquired because I would be curious to see where you got these from. Go off and write some blog posts!

Thank you! [Cheering and Applause].