#56 Magnus Stahre is not supposed to know it all, and neither are we!
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Tim Bourguignon 0:07
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 Magna Carta, Forge of Iren and walrus blood. Magnus come from an entered line of Nordic code Smith is Technology Engineering heritage was primarily responsible for preventing the narwhal invasion of Sweden, in bowls 1683 and 1950. As a craftsman of such pedigree, Magnus knows from generation of experience meticulously handcrafted code, what is needed to produce exquisite results, even when using some of the worst raw material out there. After Magnus succeeded in crossing the great sea and reaching new world, he settled in the kingdom of pillar technologies. And since this time, he has been solving ever more difficult code smithing problems while teaching the upcoming generation that weighs off the mighty Nordic code Smith. Mere Mortals must often ever that gaze from his profound use of Unix to avoid being paralyzed in all, Magnus. Welcome to deaf journey. Thank you very much. This is the most creative bio I have ever hired to hear. This is so great.
Magnus Stahre 1:38
Yeah, I have to give a shout out to my friend Nathan doats to help me help me write that thing is Yeah, I'm I'm not particularly well with prose myself. I'm more into writing code. So that's largely his doing from me, I needed some sort of description for a talk I was giving. So thank you. Thank you, Nate.
Tim Bourguignon 1:59
Yep. Thank you, Nate. That was awesome. So let's continue on this on this metaphor. With such a family heritage. Did you ever question becoming a code Smith in the first place? Um,
Magnus Stahre 2:16
not not really, I guess. So. I guess a little bit about my background. I'm, I'm from Sweden. Born in the late 70s. My dad was working as some sort of operator at a insurance company. So when I went to visit him, he was sitting behind these weird terminals and inputting stuff. And I was quite fascinating what was going on. And around the same time era, you had movies like wargames. So that opened up a fascination with with technology lives on today.
Tim Bourguignon 2:56
So did you have a chance to tinker with it right away?
Magnus Stahre 2:59
I didn't really Tinker a whole lot with it right right away trying to remember exactly how old I was, but it would have been in the mid Adas. I was sent to this I won't say it was a basic course the programming language and it was running on Commodore 64 so I was learning basic knows for those who know the domain there's a lot of peeking and poking in Commodore 64 basic to to play with the background colors and such. I didn't really do a whole lot on that front. Other than basic, so obviously With 64 you can do assembly and such but I never got into that i i would touch on assembly later on, but not for the Commodore fast forward some years. So I was I think I was seeing my dad he there I saw this sort of box at some some shelf and it's a turbo Pascal for Windows. I got curious what is this? So I ended up playing with turbo Pascal for Windows, this would be in the turn of between like late 80s, early 90s there abouts. I would take take Pascal programs go over the example or the sample application that comes with it, I would tinker with the code changes see what it does. So effectively This was doing over Opie object oriented programming before I actually understood what what that kind of code was doing so by by reading the code and copying code I was doing Oh without knowing that what it was really in hindsight, but I did anything useful in at least was
Tim Bourguignon 4:49
object oriented Pascal, do you remember what was attracting you in playing with it?
Magnus Stahre 4:56
Probably some sort of curiosity really. I guess I had a sense of trying To create something that was my own that and I remember, around this time I was also pre, pre the mainstream of the internet, there was no webpages to go to, there's no Google, no Wikipedia and so on in order to find information back then either go to a library and check out books. But there was also the wonders of the BBs systems, the bulletin board systems where you would use a modem to to connect, I still remember we had a modem with 24 bps, that would rather 2400 VPS. And it was one of those moments, I think most of them kind of worked my way. But it would, you would hear the the dial tone, and it would use the handshake. And then it would, it would shut off right after it finished that the handshake. So I still have lots of lots of memories of those, those those be modem handshakes.
Turbo Pascal, Around this time, so it would have been 9293, there abouts was the release of Windows 3.1. And one of the the big big additions in 3.1 was the ability to do drag and drop, we could drag files from one application onto another. So I wanted to leverage this. But because of Pascal for Windows being targeting 3.0, you couldn't leverage the these new features, what happened was that I found the BBs of Borland and they had some sort of upgrade, you could apply to thermal scale for Windows such that you'd get at least most of the the features for 3.1 into turbo Pascal, it would be kind of like a bar on the side of the screen, kind of like the dock, I guess I would I was able to drag files from the File Manager into that, and he would like dynamically increase the size and it would effectively be become a very rudimentary application launcher. fond memories, so getting that thing to work. One of the things developers have, Lisa, that their windows programming was you'd have these handles, and you only have so many handles. And if you don't close your handles you you run out of handles. So it's kind of like a memory leak of sorts. So this particular application, I remember had a lot of a lot of those issues, they would run for a while. But when you add started adding more and more things to it, it would stop functioning really. So it's one of those things that I kind of wish that I still have the code for, like, go back now and see what what I did wrong.
Tim Bourguignon 7:54
This was all programming for fun at that time, right?
Magnus Stahre 7:58
For fun, or for practical purposes. I didn't get paid for for doing any, any programming at that point. Now,
Tim Bourguignon 8:05
when did you realize that this could be something you could do for a living?
Magnus Stahre 8:09
It's a good question. So you know, my teen years, I had become rather tired of school, which is probably a common thing among among teens, but in my particular case, I had the opportunity to I was able to get a job at a local ISP service provider for free internet that I was able to get a job there originally, I was going to just take a few months off and then go back to school. But as it turned out, I I kind of liked working and getting paid. So that around that time I was not doing a whole lot of programming. I was hired more to be like a sysadmin to maintain their the Unix systems. So I did that for roughly three years. And then I started working at a different kind of service provider was more of a telephony talk telco company. Initially, I was also more of a sysadmin kind of tasks. As that progressed. That's where I started getting more more deep into into programming. I was doing more more elaborate programming to solve solve problems in the like. That's where I started using Java. Up to that point, primarily after after the turbo Pascal for Windows days, I had dabbled a little bit with some till assembly as well as C and then as any sysadmin knows you need to do a lot of scripts. So I think I'm primarily use either like shell scripts, a big part of it, but to some extent it's also Perl Perl. I've later come to realize this kind of the most the most Well known write only language.
Magnus Stahre 10:05
Do you care to expand on that?
Magnus Stahre 10:08
Sure. Well, now very popular say that, but it's one of those languages that it's hard to kind of come back to later and intuitively understand what what something does. I don't know what it is. But it's something about all those dollars that kind of makes it hard to read. That's probably why I don't still don't have a particularly good time with PHP either. So yeah, that's where things started getting more in depth with Java. Java is probably the the language today that I've done the most amount of work with this probably certainly well, but I don't think I wouldn't say that that's my favorite language probably was at some point, what is your favorite language kind of comes and goes, but I find myself like, like in Python a lot. It's a combination really, of the the language itself, probably everyone is done with some sort of Python has to come to terms with the significance of whitespace. But beyond that, it's I think it reads rather rather well. And as, especially as a good, good amount of libraries, it's relatively easy to install libraries and such have them available with just like virtual env and, or pi engines, and so on, it's easy to have multiple versions of Python installed. So you can kind of quickly test different versions, different diff different libraries, and see what works for your particular problem on hand has In addition, you have Jupiter gives you a web web based notebook format. With that in mind, I think Python is probably my favorite these days. Do you script languages a lot. That's kind of the the nature of what I'm doing you, like you mentioned in the intro work for pillar technology, software consultancy. And as such, we are working in a lot of different languages. Because of that you you find yourself in different contexts and different languages. So I've seen a door through my ears there have been exposed to quite a quite a few of languages, including some that you don't see all too often, I guess. So we add a insurance company, for instance, we were developing an RPG. And so it's all the IBM mainframe. And they even have something called RPG in it. So you can write unit tests for RPG, we try to incorporate those those fun who
Tim Bourguignon 12:37
unit tests for the mainframe? Don't see that too often. That's true.
Magnus Stahre 12:41
Exactly. So we try to take more modern approaches and bring it bring it back to the mainframe. And also back in was a 2012 developing a augmented reality based iOS application. That was using objective c++, which, as I like to face it, it kind of takes the worst of both worlds and makes a
very interesting language.
Tim Bourguignon 13:09
How come
Magnus Stahre 13:10
while it's he kind of don't really know if this is this Objective C or c++, what is going on here, because what what, why they were doing that is it was a cross platform framework. It was written in c++, and then they had an Android Android layer on top of it. And there's also an iOS layer on top of it. And in order for Objective C to access c++ code, you need to have this intermediate or this objective c++ by doing that you can do do the c++ features, like you can use templates and collections and all that, but it's very confusing the kind of mixing, mixing the Objective C like the nsra as well with the c++ lists. So those are vectors I guess they were they were Yeah, so that was interesting and so that that one has the extensions mmm typically with c++ it would be either cc or CPP or capital C. But with objective c++ it's m m
Tim Bourguignon 14:19
What does it
Magnus Stahre 14:19
stand for? I don't know what why you have the M regular Objective C is just just m but I guess to mirror the the c++ lang cc they object to c++ became it's probably some very good reason for being m but I don't know what that reason is.
Tim Bourguignon 14:38
We'll leave it for the aliens to write well let them know. I wanted to ask you a question about craftsmanship or craft tourists ship. I've seen I've seen in most of you or in different Bibles of yours. That your your current title changed a bit from from a dial crafter to To a Java developer to software crafter? And how do you define your current job?
Magnus Stahre 15:06
That's a good question. It's one I try not to be put too much into a title. But yeah, to describe what I'm doing, that's what I describe as probably solve hard problems, or I tried to solve hard problems using whatever, whatever tools are available and packaged on a solution that our customers can can leverage. And
Tim Bourguignon 15:28
where does the the craftsmanship that comes from,
Magnus Stahre 15:32
I guess, that kind of stems from the progression that you have from the printers to tournament to craftsman. So that's probably where it's coming from. It's one of those titles that we're kind of given at the time. That you kind of teared by, by those who had the apprentices. You had journeyman and craftsman.
Tim Bourguignon 15:54
And did he? Did you live through those stages as well,
Magnus Stahre 15:58
I don't think I did in a, in a well defined manner. Really, it's more more of those kind of grew on me. So I didn't deliberately progress in that regard, it's probably something I would hindsight would have been, would have been helpful to have done, I wish past past version of me would have would have done or probably would have helped make the progression a bit smoother, but it is what it is, um, I would say I'm a pretty good spot ended up pretty good as in the end, as they say,
Tim Bourguignon 16:29
I think you do as well. But but so I would like to keep to keep just digging a little bit in there. Going back in time, how would you would you picture this this progression going that you didn't get? What What do you think would have been helpful for one, I
Magnus Stahre 16:46
think it would have been helpful to kind of know that there is such a such a progression, so to speak. There's ways to rather that you're not kind of expected to know everything in front. And you can reach a new level, you don't need to know everything, want one way, put that into perspective. The back back in the late 90s, I got a copy of the reference book for c++ by by vrna, my Danish is probably not the best, but something is something like that the creator of c++, and I tried to read that book, it would have been the third edition of it, I believe, I got it sometime in 1998. Give or take. I tried to get into it. But there was something about that book at that point in time, I could just not get in. But there, there was so many terms and concepts that didn't make any sense to me at the time. So I did not get very far into the book. And then fast forward to I want to say it was fall of 2010 probably. So we were a client at the time, or that we were about to start doing business with had a major c++ plus project, we didn't have a whole lot of c++ skills at the time. So we were trying to trying to bring that up to speed. Again, I got the same the same book. And this would have been a difference of some some 1212 years give or take of experience that I've picked up over those years. And there something about that collective brains just made that book, very easy to read. And so that's what prompted me to think back of my previous attempts. And that's one way I could see that I've grown quite a bit as the youth was wet, chequered. read that book. That's a very concrete example of progress made
Tim Bourguignon 19:01
did this happen to you with another book or with another resource? reading it again, or reading it a few years and discovering a completely different level in the material.
Magnus Stahre 19:13
I can't think of another example. That's the the most clear cut
Tim Bourguignon 19:18
on I can think of it's happened to me with with a book rework from from Devin Pena Manson and Jayson freed. I remember reading it right after it came out. And and then I did a few years of corporate corporate work and reading it again. Those chapters took very different meeting. Right, it was really, really interesting to see it.
Magnus Stahre 19:41
Yeah, there's something to be said about books when you when you reread them a year have picked up a lot more context. So it's kind of like a brand new book in a lot of ways, or at least it connects to two parts, parts of your mind that connections that you hadn't had the previous attempt, so That's, you shouldn't be shy to reread books.
Tim Bourguignon 20:04
Is there a book you wish you were on top of your mind that you say I should read that again.
Magnus Stahre 20:09
So there's a really good reference book about unit testing called, The name escapes me, of course, but I will have notes in the show notes. It's x unit, something excellent. And it's a really good, really good book. And that was one of the many good things about that book is that it gave very good explanations of the various kind of test doubles. That's one thing when you start getting into mocking libraries, and such as terminology gets very loose. And so this, this book really define in a good way, what do you think you should read it? Again? It has been quite a few years. I think, given the what I've done the last last few years probably probably would be helpful. Because when I was reading it, I was primarily working with Java. I have not done a whole lot of Java let last last few years. So I think though, the be helpful to see in some in other contexts,
Tim Bourguignon 21:12
that makes sense. I would like to ask you a tricky question. I'm sure I've heard about you a few times before, once, via ami tie saya who was the first guest on this podcast. And once the anchor Helen, when n talked about you, she said something like Magnus has has this this special thing when he's on your team? Everything becomes possible. What do you have to say about this?
Magnus Stahre 21:40
I don't know what kind of those things are. So it's hard for me to relate to it. Because I'm, I haven't really been on the receiving end of myself.
Tim Bourguignon 21:52
What is it to to work with you?
Magnus Stahre 21:54
Um, I hope the people who work with me have the impression that I I like to get something done in a way that is maintainable and as clean as possible. Yet also one that might not be I also know when when to break rules, if you will, when that's one of the things. Rules are are good, typically good guiding principle. But there's some times when you in order to achieve something, you might might need to bend bend rule slightly released. Think outside the box a little bit.
Tim Bourguignon 22:39
Do you have a lot of apprentices around you?
Magnus Stahre 22:42
So, pillar we have over the year? So we've had various, various programs where we have had apprentices. Right now we just started a new cohort with I want to say that there's six of them. So to answer your question, yes. Well, we have we have apprentices,
Tim Bourguignon 23:04
how do you deal with this fine line between giving advices showing rules? Bringing bringing knowledge to people, and also breaking the rules and showing them that they shouldn't follow the rules blindly and requesting things?
Magnus Stahre 23:23
That's a good, good question. I think what will you probably need to do is be upfront about, about the rules, why, why they're there. And to kind of explain the purpose of the rules. So they're more more to in the beginning, they're to steer you straight, kind of like a training wheel situation, than one share, you can go about things without without the trainers, training wheels, you should take them off. But the important part is to get get them to understand that or at least they should know what when to question the rules, such that if a rule is in place just for for its own sake, yeah. Why is it there? It's more of a lease, a lot of them are to get get started initially, and knowing kind of a path forward. But then once you once you know how to operate, you need to know you don't know what the rules are and when to when you can break them.
Tim Bourguignon 24:34
Yeah, it's I struggle with this personally, was this kind of do what I say know what I do at the beginning, showing people or telling people what to do and doing behaving differently. Because Because I've I know the rules now and I know when to bend them. And it's really I find it really hard personally to to navigate this lane.
Magnus Stahre 24:56
Yeah. It's one of the things you kind of know It's hard to explain what it is. But you know, when you see it kind of
Tim Bourguignon 25:03
Yes, yeah, let's say, when when you you hire? I'm not sure if you're wearing, you know, involved in the hiring process for those apprentices. But if you were to to be involved in this hiring process, what kind of mindset would you be looking for? To to ensure the successes, the success of those of those people?
Magnus Stahre 25:24
Right? I think one thing that's important to have is kind of a hunger for to learn. So that's probably my the best quality I would put in an apprentice,
Tim Bourguignon 25:37
how would you go about and discover this in an interview process?
Magnus Stahre 25:40
So what we do is, we have a series of steps. One step is to have a pairing interview, during which you spend roughly two hours give or take with a with a candidate. And during that time, the idea is to get an impression of how they're approaching things, what they're doing in certain situations, and you will need need to gauge if this person is has the the right, right mindset
Tim Bourguignon 26:16
Do you work on on production code in those two hours,
Magnus Stahre 26:19
there's not production code, per se, we do have this set of caught us that we that have the more calm where we have a set of acceptance criteria. So we have them write code that could be used in production if, if you're, you happen to be in, in the market for any of these caught us. So that we're, we're still doing code in the way that we would have if it had been a real project. So we we do test driven development, we see that Tesco red and then green and refactor and repeat. That's the usual usual approach.
Tim Bourguignon 27:04
Do you cat as a lot besides doing them in interviews,
Magnus Stahre 27:09
so that's the primary the primary use case I use them for. There is also you can also use them to, to keep keep your skills sharp in a particular area. I know a former colleague of mine, named Jim James hood, he was big into doing caught us as a, as a daily daily exercise, basically. So he, at the same publishing company, we would have these daily, daily meetings at a for about 10 minutes, during which we would have a conference room with people and we would all be solving the same, the same problem all over again, it will typically be the the prime factor. By doing that the same same kind of approach each day, you would get very comfortable with your tools, and perfect keyboard shortcuts and the like. So I definitely see a good is a good use case for it in in addition to using them for selecting
Tim Bourguignon 28:26
candidates, do you have a favorite kiddo? I do
Magnus Stahre 28:29
kind of like the prime factor one, it's a, it's short, you can get it done in about 10 minutes, regardless of what language you're doing. Usually, sometimes, if you're new to language, you need to kind of figure out how you do modulus. Or if you're very if you maybe not new to the language, but new to testing and you need to kind of get the testing framework on the way But yeah, I think that is probably a good a good small size kata, the prime factor. So I also have a special special relationship with the game of life kata. I'm not sure if it qualifies a kata or not, but it's so if you are familiar with the code retreats, movement,
Tim Bourguignon 29:20
um I am but maybe not all the the listeners can you can you introduce it visually. So the
Magnus Stahre 29:28
short story, the long story short there is that coda trait is the idea of Kota trade in its original form, at least is to take one day that is not a working day. So typically be on a Saturday, you would get together with a group of people, you would take a particular problem and you would find various different solutions to it. So the the very first, the inaugural one was in an arbor in 2009. As it happened, I was there with a, some 3030 odd people. And we we did Conway's Game of Life. And for each iteration, it would be some, some sort of variation to the previous ones. Typically, you'd end up swapping pairs, you would, you would reimplemented with what someone else is also common that you do it in a completely different language throughout the day. So you find yourself doing the same problem. But in four or five different languages, you have to know
Tim Bourguignon 30:45
a couple code retreats myself and hosted some is really amazing to, to tackle this problem that is basically not really possible to solve in the 45 minutes that the times you have. And then forget about solving it and and just focus on solving or creating a neatly crafted part of the solution, which is always always fun and adding some constraints on top of it. I really love the no talking rule, when you hear
Magnus Stahre 31:19
a lot of times you'll see people do do the same kind of talking Bible in comments or writing stuff on paper. But yeah, it's absolutely, again, having those constraints. Absolutely. Helps you think outside the box?
Tim Bourguignon 31:35
Yes, it does. Yes, it does. Um, where would you suggest the listeners to to go and continue this? learning about cutters? Where do you have a special website or book you could recommend?
Magnus Stahre 31:52
I do have a repository, I will put that I of course, don't remember exactly where it is. But I'll give you the link. So you can have that in the show notes. It has a bunch of various caught us. If you want to learn more about code or trade, it's coded trade. org,
Tim Bourguignon 32:10
of course, and the thing the global day, somewhere in in the end of the year, is it November?
Magnus Stahre 32:17
Typically, it's in the past, I think it's been the first week of December, something like that. Yeah. Yeah. So global, they are predatory. It's absolutely a an event to, to look out to watch for and find find it in your city. If it's not organized in your city, you can organize yourself. So for the for the listeners, it's a one day, special day where
Tim Bourguignon 32:41
there's some some code retreats everywhere around the world. And I think Corey Haines, organize it the first time, flew to Hawaii or flew to one Pacific Island to start the very first one and then flew on the west coast to do the last one or something like this. I think that is
Magnus Stahre 32:58
it did fly either from or to Hawaii, I would guess that it would be from Hawaii to the west coast of the United States. That seems reasonable. So it kind of maximize the timezone difference there. Yeah,
Tim Bourguignon 33:11
some something I get it. So it's always fun. And there's some some possibilities to do some, some live streaming between sites and, and sync up with, with different companies in the same area doing the same same exercises and, and share experiences. So it's really, really something to to to look for. I would highly recommend it as well.
Magnus Stahre 33:32
Fun. Have fun around for sure.
Tim Bourguignon 33:34
I'm Magnus, the time box is running away. I think we should wrap up.
Magnus Stahre 33:39
Sounds good to me, um,
Tim Bourguignon 33:40
where where can people continue this discussion with you and bug you with more questions for
Magnus Stahre 33:46
probably the easiest way to get ahold of me, it's on Twitter. On Twitter, it's my name, there's mindestalter as I know, will be a link in the show notes as well I figure if you're, if you're not fluent in Swedish, it might be hard to spell my name, but the link should give should get you straight there. I
Tim Bourguignon 34:09
will add it to the sermons. Um, do you have some some talks coming up or something you want to blame? Ah, I
Magnus Stahre 34:15
think I've done my share of talks so that for the year, but I do have a couple of recordings of it. So if you're interested in learning more about git, and how to kind of get yourself out of the hole. So you have a dog. I I have a recording of that talk there can have your link to as well. Thank
Tim Bourguignon 34:38
you very much. It's been a blast. Thank you. It's been a fun, and this has been another episode of developer's journey, and we'll see each other next week. 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 do fantastic journeys. Thank you