#41 Simon Harrer on strong opinions loosely held
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Tim Bourguignon 0:15
Becoming a software developer is a never ending journey. Some developers started coding when they were kids. Some ended up studying computer sciences. Others came from very different backgrounds. Some taught themselves programming. Others went through apprenticeship programs, a few even jumped in yet boot camps. One thing is sure, no journey is void of bumps, forks, and hard decisions. Every journey is unique and full of learning that are worth telling. So let's ask developers from all around the world, how they got, where they are today. And how they grow.
Whether you are a junior Dev, starting your career and learning the ropes, or maybe a senior developer, pushing and guiding others around you, we have something for you. Welcome to the software developer's journey book.
Hello, and welcome to developer's journey, the podcast shining a light on Developers Live from all over the world. My name is Tim Bourguignon, and today, I receive seimone ha, Dr. c manohara. I would say, semen is a senior consultant at the company ino Q. In his daily business, he fights for simple solutions with domain driven design, fitting architectures such as microservices, of course, but also monolith, and clean code in Java, Ruby, or even JavaScript. Most recently, he co authored the book, Java By comparison, that helps Java beginners to write cleaner code via before and after comparisons. Simon, welcome to dev journey.
Simon Harrer 2:21
Hi, Tim. Yeah, glad to be here with you.
Tim Bourguignon 2:25
It's a pleasure to receive you. So before we come to talking about your most recent work, maybe your book or maybe I think you have different topics to talk to us about. Would you mind telling us your story, how your career started, maybe what the roadblocks and the bumps were? And what led you to finally be in this position of writing such a book?
Simon Harrer 2:51
Sure.
Simon Harrer 2:53
It's really hard to think about when to begin a story I first thought about maybe my first computer I worked with I played with as a young very young child was an Amstrad, an M start with no hard drive, just two floppy disk drives one for the operating system, one for your application. And that's basically was my first contact with computers that at all, and I played gorillas where you throw bananas at each other, or played snake was That was great. And somehow this this playing game stuck. I played a lot during my school time, maybe you know, Warcraft three, that's a real time strategy game. And kind of wasted. Well, it's not wasted. I really enjoyed my, my long hours playing those games. And I didn't really program at all, or basically not at all during during school time. So it's really my life as a developer started actually with with university. And since then it did Went, went quite quite well. I think that the very first project I really, really developed was right before starting at university, so I had this in Germany, we have this that the school ends basically in I think, July or June or July, and the semester starts in October, and so you have a few months in between, and I did like a summer job at Siemens, and they they said okay, here, we need an Microsoft Access database. And they asked me, can you do that? And I said, Sure. And so after I got the contract, assigned the contract, I went and bought the books about Microsoft Access, because I've never worked in anything with Microsoft Access and Learn it on the fly. And always. And so we've started basically with imperative programming. And a lot of go tools go to era, really spaghetti code.
Tim Bourguignon 5:16
I say about it was on my spine.
Simon Harrer 5:18
Yeah, that was really a great, great experience when you think about is that the very first project is spaghetti code. And but it was very close to the user. So so it was really a child and led way. So I worked on something for one of you have one or two or three hours, and then I went to the stakeholder and showed him that. And they said, Yeah, that's good, but that should be better, that should be changed. And they changed it and went back. And so we had really, really fast feedback cycles. And that still, despite the spaghetti code, that was that was really fun.
Simon Harrer 5:55
And
Tim Bourguignon 5:57
which, which studies did you get into? I mean, was it was it computer science, oh, it is something else.
Simon Harrer 6:03
Knowing where I started in in Bamber and this, basically mostly Information Systems there. So no actual computer science, we have applied computer science, but no classical computer science. And I think, then, then I really, really got got into teaching quite quite quickly. So in my third semester, I was asked to become a teaching assistant. And since then, I taught I think, 11 courses to my till I finish my degree, as a teaching assistant, was really, really interesting and ensure the Nice, nice, steady income for my, for my own hardware for my own computers at home.
Tim Bourguignon 6:52
How did this happen?
Simon Harrer 6:54
I think, I think it was, I really like teaching it so so I really enjoyed doing that helping helping others and
Simon Harrer 7:06
yeah,
Tim Bourguignon 7:08
did you ever have an experience in teaching before?
Simon Harrer 7:12
No, it was learning on the chop. So there was some some tough situations as well. When you when you have students that want to mess with you, or ask you questions you don't know and or ask stupid questions. But questions where they where they want to see you struggle. And so I learned a lot and he really really enjoyed it and and when after, shortly before I got my degree I was asked by a professor there if I want to join as like PhD student and so I stayed at university and yeah, did even more teaching later on
Tim Bourguignon 8:02
was your your PhD about
Simon Harrer 8:06
the the PhD was more about business process management systems was a very interesting part of my life. But I'm glad it's over now. It's It was really very tough years. So it's not something I really burn and can can talk a lot about a want to talk a lot about. I, I lived much more for the teaching part. While I was at a PhD student there, because we had this this unique situation that colleague of mine and myself, we were able to really build up two brand new courses at university, one about Java programming, like nio testing, MVC, and Java FX, and another about concurrency on the JVM. Including TCP connections, aka framework and the basic stuff like synchronized or semaphores. And so on. And this was really great. So So basically, we had the playground for developing developing two courses. And while I gave them six years so so I gave this these two classes six years
Simon Harrer 9:33
it was really a great time.
Tim Bourguignon 9:36
What What attracted you so much to teaching I
Simon Harrer 9:41
think it's
Simon Harrer 9:44
the one on the one hand, it's when you teach you learn a lot more about the stuff then you and you thought you can ever know before, but I really like to help people and bring them forward. I think that's this this Quote, it's going around a lot in on Twitter and stuff today to say a 10 x developers, someone who helps 10 other people become better. And I wouldn't say that I'm a 10 x developer, but I really like this this idea of helping others and, and that that's the really important thing. We should we should do help help others and a lot of beginners. When you think about it University, a lot of people come there every semester every year and and want to learn to program and they don't know it yet. They have to start learning it. Yeah, from the ground up.
Tim Bourguignon 10:41
Do you do you miss this time?
Simon Harrer 10:44
Yeah, yeah, a little bit, why not little bit, I really, really miss it. I think
Simon Harrer 10:49
I,
Simon Harrer 10:51
I have another like it, we help each other out in our team, of course. And the style of learning changed a lot. But I really like this university style of learning as we did it, because in our courses, they are very, very hands on focused. So basically, we had always had like a block where we presented a few slides and told them about a new technology or new method or something new concept in framework. And then they had to develop short exercise. And then we discuss this short exercise made a basically a code review together in the course. And then the later on they they had to do a group work, where they really tested out the framework or the concept or whatever we taught them in a two week project in a group of three. So very hands on style of teaching. And those those projects, those two week group projects, they handed in and we graded them, we did a really thorough code review, and gave them detailed feedback.
Tim Bourguignon 12:02
That's, that's very hands on that's very, actually a very close to what we do on a day to day basis in the industry, and how we, how are you influenced by, by the, by the best practices of the industry to, to craft this course.
Simon Harrer 12:21
I think the the, our own word distributed systems group and a lot in our free time, we worked on chapter F, which is an open source project for Bibliography management. And it's a very, it's a very old Java desktop application. And we try to employ a lot of good practices now learned a lot, and really, you know, created a community or revived that community basically, on GitHub for that project. And so we had a lot of experience doing code review there, and have practice practice to. But I think one of the main influences, obviously, our books like the ENCODE effect of Java, or factoring, so my colleague, and myself, we really have read those books one or two more times and really try to live up to those standards.
Tim Bourguignon 13:29
Have you? Have you talked to two companies to see how they how this, they see this curriculum that you built?
Simon Harrer 13:40
I'm not not really that that much. I know, from some companies, they are very fond of that. Because a lot of the interview questions are based on the things that we taught. There was there was interesting to see. So they really said okay, well, there's there's this few questions. And if, if the student can answer that, that's a very good indicator of a good proxy for being a good developer later on. And that was that was interesting to, to learn about that.
Tim Bourguignon 14:21
Yeah, when thinking about my own experience, what I learned at university University years is miles away from my true describe, it's it's not at all things that I reused in my career. After we add, I learned how to learn, but it didn't learn how to how to program back then. And what you're describing is, is all the things I've been ranting about when I think about students say, well, they should be doing code reviews in class, and they should study clean code in class. And so I'm amazed to hear that oh, this this is great.
Simon Harrer 14:58
That was really great. Great. Time. And while if fun funny note, we were nominated six times for the best teaching award our faculty, and in the last year year we basically wanted. So maybe that's also a sign that that students because students had a lot of saying in giving away those awards. And I think that's really their their way of saying yeah, this is the we really learned a lot and and it really helped us tremendously.
Tim Bourguignon 15:29
Congratulation. Um, so how did this influence the jobs you chose afterwards?
Simon Harrer 15:42
quite quite a lot, actually. But it's the most influence later for me was when when you work at, at the university, or how I worked at the university with my with my supervisor, my boss was very, like freelancing. So we had a very, very high degree of freedom, as long as the like, the lecturers were on time, and we did our job. Well, we didn't have much control, we just, we just did what we wanted to do. And and because we were enthusiastic about it, I think we did, we did quite good. And and I wanted to have that experience and company later on. And I want to have this freedom, this, this trust from Boston, me that I will do the right things. This and I think in Tokyo is one of the companies that that really, yeah, trust your song so much. That that you can do that. Now. For instance, when you started in QE get access to the Amazon account of the company. And if you need something, you just buy it, and it's automatically paid for by the company credit card, and you just shipped to your home. So this is really how they trust you. And that's, that's how I want to work.
Tim Bourguignon 17:12
And how did you discover that? You know, q was the right fit for you? What was it the first right, what is the first company you entered? And it was right away? A perfect match?
Simon Harrer 17:23
No, I interviewed a few companies. But I think you know, q was under the top three. And I learned about it basically during my PhD so I met another another person who worked at in ACU already at the time was but had still connections to the University of Stuttgart. And we both, you know, research on the same topic on BPM engines. And so yeah, kind of so that's, that's how I got to know about the company. And then when you look at conferences, you notice that name, and it is that's why I kept on hanging to that idea that might be a still might be an interesting place to work. And yeah, it is, that is really great.
Tim Bourguignon 18:19
Cool, and you've been within the queue for how long?
Simon Harrer 18:22
It's since a pronoun, so it's not that long.
Tim Bourguignon 18:26
No longer doing BPM engines anymore?
Simon Harrer 18:29
No, thank God, I think that that chapter I closed and and for good.
Tim Bourguignon 18:37
Do you want to briefly say Why?
Simon Harrer 18:40
I think it's, I think there are two two answers to that. When you do a PhD, you work like five, six years on something. And at one point, you say, Okay, I worked enough of my life on that. That's, that's enough. I want to move on. And the second answer is I think that these workflow engines or process engines are mostly favoring a central style of application. So And today, we often want to work in a more decentralized way with small applications with small teams, lightweight applications, and all those things are another good fit for workflow engines. But still, when when I when I come in and look at industry projects, we often want to have the central view on on the workflows or processes that that trickle through our system, where we can say okay, this is the audit process and where are we now and for that customer, where do we stand? So we basically reconstruct from from multiple small systems reconstruct that central For a few on the central customer centric view, on the, on the workflow, so our processes that are inherent in our system. So there, that's that side that idea I still carry around with me.
Tim Bourguignon 20:16
I think thank you for the answer. And since you're not doing it any BPM engines anymore, what do you do it, Nick you?
Simon Harrer 20:25
Um, well, we Okay, how do you say, um,
Simon Harrer 20:32
at the moment I'm working on, on a project with and to other interview colleagues, and we are working a lot with coordinators and building. Yeah, I would say, Spring Boot applications that integrate asynchronously through Kafka. In an e commerce setting, that's very, very interesting project. I really, really like that. But that that's the funny thing. I still like technology. But what I recently came upon how we should work together how our team should work. And I recently stumbled about or assembled on remote mob programming. So so in the team I talked about, we're doing precisely that we're doing remote mob programming since last August. So at this point of time in recording, it's about five to six months. And I don't want to work in any other way anymore.
Simon Harrer 21:45
And I want
Tim Bourguignon 21:45
to learn more.
Simon Harrer 21:48
Okay, remote programming. Yeah, no problem. mob programming is when you it's a little bit like pair programming, but nothing at all. So basically,
Simon Harrer 21:58
you have
Simon Harrer 22:00
three or more people working at the same problem at the same time, on the same screen or computer, but with only one keyboard. And we are doing that remotely. So that means that on that we are not sitting together in one room and have one computer and one, one keyboard in front of us. So we're sitting at home with our own computer, our own keyboard on screen. And we're still doing more programming. And I think that's the perfect symbiosis for was a perfect solution to any problems we ever had with remote working.
Tim Bourguignon 22:46
Let me see if I got this right. So there's, um, you're all sitting in front of your of your computer, obviously, because you're remote. But at any given time, there is only one person typing stuff into the codebase.
Simon Harrer 23:03
Exactly.
Tim Bourguignon 23:04
And all the others are are helping Oh, how do that works out?
Simon Harrer 23:10
Now we have specific roles. So the one who controls the keyboard is the typist, only the typist is allowed to type and the rest of the mob all the other ones and they discuss what problem should be tackled how it should be tackled, and give instructions to the typist. And the cool thing is the typist is actually a like a very high level human computer interface. So if the type is good, I can say the typist, please.
Simon Harrer 23:45
Yeah, we need we need a new field.
Simon Harrer 23:48
We need need a field in the database. new email field we haven't we haven't had an email field yet. And we need to get that email field from the users, the user has to input it so we need a form. And that basically should be enough for a very good typist to just tap start typing and implementing that what you want and the rest of the mob would watch and immediately do a code review or change directions that they see that something sounds look strange. And yeah, but make cos correct. And then we switch so basically every 10 minutes, the type has changes. And another one from the rest of the mob becomes the typist and the previous typist joins the rest of the mob.
Tim Bourguignon 24:40
Is this 10 minutes. timeframe. A guideline from whoever invented this. I think was it woody woody zoo? I think invented mob programming.
Simon Harrer 24:53
Yeah, what he
Simon Harrer 24:55
invented mob programming and they I think they use a lot shorter term I think seven minutes he said some, some presentation I think we are doing remote remote more programming. So we we kind of tried out different timings and we ended up with 10 minutes. And was that worked out quite well for us.
Tim Bourguignon 25:20
Um, when when would you recommend somebody doing this?
Simon Harrer 25:27
As I said, I don't want to work any other way anymore. So I recommend doing it always. But there's really no exception. I, I think every week, some people bring up arguments against how maybe maybe not for simple stuff. And then we realize that in simple stuff, we do a lot of copy and paste errors. And because we tried to do shortcuts, and the shortcuts hurt us afterwards. And that's why we need a very thorough code review. And more programming or remote more programming gives that.
Simon Harrer 26:04
So I don't I don't know any real
Simon Harrer 26:08
situation where I don't want to work that way.
Tim Bourguignon 26:13
Okay. How about other people? Do you think everybody is is is fit to work in a mob? Not necessarily a remote mob, but but in a mob?
Simon Harrer 26:26
That's, that's a very interesting question. Um, I think when you can't work in a remote mob, it will be very hard to work in a team at all. So you have people that that have a tough time working in a team together. And if you can't work in together as a team, you remote more and more programming won't work either. And that, that being said, one characteristic that's really, really important for for more programming, I think, is to have strong opinions loosely held. That means that you take positions, but if you realize that your positions and justified you, you compromise, or you switch to to a better position, you let you get you can be convinced by argument, you don't just stick to your to your ideas and say, I always did that, like that. And I was want to do that. In the future. I
Simon Harrer 27:34
think that's crucial. That's interesting.
Tim Bourguignon 27:38
That's very interesting, strong opinions loosely held. How much just is is the recipe for, for good teamwork, actually.
Simon Harrer 27:53
I think what programming is, is teamwork at its best. Because you work on everything together. And you decide on everything together. So your decisions will always be very, very good. So group decisions are typically much better than decisions by a single individual. And when you think about programming, it's not about developing, it's not about how fast you can type, how well you mastered Emacs or whim. But it's mostly about what not to write, what decisions you make. So what design choices you make, what trade offs you discuss, and and decide on which side to lean on on a trade off. And all those things that that benefit from tremendously and profoundly from a group decision. And from the input that group can bring.
Tim Bourguignon 28:56
It really sounds like like a litmus test or the canary the canary in a coal mine. If If your team manages to, to adapt to more programming, then it is indeed the team. And if they don't, then well, you have a problem. And I think that's very interesting. Have you have people complain, or they'll tell you about introverts versus extroverts in this context?
Simon Harrer 29:31
Hmm, no, not yet. We only have X i only have more programming experience in our team. And we were kind of all tending more towards the extrovert side, but not extremely so. So it's, it's we don't have the the extremes in both sides and our team so I can't really say a lot about that. But I think it's an interesting one. One idea because I discussed it with a colleague once. introvert people may feel safe to say something in a remote mob, because even the most extroverted person becomes the typist and the typist doesn't discuss the type is just receives instructions from the rest of the mob. So this opens up the chance for introverts to participate in the discussion if there's a very strong extrovert person that dominates discussions too much. The type is basically puts you in a humble position, because instead of Yeah, steering the ship, you're just the this Seaman that that I don't know has to has to set the sails and get instructions from the Hampson.
Tim Bourguignon 30:54
I see I see, I've had a bit of more programming not in a remote context, but more programming experience. And one thing I struggled with were a few colleagues that kind of needed time, alone time to process things. So in my mind, these were kind of introverts, maybe it's not the right word, but I'm struggling to find the right way. And really what they needed was was to, to stop the flow at some point and just summarize what happened in their mind and hit the Post button. And just just try to get things sorted out in their mind. And my, my feeling was that this mob programming was preventing this because the the flow was continuing, and they couldn't just hit the Post button, and do something for them for a while and then come back how we solve that was, but it's saying, Well, if you feel that you need this time, at some point, just step out of the mob for a while, process things and then come back. But I'm not sure if this is the right way to do it. That's been interesting to ask to the the Guru's of mob programming, I think one
Simon Harrer 32:13
comment to that would be. So we our problem was that we didn't take any breaks at first, we just went on because the flow felt so great. We went on and on and on and four hours straight five hours straight. And that was just too exhausting. After a few weeks of that we were really, really, really exhausted. And you felt that physically. And so we have force brakes, and also to process that. Maybe Maybe that the focus on brakes could help could help as well.
Tim Bourguignon 32:55
Yeah, so that's a great idea to enforce really schedule, maybe two to two pomodoro rows, so 25 minutes twice, and then break something like this. That's the video.
Simon Harrer 33:10
Yeah.
Simon Harrer 33:13
At the moment, we are we are writing up a short infosight about how we do remote more programming and how others can can learn from our ideas and searches. So let's I I will put the link in the show notes. But it's not yet upsell, maybe a few months in a few months, and in the future, we will we will have something to show you.
Simon Harrer 33:36
Cool.
Tim Bourguignon 33:38
I hope the podcast is for is forever. And I come back to it in 10 years or 50 years. And I've still learned something. And then by the end it will be up right.
Simon Harrer 33:50
Well, it should be it should be up in a few months. I'm pretty sure about that.
Simon Harrer 33:55
Cool. Do you want to talk about your book?
Simon Harrer 33:58
Oh, yeah, that we kind of made a little bit of a detour through the document and remote programming Yeah. to maybe close close the link about my my teaching experience and and crafting those two courses at university. We had we did a lot of these code reviews of the, of the code that students handed in, in their two week projects. I think I think it was really a lot of work. I don't recount the hours. But was a lot of Java code that that we went through and we always gave very detailed code review. So we so we would create a criticism, some some some answers for them. And it was basically always the same answers. Wow. A similar answers popped up because what students made similar mistakes over and over again. Each new semester new students would come and they make the same mistake. As the students one year before, and we had to write the same answers to their mistakes. And that's that's how we came up with a format of saying, Let's how you did it. And that's, that's bad, because maybe use that code because that's better when we describe why it's better. And this, this, this concept stuck somehow. So when you think about it, that's basically the best code review. You can get. When someone say, okay, you did it that way. This, this has a few flaws, I described the flaws very detailed for you, and then say, so maybe do it that way, and provide you a specific suggestion how to fix that. And say, That's better, because wouldn't you? Wouldn't you agree, that's kind of what you that's the perfect comment on anything in your code review would not?
Tim Bourguignon 36:03
Definitely, definitely.
Simon Harrer 36:06
And, and we gave them precisely that. And you know, the students and and we did that over and over again. And at some point, we thought that might be interesting, for like writing it up, and really putting effort and very good explanations on why something is not so good, maybe not so readable, and why something is now more readable if you apply a few minor tweaks. And that basically, was how the book concept came came into being. And then we wrote our short proposal, send it to a pragmatic programmers. And a few days later, let's say they said, Yeah, sure. Great. write that book. And we said, Wow, that's, that's fast.
Simon Harrer 36:57
And then the one yes, journey started.
Tim Bourguignon 37:02
Yeah, and this is exactly how it feels. So the book is called Java by comparison. And this is really a comparison work. So what you described is exactly how I felt, reading through it. Really, here's a naive way of doing it. And here's why we think it's bad. And he would be a better way to do it. And here's why we think that would be better. And here are the advantages. And here are the things that you maybe will never think about in the next five years. But at some point, you will, and this is why you didn't vote in that cetera, there's really a comparison between two states. And that makes it really easier to grasp and easier to understand from from one state to the other. So I really relate to it to what you just said, that is a great approach.
Simon Harrer 37:50
We sometimes think about it as like a mentor, you know, a mentor with infinite time, because the best mentor would do precisely that. But mentors have limited time. In the book. Well, it's papers patient would say, and you can you can you can use that and yeah, help you help you get better. And actually, when you when you think about chama By comparison, the charter part isn't that important. Some Some people even suggest that maybe we should call it clean code by comparison. Because not about Java, it's about writing more readable code.
Simon Harrer 38:32
clean code. But I think
Simon Harrer 38:36
even better title would be cleaner code by comparison. Because it's not absolute. It's it's just getting a little bit better. Because absolutes are always impossible. So so maybe cleaner code by comparison with Java examples basically, would be would be better.
Tim Bourguignon 38:58
Nice idea. That's for your next book.
Simon Harrer 39:01
Maybe maybe Yeah.
Tim Bourguignon 39:03
How hard was it to to come up with, I think 70 example yet? Or maybe reduce the number of examples to 70 I don't know which which way it goes.
Simon Harrer 39:15
Yeah, in between, we had 80 examples in the making so so even when you when you look around on the internet, because book titles don't change, when they are published once there are some some pages that still say that 80 examples in the book, and not 70 reuse it to get finished. So basically, what you always do in a try projects, you reduce scope, because you don't want to sacrifice quality or time. And that's what we did we reduce it to 70. And we have still a backlog of a few items we could discuss, but it's always hard. You know, what, what should you talk about? And how can you make it live up to a certain standard. So we really did a lot of Yeah, thinking about what is really valuable. What do we want? Yeah. Second, a juniors. Yeah, to teach. And maybe maybe we'll be able to write something about Java concurrency. Because we rather skip that part in the book. I think only one item is about concurrency, one or two.
Tim Bourguignon 40:33
Now, there you go. You have a second book?
Simon Harrer 40:36
I'm sure.
Simon Harrer 40:38
Let's see. Let's see. Let's see what my wife and my child will will say about that thing. They like their time with me as well.
Tim Bourguignon 40:47
Now, I don't ask them, they're always running dreams. But that was a nice segue. And speaking about about junior or junior programmers, what would you have liked to know when you started? Something that you didn't know? And now he would say, Well, if only I had known this,
Simon Harrer 41:14
the fastest way to learn is in a mob programming session. And I would have liked to do more what I would have liked to do more programming much more when I was younger, because I think that's really supercharged learning. I haven't seen any faster way. And if you do that for I don't know, a year right after university, I think that would be a kickstart for every junior developer starting at a company.
Tim Bourguignon 41:50
Did you think you could, you could teach this way.
Simon Harrer 41:55
That's, that's interesting. I never considered that.
Simon Harrer 42:00
Teaching is somewhat always focused around in the video scores, individual examination, in Germany at university. That's, that's so in university diversity context, I think it's, it's hard. But maybe worth a try. I think an industry industry could really profit from that model. Because they, they can do what they want. They don't have to do this, this art examination.
Tim Bourguignon 42:31
This is where I've used it most is when teams have some very scattered knowledge, and somehow need to, to spread know how, between the team members. This is where in my opinion, mob programming really has a key learning element. Of course, in the quality of the work produced, etc. but but especially in this case, this has proven very, very nice idea. But I would be I would be interested to see how it works. When you have a very, very big knowledge difference. Meaning if you had a team at the University with one TA, or or a teacher, and and students and mobbing all together, if this could work, or if the knowledge different is so huge, that the the the teacher cannot be part of the mob and has to somehow influence the mob from outside, which kind of would be
Simon Harrer 43:30
bad. I don't know.
Simon Harrer 43:31
That's something.
Simon Harrer 43:33
And I think it works. Because I think that would work when you think about that. The teaching assistant would actually be the expert that joins the mob for a speech short period of time. And can the whole mob control the knowledge from that expert during that time? And then the mob can still resume the work. And then at some point later on, the expert would shine the mob again. And they can then get what the next step, the next knowledge package basically out of the of the expert. Think that would work. Yeah. Interesting. And because the expert never becomes the type of the expert always stays in the rest of the mob and takes part in the discussion. And and we try to use that as well, in our project. So we had an expert for Helm tool for deploying something to Cuba natives. And this was that was really, really helpful. And you don't need a lot of time with them one or two hours, and we really had a very good feeling what we should do with Helm and where we rejected helm, but during that time, we really tried it out and could evaluate whether we wanted to use or not.
Tim Bourguignon 44:58
That's interesting. You You still have contacts with the university. And real send send some some ideas over there. I would be very interested to know how that goes. That sounds really interesting.
Simon Harrer 45:11
Yeah, we'll try to I have some I know some people back there so yeah, maybe maybe they will try it out. Let's see.
Tim Bourguignon 45:20
Um, unfortunately, it's been already 45 minutes we spent speaking Time Is Flying like crazy. Um, did we miss a topic you wanted to talk about?
Simon Harrer 45:30
No, I think we could talk on and on and on. I think we kind of hit it off yourself. I don't I don't want to open another another box.
Tim Bourguignon 45:44
That's fine. Um, is there something coming up on your plate in the next in the next weeks that you want to plug here make some advertisement for it or something like this?
Simon Harrer 45:54
Well, we try to come up with this remote mob programming, microsite and I think that would be that will be very interesting. And it's basically what what i what i want to to see that other people's, our people pick up on remote more programming, and I hope that that it will make their professional lives much as as great as minefields today.
Tim Bourguignon 46:22
So if people don't want to refresh the the show notes page, every few days, where should they look? After after information from you to know that this, this this information or website is coming out?
Simon Harrer 46:41
Just follow me on Twitter. I think that's that's the easiest part. And then you you won't miss it. I will make sure that I have that.
Tim Bourguignon 46:49
Okay, so I will add your Twitter handle in the show notes. And then people can can follow up there. From there. Great. Cool, cool. Well, um, that was great. Thank you very much for coming on through.
Simon Harrer 47:05
Yeah, it was a pleasure. Thank you.
Tim Bourguignon 47:08
And this has been another episode of developer's journey. We'll see each other's two 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 www dot 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.