#73 Kai König about simplicity, aesthetics and learning

• 
• 
• 
• 
• 

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Kai König 0:00
Yeah, so he got me onto that because I already knew how to like program websites and use a server side language to do that. And so Ruby and Rails came, came like a natural succession of them. And I really I fell in love with Ruby. That was the first time you really fell in love with a language with the framework with the mythologies behind that and the mindset behind Ruby and Rails.

Tim Bourguignon 0:36
Hello, and welcome to developer's journey, the podcast shining a light on developers lives from all over the world. My name is Tim Bourguignon, and today I received Kay Kearney. Kay has had several roles in the tech industry, including product owner, team manager, systems and software developer he's passionate is in building teams, companies, strategies, and systems in general. He currently focuses on business development, building and growing an integration platform as a service for the company fitbark. When not working on client projects, Kai enjoys fixing migration code in the open source framework Django, or improving the documentation for the Google Python SDKs. Kai, welcome to the journey.

Kai König 1:28
Hi, let's get writing there

Tim Bourguignon 1:29
wasn't always your idea to end up in the software industry?

Kai König 1:34
Well, actually, no. And, like with most stuff in my life, I'd say it was more by accident and by choice, and the same thing is true for like my early endeavors into programming. And like, I think it must, it started out with images and HTML, actually. So I, when I was 12, or 14, I used to collect images from the internet back then, as a hunter gatherer sort of type, I just like had a desktop. And there are lots and lots of files and categories for pictures of mostly beautiful things like architecture. Like early on, I was really fascinated about architecture. At some point, I wasn't really happy with how windows at that time presented the images. And I knew that like the webpages were made out of HTML, and I knew how to look at the source code. So at one point, I just like started experimenting with creating a local new view of the images I've gotten. And I used to do that by hand. So I've written down, like every source of every image. And I didn't know anything about like databases, or programming or loops or whatever, I just knew that I could show an image by using a a good like brackets and typing funky commands and like copying of the stuff, copying stuff from other websites. And making this page like I made a new view of my images in HTML. And I was really proud of myself at that time. And like, frankly, right now, I'm thinking about that. The internet was so open, I just could copy other people's stuff and make my own. And that is still true today, which I really, really like. I mean, it goes a bit with all the compiler frameworks and all that stuff like Webpack and wasum. And what's coming there, it sort of goes away where you can just copy stuff. But back in the early days, that was really easy to just like copy elements and to your own site. So yeah, that was that was my first experience with programming and I think so there wasn't really like I didn't feel like I need to become a program where need to, like study computer science, or I didn't like jot down a career path from there. But what happened next sort of shaped where I would be going, and that was at that time, my parents had a divorce. So and I live with my mom and my mom got a new boyfriend, actually. And he was a programmer. He was a professional program and he sort of saw me do that. And then at one point he taught me to program and I was really fascinated, fascinated by it in the first thing he taught me was chocolate. lingo which at that time was a full blown programming language as compared to flash, which just wasn't with ActionScript. Two, which wasn't really a programming language. But lingo was, and the first we programmed a game, you could run in the browser with a browser extension. Shockwave at that time. And that was ping pong. A classic basically. So yeah, that was that sort of set the path. To me wanting more wanting to know more wanting to get deeper into it,

Tim Bourguignon 5:34
I can relate to so much of what you say. I remember my first my first websites, which were completely statically made with each and every link prepared by myself manually. And even some some nicely rounded designs based on tables. Oh, yeah,

Kai König 5:52
the table, the tables and the images. Oh, my God. Yeah.

Tim Bourguignon 5:59
Okay, so how did you? How did you go from our from Shockwave and lingo into this idea of, Hey, I could do this. I could do this more. This is fun.

