#91 Harald Reingruber is embarking on a coding tour
⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes
Harald Reingruber 0:00
The team I joined, were already on a quite a high level from a software quality perspective. But I would say the most learn from the things of course, which didn't go that well, they already started a couple of years before I joined them to write a huge amount of automated tests, but most of their test suit, I don't know 90% were all integration tests. According to the test pyramid. It's not a good idea because they're all they all run very long time and they are very unstable. And, but all right, also learn this. Semi optimaal tests are better than no tests. If I can choose still better to wait a long time for feedback. Compared to you don't have any feedback at all.
Tim Bourguignon 1:00
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 receive Harald Reingrüber. Harald is an enthusiastic software developer with 10 years of professional experience working in different areas of visual and spatial computing. He likes delivering high quality software, but he also likes working on prototypes, and MVP. So Minimum Viable Products for measuring traction before adding later on, require complexity. Inspired by Peter (the code cop) Koffler, Hamitai Schleier, Cory Haines and probably many more. He decided to go on a pair programming tour in the US in March and April 2020. So right after this podcast here, and I hope we're going to talk about Harald, welcome DevJourney.
Harald Reingruber 2:00
Hello Tim, welcome. Thanks for having me.
Tim Bourguignon 2:03
Hey, it's my pleasure. It's my pleasure. So before we talk about your journey, your tour that's coming up. Um, let's go back into your past. And we went taking you through the first steps into it when you first entered this, it worked. Oh,
Harald Reingruber 2:18
wow. Yeah, I have to go back in time quite a bit. I started learning programming when I was in a Technical High School in Austria. I was about 14 years old. Yeah. So I'm already quite long in this in in our industry. There's one thing I remember Oh, well, after a couple of years learning different programming languages. I still remember how frustrated I was that I still couldn't imagine how a computer game could be programmed. So I think that's where the curiosity about computer graphics And we should computer visual computing structured where you player. Well actually, that's the funny thing. I never really was a gamer. I, well, I tried quake and Well, I mean, I was like maybe 12 or 14 I loft, playing computer games. But when I started learning programming, suddenly I wasn't interested in gaming anymore. It wasn't really interested in figuring out how it can be developed.
Tim Bourguignon 3:36
And what what what attracted you at first to word programming and then to a word, game programming maybe or visual programming?
Harald Reingruber 3:44
I guess it is my curiosity. Okay, if I cannot imagine how it's done, how it works, I want to know more about it and want to figure out how to do it
Tim Bourguignon 3:58
and so Just the the annoyance of not understanding how that works.
Harald Reingruber 4:03
Tim Bourguignon 4:07
That is cool. That is cool. But But why computers and not maybe electro technique or maybe fluid mechanics or whichever plasma physics? Why computer science?
Harald Reingruber 4:21
Good question. Actually, I don't I don't really know but probably because we had a computer at home and I was able to play around and while playing around figured out okay, I can change things I can break things but I also can fix it to my parents were really happy that after breaking it, I was even able to fix it as well. And so then I discovered I was quite good at it and and learning to understand How our computer thinks and yeah, I think that's maybe that you don't need many tools you don't need not really overly expensive equipment.
Tim Bourguignon 5:13
Yeah, you can have a computer at home. It's hard as we have plasma head on. Yeah. I or Yeah, the worst thing that can happen and he's happens to me quite often is you have to format the whole machine because doesn't work anymore. And then your parents are obviously mad and they wanted to fixed as soon as possible. But that's probably the worst that can happen, right? Yes. Okay, so you were in this Technical High School in Austria and you started goofing around with computers and getting hooked into this. How does this work? How does this looks like from there? When did you decide that it could be a career choice? And then where did you take Get from there
Harald Reingruber 6:00
afterwards I decided Yeah, I want to learn more about it and went to a dip my bachelor's degree also in Australia or close to where I grew up. And there I remember there I did an internship at Diabla Research Center in Germany. They are really the curiosity about computer graphics was originated, the internship was more about simulating some entering control system. So we were like developing testing and simulation environment for c++ module which was developed by one of their researchers. But our supervisor he introduced me to the computer graphics team in the they are and showed me what they were doing with With 3d computer vision, and I was really fascinated, and also during the degree, we briefly touched medical image processing. Yeah, and really loved it. I wanted to know more about and later then I found out at the university in Vienna that there is a master's degree with a focus on both things on computer graphics and on image processing. And that's where my my education continued, can you understand
Tim Bourguignon 7:34
why you were so attracted to the visual part of computing are still attracted to this because computer science is so wide you have so many fields that you probably don't understand it either. So why why this visual part?
Harald Reingruber 7:49
I think, because the results are more visible. I think that that's also for sure. several reasons, but Think that you could show it to somebody who is not an expert or is was not really into it and he stills he is able to understand the result and see what what you were achieving with this project. Yeah, I think that's something I,
Tim Bourguignon 8:20
I liked about it. Were you tempted at some point to go into more for instance, web design, which would be exactly the same kind of very fast visual feedback?
Harald Reingruber 8:30
Tim Bourguignon 9:52
I'm sure that's not true. Okay, too soon. So you you were finishing your your battle and You did this internship with Daimler Research Center. Did you continue with Daimler? Do you What did you do after this special? How did you first job maybe look like?
Harald Reingruber 10:09
Yeah, no, I yeah, I did a master's degree in Vienna for computer graphics and image processing. I went into medical image processing. I, my first job was at UCLA health care. And he were developing radiology software. Yeah. And I, after some time, I became the principal developer for the volume rendering engine and that Yeah, that was really interesting, because it was really performance critical, high, highly optimized, c++ code and processing huge amount of data and also very, very visual such a component when a picture healthcare Image Processing? In my mind, it's mathematics all the way from top to bottom. Is this correct? Is this really image processing with AI using frameworks? are you creating your own rendering equations and, and image manipulation, etc? You're right everything computer graphics and, and image processing. It's pure mathematics. But yeah, it's it's like in with math in school. If you know the basic formulas and basic computations, then you can do a lot of things. Well, if volume rendering, it's a bit more complex, and you usually have basically followed a paper follow a paper somebody where somebody describes an algorithm, and so you should know how to implement the formula but you don't have to invent to invent the I written itself
Tim Bourguignon 12:05
92 somebody did the research and and coined the or prepared the way you should do it. And you're basically engineering this idea.
Harald Reingruber 12:16
Yeah, exactly. I mean, sometimes it's, of course it overlaps. So sometimes when you do some optimizations, and usually in the paper, not everything is the opportunity to get the appealing result. You might tweak stuff, then you also like you have to add to the whole interaction and so on. And yeah, maybe maybe you even are able to improve stuff then you probably write your own paper. But yeah, I in my department, we were not so much. Researching we were integrating. We were focusing on the product, part production. Can you say that? Actually,
Tim Bourguignon 13:02
I have no idea? Let's go in it.
Harald Reingruber 13:06
Yeah. Yeah, to make about x out of the research prototypes, that approach. And yeah, it was also that time where I became curious about how to fulfill high quality software requirements, like the healthcare software field is highly regulated and you have to provide a lot of documentations on your audio working. And it was also the first time I got in touch with software testing, unit testing, and so on. And that's how I got curious about how to provide high quality software.
Tim Bourguignon 13:55
Yeah, I worked in healthcare, as well for for a while though. FDA audits that you get every so every now and then, and the whole tracing of requirements and the whole classifications of devices and showing that you did the right thing, this is this is really a big, big deal. So if you if you want to, if you want to be able to produce some, some, some software, some hardware for the medical industry, you will have, you will really have to show that you know what you're doing. It's it's less of showing that the product is bug free. It's more of showing that you know what you did, and if there is a bug that occurs, you know exactly how to react to this.
Harald Reingruber 14:39
Yeah, exactly. This is a
Tim Bourguignon 14:40
pain in the ass, but in some sense, it makes sense. Okay, and so I guess I've lived a similar path, and also discovered pretty much at that point when I was working in the healthcare industry. What it takes to produce software that's really high quality that is tested from from bottom up and up to down and left to right. How did how did you learn this? How did you discover all this this world of software quality software metrics, testing, static analysis, dynamic analysis, etc? How did it come to you,
Harald Reingruber 15:21
the team I joined, we're already on a quite a high level from a software quality perspective. But I would say the most learn from the things of course, which didn't go that well, they already started a couple of years before I joined them to write a huge amount of automated tests, but most of their test suit, I don't know 90% were all integration tests you according to the test pyramid. That's not a good idea because they're all they all run very long time and rarely Insert table and that will rate also known as semi Optima tests are better than no tests. If I can choose still better to wait a long time for feedback compared to you don't have any feedback at all.
Tim Bourguignon 16:16
So if we're going through this, so you had integration test with means tests were pretty high level depending on other systems or components and not not moxa not mocks, not fakes of those of those interfaces. And so the tests were a bit slower than they could be it's not unit tests that are just on the bare metal and working hundreds of second it was more in the in the seconds or minutes level do stairs since the depend on third party software or third party API's, etc. They tend to fail at some point because reasons because the network didn't play nice that day. And so we kind of tend to become brittle and produce more problems than they should be. And what you're saying is, but this is better than no test at all, because then you probably don't know what you don't know. Is I mean,
Harald Reingruber 17:12
yeah, exactly. It's a good start. So have a bad test yet, and then you can improve from there. There was a good reason why it went this way, because the tests were fast to develop. So they were like directly interacting with the user interface. So you can write the new tests with a couple of lines of code, telling the test to click this button or to move the mouse track or double click or something. But the costs were that execution time was very long. And also they became unstable because if some pop up menu was blocking the mouse or something didn't shut and suddenly the test was failing, even though Yeah, you always had to debug to figure out why it's actually failing. And it and we did a lot of screenshots comparison for the tests. Yeah, sure. I mean, I do also understand from a regulatory perspective, it's also appealing because you really can prove like, okay, we have this test, the screenshot recorded how visualization in the end looked like. And you can be quite certain if all the tests are green that every pixel looks the same. But yeah, usually you would like to have a better mixture. The integration tests are really good also for roofing that. Rendering results are the same as men you had when you did the certification process, but on The developer experience for sure is better. If you have much more unit tests, much more low level tests, which tell you exactly where the bug is.
Tim Bourguignon 19:10
Were you able back then to already? Move some tests down the pyramid? So going from this integration level two more unit test level?
Harald Reingruber 19:20
Yeah, actually, we realized in the team that the disadvantages of integration tests and so we we try to motivate other developers. Yeah, try to think in which case unit test works better.
Tim Bourguignon 19:36
Let's let's fast forward a little bit. You stayed in this job for a few years, you became the principal volume engineer a volume rendering engine engineer, I as I listen, yeah. Then you probably moved, move to a different job. How did this this understanding of software quality and what it takes to produce quality software change over the years
Harald Reingruber 20:01
and it's a really good question after after my job in the healthcare software industry, I joined the startup we're focusing on augmented reality they are It was a quite a shift from where he came from, which I also liked because it was much more hands on Okay, we have to get it working, we have an idea, we need fast results and but unfortunately, the quality requirements were not so high Of course, and also their willingness to spend time or money for hire software quality was not was not so high, but I always had the feeling of there is some misconception about saving money with lower softer quality, that it is cheaper, lower, softer qualities cheaper. It can be for a couple of months. But yeah, I always felt that we are actually not that fast that we think we are, even though we are saving time on software quality. And my third job, I was working in a small team, it was quite similar. And that's also where this craving to focus more on quality again came from kind of the Curiosity how to be able to deliver a quality even though you have to deliver fast results. That's that's also why I got curious about TDD and programming because the idea is that you are actually not slower, even though you're doing programming or test driven development. That's also the idea why I had ideas to doing this programming tour to see And practice pair programming with other peers since he that you really can achieve quite a bit while practicing this different techniques, which leads to higher quality, what is so great about programming? in your own words? I think it's really the discussion. You know, when you're developing, you have like many ideas, and then you start trying out those ideas, which are the most promising, but every once in a while you'll get stuck, then you need to take a step back, rethink and try the next idea. And I think that having the whole time discussion, the fun appear that this is a lot faster, that you are much better in sorting out which idea is the most promising because certain suddenly you have two opinions. Maybe you your Already in the first place a white couple of paths because of the input from your colleague,
Tim Bourguignon 23:06
and what does it take to be a good peer or to be good at pair programming? I imagine
Harald Reingruber 23:11
that it's a lot about communication. I mean, first of all, you have to be really mindful of how you communicate and tell you like, such as different ideas or criticize and at the same time, when you present ideas, or start coding in one direction, you have to have a lot of self esteem that you are confident enough to try out something which might be a better the year or might be wrong. And so I think I definitely think that it's not, it's not the perfect way to program for everybody. But if you find the caring partner that works well, like I could imagine that it can be really pushing you and boost you and your development process. Did
Tim Bourguignon 24:05
you live through pairs that didn't work?
Harald Reingruber 24:07
Well, to be honest, I've never been successful establishing a pair programming workflow. In the companies I was working at who in my last company, we tried it a couple of times. But then deadlines and feature demand came in and we we also my, my colleagues, were not that interested to figure it out. And I wasn't able to convince them to experience to to experiment more. I've attended several code retreats, where I was able to program with with a couple of developers from Vienna, and which was really, really fun. And yeah, welcome. The first taste of pair programming, and I had sessions, which worked really well. And there were also sessions, which didn't work that well,
Tim Bourguignon 25:10
it always amazes me. pair programming is one of these tools that if done well could accelerate your development process. So fast really, or maybe the the development itself is not going to be much faster, but the quality is going to go through the roof. And so overall, your development process is going to be way faster, but as soon as deadlines start breathing down your neck, you go back to your demons and throw pepper roaming gdd down the drain and not use it, which is come to the silly. I've seen this so often. So what you described is is is absolutely normal. Unfortunately,
Harald Reingruber 25:55
yeah, that's true. But on the other hand, you shouldn't shouldn't stop the processes which you define that are good, just because of the deadlines because it can be risky that then in the end you you need even longer because you stopped all those processes and didn't write the unit tests and so on. And
Tim Bourguignon 26:19
this is I did say,
Harald Reingruber 26:21
I guess it's also kind of human Of course to get sloppy because you start to rush things, but I could also imagine that if you are doing pair programming, then there is always another person who could maybe prevent you from and tell you like, okay, let's take a step back or let's don't jump to too early conclusions and so on. So let's talk about this to our viewers. You call it a pair programming tour. If you go back to episodes five with amortized liar and Episode 11 Was Nico, how we talked about similar demo tours? I think we called them craftsmen tour or journeyman tour back then. But I think as humans the same idea. So coming from this apprenticeship idea where an apprentice was learning with a master, and then became a German, and from their own went into the world world to discover what other masters and Germans had to say about their field, and kind of understand how others are doing it, and then learn and grow along the way. Is this what you intend to do? Yeah, right. So the idea is quite the same. Actually. There are many terms. I think Cory Haynes was the first who called it cherny mentor. Also I heard coding tour but basic idea is to spend some time with another peer with another developer and learn from each other because everybody As a different background, everybody has different experience and valuable experience, positive, negative. And everybody learned from these experiences. And I think even even when you're already a very experienced developer, there is always something in here you can learn from somebody else. And this, this tour really allows me to see many different places. And also, I mean, I also want to offer value to the hosts who invited me. So I'm curious in when when the episode is going on here, it will be already it will be only a couple of days until it will restart and I think I will also improve a lot on the coaching side of being an experienced developer.
Tim Bourguignon 28:56
I'm sure you will share your work if I am I haven't done a tour like this, but how I picture it is, um, you know, when you start a job and the first week or two week on the job, you're just getting an avalanche of information and you think to learn, and I picture a tour being like this, but for for two months, which is going from one place to the other, and you're just, it's just non stop, you're getting you input. And that must be so exhausting. Yeah, but so amazing.
Harald Reingruber 29:29
Yeah, maybe it's a bit different because the goal is not to learn everything in order to get an overview of the whole project. So I imagine that we try to focus on very specific topics or tasks, it will be constantly different environments, different people will be interesting. I'm really, really looking forward to it. I also want to attend meetups or maybe give a talk mera Demeter, and it will be a tense schedule.
Tim Bourguignon 30:04
How do you think you are going to be able to provide value to a company with just a few days attendance with them? what's what's your plan in giving back
Harald Reingruber 30:16
something having somebody from outside of the company or is not doesn't have to typical company blindness is valuable to offer different perspectives. And also to set set some time aside and focus on specific tasks, which maybe you didn't before had time to. And then you have for like a good reason to, I don't know, I also thought a lot about how one could be productive from the first day and I think writing automated tests or refactoring legacy code. I think it's something where you can really quickly get productive and offer a good Second Opinion. Maybe some company or some developer invites me because he, he reads the list of skills or experience I have. And t thinks like, oh, wow, actually, I don't know that much about that. But a couple of years ago, we had the idea to do this graphics visualization in our app, but we didn't have anybody with the knowledge and maybe somebody thinks has the idea to invite me for a couple of days to work on the first prototype. So I could imagine a couple of different ways to provide value. Did you find all the companies for you to already know? No, not yet. So I have almost two companies. Two tourist stops confirmed. One is actually on the the official, HR approval is missing. But the team and the director is on board. So it looks really, really good. And there is another stop in San Francisco, which seems to be promising. Yeah, it's really it's not so easy. I spent a lot of time to send Twitter messages, direct messages to to developers and put a lot of effort into advertising metaphor. I think now my first couple of confirm twist ups helped get some some more invitations and maybe also if this podcasts episode, maybe there's somebody who thinks like, hey, that might be interesting. Harold sounds like experience interesting guy and continue timber King wish him for to freeness and to learn from him and exchange knowledge.
Tim Bourguignon 33:07
That would of course be amazing, but I hope that by the time this episode airs, you will have all the companies because this will air if we if we calculated that correctly. Just three days before you land in sin Diego you said
Harald Reingruber 33:23
Yeah, exactly. I will start from San Diego. Yeah, it could be that I'm booked out but a time but I I'm looking forward to just see how it turns out and I'm open to for spontaneous invitations.
Tim Bourguignon 33:39
So before we come to to your contact information and where people could be less spontaneous and and talk to you about this or be spontaneous and then in Kentucky, and what would be the the one advice you would give to people may be thinking to do such a German tour or a peppermint tour just to convince them to to jump in Jump into the cold water as the the Germans say, what would you the one the one argument you would add to the to the balance?
Harald Reingruber 34:06
Well, my number one advice is definitely reach out to people reach out to those who did similar things I receive so much support from from ami, Tasha from PETA cough from Nicola. And everybody already did this. They're really like, apparently had a great experience and they are willing to support others who want to do the same. And I wouldn't be surprised if after my tool it would turn out different for me. I'm quite sure. I'm also happy to offer help and support and yeah, maybe in five or 10 years, maybe doing a tournament or is it a slightly common thing to do? That will be cool. Yeah.
Tim Bourguignon 35:00
Once again, networking to the rescue. Ask people around Don't be shy.
Harald Reingruber 35:03
Yeah, exactly. And it's so easy nowadays. There are so many communities, you just have to find them. That's the only tricky part. But if I'm across borders, it's not that difficult to reach out. Get in touch with like minded people. Amen. Amen.
Tim Bourguignon 35:26
Okay, so where can people reach you and either continue this discussion or or invite you in their companies? Where would the be the the rights the appropriate place to do this?
Harald Reingruber 35:37
Yeah, the best thing is to look me up on Twitter. My Twitter handle is Harold fri dcv and they are you will also find my tweet promoting my tour and attached to the tweet is a link to the my blog article describing my tour. From there my direct message feature is open. So just contact me on Twitter or find me at one of the meetups in this the cities so far I've planned to go to San Diego, San Francisco, Portland and Vancouver. If you're somewhere nearby even miss you on the way maybe you never know in which direction I will adopt my tour. Maybe I will insert another stop somewhere on the way. Awesome. Anything else
Tim Bourguignon 36:30
you want to plug in? Yeah.
Harald Reingruber 36:32
I really would like to thank the army tie and Peter Koffler for the amount of support it gave me. I think even during my preparation, I learned so much. I found out about podcasts about flexspaces and people I'm following on Twitter and if somebody is thinking about doing such a tour, but isn't sure if f4 just wrote a fifth or if if having doubts to fail, don't worry if um, if you fail, you learn a lot. And it's really it's really create. It's really enlightening.
Tim Bourguignon 37:13
I'm sure it will be. I'm sure it will be. Okay. So by the time this podcast airs, you will be almost on your way. So I wish you farewell and a great journey. And I hope we will read a lot about about it on Twitter and what's happening to you, and all the things you learn. I will post regularly. Well, thank you very much. It's been a blast listening to your story.
Harald Reingruber 37:36
Thanks a lot for having me.
Tim Bourguignon 37:37
And this has been another episode of developer's journey. We will see each other next week, bye. All right, this is Tim from a different time and space with a few comments to make. First, get the most of these developer's journey by subscribing to the podcast with the app of your choice, and get the new episodes automagically, right when the air. The podcast is available on all major platforms. Then, visit our website to find the show notes with all the links mentioned by our guests, the advices they gave us, their book, references and so on. And while you're there, use the comments to continue the discussion with our guests or with me, or reach out on Twitter or LinkedIn. Then a big big THANK YOU to the generous Patreon donors that help me pay the hosting bills. If you have a few coins to spare, please consider a small monthly donation. Every pledge, however small counts. Finally, please do someone a favor, tell them about the show today and help them on their journey.