Kai König 6:10
Well, I was a troubled child at school, like really didn't like it. And they had trouble with authority. And like, I couldn't sit still in school. And so I feel while not being at school, I was like, fascinated by computers and got deeper and deeper into it. Like, at one point, I helped my parents build a 3d online Museum in Shockwave, which was sort of an application that could render 3d objects and 3d interiors, which I find fascinating because I was into architecture. And like, sort of display videos on it, and like thinking about it, that was way ahead of his time. So it was basically second life but way before Second Life, and it never took off. But yeah, I sort of got more into programming with that outside of school, but I failed, basically school. So what happened was I was in, in German, it's good nauseum. And I dropped out of that and copped into the real Schuler and I dropped out of that. And then I, like recovered basically, from state funded programs, and I went to foxhole Schuler, which is, and then when to the fossil shoulder and then dropped out again. And then it was time for me to really think about my life and what I want to do. And then at that point, my dad stepped in. And he he sort of knew someone who was offering apprenticeships in media design and application development. And that was for me, and I applied and I got in and I knew programming and so I could be I thought I could be like, productive from day one. But basically, they the company was more looking for, for immediate designer, and I remember this to this day, there was one situation where I should design a neural network or a brain cell and I just copied images from somewhere and I couldn't make it to the point where I got the head designer to approve my design and that was like, okay, fuck it, you know what, I don't want to argue with people about their tastes, I want to work on something that's either correct or not. And then I said to to the, to Daniel's happiness, that time he worked at high tech for lock which was a company where I did the apprenticeship and then said, you know, what, I want to do I want to program please LIKE ME program. Yeah, from there on. I, I programmed for like three years at a company building a CMS. In a, you know, language, another obscure language, which is called Boyle, which stands for Bonnie's own interpreted language and Bocconi was a friend of Daniel who wrote that with C. And what was it called? Yak? Yeah, basically a grammar grammar generator. So yeah, that was this. I programmed oil which has had similarities to like, it's a bit like PHP and Java mixed together, but it couldn't do all that Things you wanted to do. And that was horrible. But I learned to program because the language was Turing complete and had a C like syntax and could render HTML. So we built a huge CMS. And I think, up until today, that website is still powered by the language. Wow.

Tim Bourguignon 10:20
You answer, boil questions on StackOverflow.

Kai König 10:23
I don't think that tag exists, and then we have to

Tim Bourguignon 10:27
create it.

Kai König 10:31
Yeah. And that's cool. That was that was it. And from there on, then, at some point, like, remember, the boyfriend my mom had, he was like, he was I looked up to him, he's, he was a professional. And to this day, and this age, like, he's, like, old for programmer, but he knows more about the new stuff that's going on than me. And that was still that was true, when I was young, as well. And so he got me on to Ruby, and Ruby on Rails. So he, like, saw this framework, and he liked it. And it was like, oh, point seven something. And he was really intimidated by the language. We're fascinated by the language Ruby itself, because it's so beautiful. Yeah, and so he got me onto that, because I already knew how to like program websites, and use a server side language to do that. And so Ruby and Rails came, came like a natural succession of them. And I really, I fell in love with Ruby. That was the first time I really fell in love with the language with the framework with the mythologies behind that, and the mindset behind Ruby and Rails,

Tim Bourguignon 11:50
did you remember what what attracted you?

Kai König 11:52
I think the the aesthetics of the language, like coming from Boyle, which is really ugly. And then seeing Ruby and the way it like it looked at, I can't really describe what fascinated me much. But to this day, I remember, everything looked too neat. So because I compared everything back to our hand, written CMS in Boyle, and I was like, I love the language. And there isn't a concept from from a management girl which his name or for God, PETA, called Pitta causa, and he said something about learning, which is really, really true, I think. He says that, like, intuition develops when you are overwhelmed. And by something new, you try to learn. So that is when intuition develops, because you can't really explain why things are the way they are, why they work and how they are working. But you sort of know. And that because intuition, and that is how I actually really learned to program the web. with Ruby, like on the on the tipping point of like being overwhelmed and having too much on my plate. I sort of developed this intuition for a statics in programming. Yeah, so and that's what what, like I still have today. So if things aren't simple, and aren't static, and aren't like feel natural to their surroundings, or to the language, something is off. And that's my, like, early days intuition, sort of,

Tim Bourguignon 13:46
into me that that's very interesting. In your experience, how does this intuition works out when communicating with people?

Kai König 13:54
That that's a good question. So at the beginning, I guess, like arguing about personal preferences and like subjective things like saying, This doesn't look good. That is not really constructive. So you're absolutely right. And I think my first arguments with my coworker was were on that basis that it didn't really look good. But as I like, got more experienced and experience, I could eventually explain why things, what made them look good, and why things need to be simple and how to make them more need. And I think to some extent, my, my early day, over engineering promises or how do you say that? Anyhow, so I like to over engineer in order to get to aesthetics, which doesn't make sense at all, and I I don't do that anymore. But anyhow, on communication, I think, to be to be more senior and to like being able to inspire and lead people, you need to explain why things are the way they are. And you need to fully understand what you're doing. But isn't, isn't this a bit a bit of a paradox? Because intuition true intuition is something you actually cannot really explain. Yeah, yeah, absolutely. And to this day, like, I still get a feeling of things not being right by some sort of intuition. But I got just better at explaining why I think that is, but if you would hear me or like sometimes say that, I think this is wrong, this doesn't feel good. Like I often use the term feel, or feelings or looks or fields. So for me things when they're often I can't explain their start to feel like something. So if I see a piece of code, or a large class, or a method, or something really complex, or I see a concept that feels strange, and like that's my first response, and then I like try to dig into that, and like, explain and pinpoint what made what, like, where this feeling comes from, and what part of the code might be responsible for me getting that feeling?

Tim Bourguignon 16:30
Did you have? Or did you feel the need to, to train your coworkers to react to these feelings? Of Us?

Kai König 16:39
That's a really good question. No, never. I never did that. Because no, wow. So I would try always to get the discussion down to a, like technical and logical level, like, as fast as possible away from intuition. But in hindsight, that might have been a mistake. So that's good. I mean, my intuition is probably worth something. So you should be able to get that across and get that into people's minds to do some extended lease. So yeah, but my initial response was always to like. So sort of intuition is like this. A signal you get in you react on and you try to or an indicator you get, and then with that indicator, you dig down into the root, cause.

Tim Bourguignon 17:35
I remember this this quote from I think it's Steve Jobs, saying arm I don't know what right is, but show me something. And I'll tell you if it's wrong.

Kai König 17:45
Yeah, to something. Yeah, yeah, that's it. Yeah, basically, I had the same experience, like I couldn't really pinpoint What's wrong, and how it needs to be right. But I know, I just knew it was wrong. But that was more in my earlier days of my career. Because now I think much of the time, like, much of the time, it's not worth the effort to make something beautiful that so little people see. So I would much rather spend time on a, like a concept or a, like a user interface or simplification of processes or something like that. But not on like having the perfect UML diagram or the perfect entity relation or something or the perfect class hierarchy, like I don't care anymore, I used to care a lot. But as it's more important to get stuff out the door that has taken a backseat, like pleasing my sense of aesthetics in programming.

Tim Bourguignon 18:55
Did you do something special to get out of this or out of this is a bit negative.

Kai König 19:01
Now I think it sort of developed over time that the statics they have value for myself, and maybe the people that also have the same sort of aesthetics and the same desires as I did. So but those people you could count on one hand. On the other hand, you would have like clients and customers and colleagues, depending on the work you do, and that in the end is more valuable than like having beautiful code no one sees. And sort of over the time I realized that and I stopped basically over engineering for aesthetics. If you were to a to guide or mentor, more junior developer that was

Tim Bourguignon 19:56
in love with aesthetics as you were How would you guide this person slowly out of this of it.

Kai König 20:06
So that's a good question. I wouldn't, at first I wouldn't devalue intuition. So it's still worth something. But how you apply it matters more than, like following through, or like pleasing it to, to an extent where it doesn't make sense anymore. So what I mean by that I would probably, like, explain where it comes from, because I took me some time to realize why I have the type of intuition. And I think it's important to have, and I would probably focus on value creation. Or if you're an artist, that's something else. So if you're an artist, you can be into aesthetics as much as you want in the perfect design. But if you are working for a product, or a company or a client, or whatever, value is more important, and I would say like slowly and gradually build that sort of understanding and trying to relate the things you've built with the value you create, and sort of show that maybe, at some point, there will be might be a discrepancy between the time you the effort you spent in making this really beautiful, but in the, the outcome is still the same. So it's the same way as with refactoring. Like, yeah, it's good, and it is hard to measure the impact of refactoring. But in the end, like a reflected function does exactly the same thing as before. And the value you delivered is equal to zero.

Tim Bourguignon 21:45
How do you argue for refactoring, then,

Kai König 21:48
I argue for refactoring on terms of other measures, and that, like show impact that have impact, but only on a verifiable basis. So what we use to do or what I used to do was, for instance, measuring complexity, and tying that to our overall story, throughput backup fit. And so we had a CI build job that would, on each run, measure how complex the system was based on like cyclomatic complexity and a few other measures. And with that, we, I sort of saw a little value in refactoring and doing that.

Kai König 22:40
And

Kai König 22:43
yeah, so that's my stance on refactoring. And there's also this boy scout rule where we, we used to say that, like, if you see a place and it's messy, like you can at least clean it up a little bit. But like doing those two weeks, refactoring sprints is like I in my opinion, it's not worth it, it's not worth the time, because it isn't linked to an outcome. If it is linked to a real outcome. Like if you want to, like half the fleet of service you run, that's a good thing to do. Because that essentially boils down to having less operational costs, which is good. But if someone just says, Hey, I want to refactor because I don't like the codebase. I, like I wouldn't give my goals so quickly.

Tim Bourguignon 23:31
And easily. In other words, that means if you're going on going TDD style going red green refactor, for instance, the refactor step only makes sense. If it is going to be followed by another read again. And if you were to stop right after the the test you just wrote, you wouldn't refactor. Right.

Kai König 23:52
So yeah, in essence, yes, but every tests, so I have a, I think, I don't know if it's an unpopular opinion. But I used to follow the like TDD, like, religiously. And from my experience, what that does, I want to just share that because I think it's important. So at Tesla, we there was a huge eirp self written in Django, it was a huge code base, and like the entire company relied on it. And so the natural response was, okay, like, we need tests. And we saw the very early on with tests, and we had like a test suit that was seven and a half thousand integration tests that ran for like 14 minutes on, or I think it was 50 shorts. And it was a huge there was tremendous. We had an entire framework for that. But in the end, it took way more time to write tests and to change How tests behave, and to change system behavior. That I think that wasn't like, in the mature phase of that product, it wasn't really worth it because it kept, like slowing us down. And the business around us evolved quicker than we've off. And that was partly due to the amount of tests we had. So at that point, I really wouldn't really would like kept them out. Lots of them. So yeah, I have liked tests. But tests for me, are like, only use or bring the most value, if you know how that your product is stable for a while. And for that, you need to secure the stability of that product. And what that means is, like, as a startup with the sort of product, don't invest in tests, like test and don't invest in coverage, what you should do is in like, make sure the critical paths are covered. If you find like customers, and they're paying you and you're growing, and you know, like, you're the product you build is your money machine, then go secure that with tests. But if you want to move on with a product, like remove a few tests, that you're not so constrained and evolving the product is basically what I'm saying. So you could imagine a Gaussian bell curve on the time axis with a number of tests on the y axis and the time on the x axis or the maturity of the product on the x axis. So that that's how I view

Tim Bourguignon 26:40
tests. What do you say to two dumb bunch of developers who say that TDD approach or a very test centric approach helped them create the code in the first place?

Kai König 26:54
Good point. So I think tests help junior developers to get stuff out of the door. I think that's true. And I think it's necessary to have that. But the seniors, or senior developers, or more experienced developers, they can like write an entire system, because they already have everything in their head, like as part of a plan or vision or, like, they just need, they know what to do. So if I say to you, can you write me, you know, off to service, and then you have a junior developer who doesn't know what parts are involved in that, and needs to like, get his way there three tests in through, like validating each and every assumption you made. And then you have a more experienced person who already knows what's involved and can code that entire thing and maybe secure it with few integration tests. So I think you need to draw a line between the level of experience developers have and how tests can help one and make the other one slow. And much of the industry actually, because there are so many self taught people. I take advice, and really down at some point, when reflecting that and just take it in and do as some popular Twitter handle says, without reflecting on the actual impact and the actual outcome you want to achieve and whether one fits the other. So I think you need to be careful in order and look, what you're trying to achieve and the method you're choosing offene really helped you or is that something just ever work? Because everybody does it? You need to? I certainly agree. And I've seen my fair share of projects that are that crumbled under the weight of have way too many brittle tests. And when you made one change then suddenly had 200 tests failing instead of one and it's just it's just nightmare to find out which one is really the problem. Yeah, where do you need to fix 200 which is even worse,

Tim Bourguignon 29:08
which would be even worse. Yeah. You said we spoke about this, this boy language, which I will put aside for a while. Then we spoke about Ruby and I know there is Python in your in your Python DGM any statically typed language in your in your past?

Kai König 29:26
Yeah, not in my past. I just recently picked up TypeScript and go and boy I must say I love that. I really do. Like I think I've missed out on on types. I know like I used I have some a little bit Java experience. I used to do my

Kai König 29:50
A.

Kai König 29:52
So in order to I had a course in an in high school and you needed to a large project with Java actually, and I did a visual eye sorting algorithm visualizer with Java. And that was my only experience with type languages. And I quickly moved on. But now I've been picking up TypeScript and go, and I love it. And I love it. Because in the like, the thing that improves my productivity the most is the ID and the IntelliSense. I get from that. I know Python has that, but it's not really good. And Ruby has that. And it's more complicated than in Python. And so you get the type languages, like the editor really, really helps. And going back to that large project, that password the or P mode, there were times where people used VI, and you would literally get this to functions, doing the same thing on different objects, because people didn't have auto completion. And with a, well, that's not avoidable with type languages as well. But with large projects really benefit from statically typed languages, where the compiler can already tell you that this is going to be a type error or any other

Tim Bourguignon 31:23
just to just to to close the discussion on the testing. And did you see a difference? there between between working in dynamic languages and statically typed language?

Kai König 31:33
Actually, like? No. So I wrote a wrote a few. A few, like I wrote tests ago. And I really like the approach to it. Even though I don't like the the template they give you. With the test cases being inside a test function. I'm more a fan of having one test. Testing one thing, sort of like a paragraph like describing what's going to happen. And yeah, so there's not really a much different approach or evolve, widely different approach. Except maybe in Python, like you can change everything at runtime, which makes mocking and stubbing a little easier. But it also makes it more complicated. Because in the end, you get that mark theater of like, nothing's real anymore, and you don't know what you're actually testing. And that's a bit more complicated in piaa, and go to achieve. So I think it's a little easier there.

Tim Bourguignon 32:45
That moment when you realize that it tests actually your mock testing and other mock. Yeah, sort

Kai König 32:49
of that way. Like, it doesn't really make sense anymore. You're testing like such a small aspect of the system that, like the test doesn't make any sense. And you can throw that anyway. Because like, in two weeks time or two months time, the next person is really going to have a hard time deciphering whether that test is actually needed or not. And you shouldn't really save your colleagues had cycles and stuff like that. Yes, you should. You should you

Tim Bourguignon 33:19
described in nothing lens, but in details. Your love for Ruby. Yeah. How did you come to Python? And when Why did you settle on Python for a while.

Kai König 33:29
So like, when I finished my apprenticeship, I went back to school, got my cup, my high school degree, and then I didn't really know what to do. And so I worked for I worked in Ruby on Rails for a client of mine did a photo CMS. And then I went to Bomberg actually studying for three months, computer science applied computer science. And I dropped out again, like I liked dropping out of schooling stuff. And yeah, so there are there was not any longer enrolled in university. And so not really by choice, but like stuff just keeps happening to me. I walk by an office in nurnberg. And it said pasla, the monitoring company, and I sort of like the office and I google the company that liked how they presented themselves. And so I applied there for a Python position. Although I didn't know any Python I had just like and I got the interview and as I just said, like Python is like Ruby and I I know I can pick that up and in no time. So it was a bit overconfident on that one and went back Home, actually. And they said like, Oh shit, I have no idea what I've got myself into. And from the time of the interview till I got, like started the job, I actually wrote a small service that encrypted mails are big No, well, it did something with encryption, there was a web service where you could send messages that would self destroy based on some hash. I can't really remember. But I needed to, like, reassure myself that I can actually do that. And then there's the modern Whoa, x. Yeah, so and so I got into Python. And I got into Django, which also is quite similar to rails, or at least the the basic ideas are the same. So you have some sort of, you have middlewares, your views, you have controllers, and you have an aware and some models. And basically, it's the same principle. Yeah, and I've been doing that for quite a long time. And I think I really got the deep understanding of web technologies at that time, and how to operate larger systems. And at pasla, I learned so much. And I'm really grateful for that. And I'm also grateful for for whoodle. Shout out to you for making this possible here. And I would have loved to work some more with Udo, but the company wasn't wasn't the right place for me. So yeah. And so that's how I got into Python. And I probably, that's my go to language because I can get stuff done very quickly in Python. And nowadays, it has types as well. But not strictly enforced. But yeah, that's how it went to Python. I love it. And we'll keep it in my tool shed for some time.

Tim Bourguignon 37:02
Very cool. Very cool. And so now you moved on to, to go and to a very different kind of company, right?

Kai König 37:09
Yes, yes. So I fitbark is actually a consulting agency, and they work for Tesla. And they started working on this concept of a visual programming language. And they demoed a very early demo, to us. And like, right at that time, I decided to maybe it's time for me to leave. And so I joined them very early on and the sacrus totally different. We now work in view and TypeScript and go, and still some Python microservices. Yeah, and we work on that visual programming language. Like sort of enables you to come up with a program with boxes and arrows, because essentially, programming is soft. And I don't think programs are that much of a needed resource and 20 years from now, so because everybody will have ready made tailored solutions, or can actually create solutions that automate processes and automate data aggregation or data entry. And that's why I think it's the space the entire low code, no code space is going to pick up some some pace in the next couple of years. And we're gonna see how it's gonna turn out. Like Recently, there was a launch of dark Lang, I don't know if you've heard of that doesn't ring a bell. Now, that was a huge launch. And it's a very new concept on part visual programming language part new operating and deployment model, because like they completely abstracted away deployment, there is no deployment where everything you change is life in an instant, which is kind of interesting. And you also have an ID that is sort of visual base where you connect different parts, different functions with each other through a visual way. So yeah, I think it's going to be really interesting for that space. Are we still need some some

Tim Bourguignon 39:15
solution or application developers that do this, this high level puzzle? But

Kai König 39:22
yeah, we Yeah, we do. So yeah, I think we're gonna have like specialists, again, that are really good at some specific technology. And we're going to have like, solution engineers for the large middle section we have at the moment where you have full stack developers who like sort of can do everything. I think this is going to shrink over time. Because I business people are going to be more enabled and the new generation Sort of knows their way around computers and knows better and like can come up with solutions on their own. And they don't need to be a computer scientists to know that stuff can be automated. And that's why I think that middle section, full stack developers, General programmers, will this will not disappear, it will just get smaller.

Tim Bourguignon 40:22
And if we don't want to face the same fate as the dinosaurs back then what would you advise the full stack developers of today? To start doing?

Kai König 40:33
Good question. So I think what's important for programmers is to focus not so much on technology, but more on how to actually deliver value. And in any sense of the word like in a product in a medical device, in a business application, just focus on getting getting a solution now, not focused on technical details, because they are gonna get abstracted at some point. And it's better if you know more about the general concept. And the products, then, you know, a specific detail about a specific language or framework that's going to be obsolete in a few years from now. So learn the basics and be strong on the overall concepts. Is this

Tim Bourguignon 41:30
is also an advice you would give to to newcomers.

Kai König 41:33
Yeah, absolutely, absolutely. So you could, I mean, most of the bootstrapping, and like boot camps, they focus on getting you out there. So there's a view boot camp, so you can be a view programmer. But I think you're gonna have a hard time than views not really cool anymore. And you haven't picked up some of the fundamentals around view, like how reactivity works. But JavaScript is what DOM is. And I mean, you would have picked up JavaScript by by that time you got on cool, but there are so many layers, you have to peel back to get to the basics. And I would actually recommend, like learning the basics, and they are underlying concepts. So you can apply them to the next thing that comes around. And you can be very quick to pick that up. And may that be a completely new language or a new tool or anything you will feel at home because the concepts don't change so fast as the tool starts at a tools to the DOM,

Tim Bourguignon 42:34
you cannot you cannot pick dues, dues fundamental Come Come concepts in a matter of weeks or months. So is there a future for the boot camps? We know the three months full time boot camps that we were you have right now?

Kai König 42:49
That's a good question. So I think that boot camps do a great service to the economy, because they get they fill a demand. So there is a demand for programmers, and because otherwise the boot camps wouldn't exist. And the demand is so large, because the on the other side alone on the consumer side demand are so large, and there's lots of money to be made. But in the end, there is a huge range of quality, I guess, and what comes out of those boot camps and what products will actually make. And what I mean by that is, so of course, if the quality is a predictor of the low long term success of a company, I think boot camps are very short sighted in that sense, and a short term solution that needs to like, get a bit more long term me. And I don't think boot camps are, are a bad thing, or will vanish or but I think they're they're self understanding will change over time. So more into a How can I support the growth of developers instead of like getting them off the ground? Because at some point, the demand is as fulfilled, and everybody has become a view programmer, and so what do you do? sort of get them to stick to being a programmer and teaching new tricks

Tim Bourguignon 44:28
or linking this to the discussion we just had before having boot camps as a to teach solution developers that don't program anymore, just that do this puzzle solutioning of getting getting one processes up to ground with as little code as they can?

Kai König 44:48
Yeah, this could also work. Sure. Absolutely. Same thing with demand supply and demand. So and I think Like boot camps are also a testament to the failure of the, like education system. Because I, they wouldn't exist if the education system was fast enough to react to the economic demand for talent. So I think there is something really bigger at play there. With the boot camps. I think they're good. And they're helping a lot of people that are like, willing to learn and willing to move on. And I think it's a good thing. But, as you said, and as a question goes, I have no idea where this is going. But I don't think it can operate in that way. It currently does. Because either the education system picks up or like copies to model a copy success. Or on the other hand, demand goes down, and they need to reinvent what they're doing.

Tim Bourguignon 46:03
I guess I asked my, my last question already, and then you answered in length vise know that that sort of school the the advices, you would give to them to new Congress, no industry? So let's, let's pick a different last question. Before we end, we can do you think there is a there's a special key skill or mindset that is not necessarily required? But very nice to have to succeed?

Kai König 46:35
Yeah, I think there is one. I've This is not really limited to our industry, I think. Because what I really value in people is if they can take something complex, and make it simple. And that applies to programming as well. So the simple solutions are elegant, like as a math, like everything in math, that a simple is a good solution, and is easy to understand and easy to replicate. And it has some sense of beauty to it, too. So I like aesthetics and math as well. But yeah,

Kai König 47:20
if you,

Kai König 47:22
you don't need to show off as a programmer, by doing the most complex stuff. You're a really good one, you're really a highly valued colleague, if you can make the complex disappear in simplicity. And that is something I would really look for in in programmers.

Tim Bourguignon 47:44
Very wise advice. Thank you very much.

Kai König 47:47
Quiet, but you liked it.

Tim Bourguignon 47:51
So okay, where could the listeners pick up this discussion and continue talking to you? Where would the appropriate place be?

Kai König 47:59
the appropriate place would be Twitter, actually. And my handle is Chi underscore. Richard,

Tim Bourguignon 48:08
will add this to the shows? Um, do you have anything on your plate coming up in the next month that you want to advertise?

Kai König 48:15
Yeah, so as I mentioned earlier, we're working on visual programming language. And we are still in stealth mode and private mode. And if you want to be among the first testers and want to give us valuable feedback and want to help shape the platform, just drop me an email, I would love to, to invite you to our beta testers and see where we can help you and see whether we're actually onto something. So could really like that. Give me Give me a DM on Twitter.

Tim Bourguignon 48:55
And you'll find the link in the show notes. Again, the listeners. Okay, fantastic. Um, then thank you very much for sharing your story that was absolutely fantastic and interesting in and I love the the whole discussion we had. Thank you very much guy.

Kai König 49:11
Thanks. Thanks, Tim.

Tim Bourguignon 49:13
And this has been another episode of developer's journey. We'll see each other next week. Bye bye. Dear listener, if you haven't subscribed yet, you can find this podcast in iTunes, Google music, Stitcher, Spotify, and much more. Head over to WWE WWF journey dot info. To read the show notes. find all the links mentioned during the episode. And of course, links to the podcast on all these platforms. Don't miss the next developer's journey story by subscribing to the podcast with the app of your choice. right now. And if you like what we do, please rate the podcast, write a comment on those platforms, and promote the podcast and social media. This really helps fellow developers discover the podcast and those fantastic journeys. Thank you.