Ran Levy, a well known and prolific technology podcaster joins the show to talk with the panel about software bugs. Topics of discussion include the inevitability of software bugs – are they an intrinsic part of software development? Also, can they be minimized and their impact mitigated? And what can software companies, and the developers themselves, do in order to deliver properly working software.

Sponsors

Panel

Special Guest

Links

Picks

Dan

AJ

Charles Max Wood

Follow JavaScript Jabber on Twitter: @JSJabber

Special Guest: Ran Levi.

Sponsored By:

CHARLES MAX_WOOD: Hey everybody and welcome to another episode of JavaScript Jabber. This week on our panel we have AJ O'Neill.

AJ_O’NEAL: Yo, yo, yo, coming at you live from Pleasant Grove. 

CHARLES MAX_WOOD: Dan Shapir. 

DAN_SHAPPIR: Hey, hey, from Tel Aviv, where it's really hot. 

CHARLES MAX_WOOD: Amy Knight. 

AIMEE_KNIGHT: Hey, hey, from Nashville. 

CHARLES MAX_WOOD: Steve Edwards. 

STEVE_EDWARDS: Hello, from Portland. 

CHARLES MAX_WOOD: I'm Charles Maxwood from DevChat.TV, and this week we have a special guest, and that's Ron Levy. Did I get somewhat close on your name? 

RAN_LEVI: Very, very close. Hi, hello to everybody. From Tel Aviv, not far from Dan. 

CHARLES MAX_WOOD: Yeah, and you're famous, right?

RAN_LEVI: I would say, you know, in the Israeli podcasting community, perhaps being the dinosaur of the neighborhood, an old and old geek. But thank you. Yeah, I've been in podcasting for like, I don't know, 13 years by now.

 

Leveling up is important. I spend at least an hour every day learning ways I can improve my business or take a break and listen to a good book. If you're looking to level up, I recommend you start out with the 12 week year as a system to plan out where you wanna end up and how to get the results you want. You can get it free by going to audibletrial.com slash code. That's audibletrial.com slash code. 

 

CHARLES MAX_WOOD: I was talking to somebody from Wix the other day and they mentioned that you were coming on the show and they were like, they were excited to hear you come talk to us. And they weren't even the tech people over there. So anyway, do you want to introduce yourself so that everybody else knows why you're famous? Or maybe Dan should do it. 

DAN_SHAPPIR: Well, I don't know enough about Ron. I can only say that I listened to quite a number of his podcasts. And the interesting thing, by the way, is that even though he describes himself as a not specifically about technology. Like there's an excellent history podcast and everybody knows I'm a big history buff. And there's like a new one about news, I think. And it's really an eclectic but excellent collection of podcasts. And obviously, there are the technical podcasts which I really dig because I'm a techie as well. 

RAN_LEVI: Thank you.I started actually as an engineer. I was an electronics engineer for like, I think 20 years or 15 years of my life. Transitioned to software development after a time. And in parallel, I started a podcast. It's called Making History in Hebrew. And it kind of got popular in Israel. So I reluctantly left my day job to start a podcast network, which then mentioned there's lots of podcasts with you know, very eclectic topics. And in the last, in the past four years, I've been podcasting in English as well for American and international audiences. And my latest podcast is the Wix Engineering podcast about developer culture in the world of software. 

CHARLES MAX_WOOD: Very cool. 

RAN_LEVI: Thanks. 

CHARLES MAX_WOOD: So we're gonna be talking about bugs. 

RAN_LEVI: Yeah, favorite topic of every developer to talk about.

CHARLES MAX_WOOD: Yeah. Now, one thing that I thought was interesting is you actually entitled this podcast episode. We're going to kind of be talking through as our software bugs inevitable. And I'm curious, how does everybody feel our software bugs inevitable? 

AIMEE_KNIGHT: Oh man, I have so many strong feelings about this. 

AJ_O’NEAL: I don't know how it seems like a just a placid yes. 

AIMEE_KNIGHT: Like I feel like yes, but at the same time, so many people use that as an excuse to like, not be more cognizant when you're developing like, or shipping really like, oh, nothing gets me more worked up than people like, oh, just ship it. Like, no, like your customers are paying for code that works. 

AJ_O’NEAL: No, no, no, they're actually paying for whatever you deploy. Whatever the minimum bar is, that's what they're paying for. They're not yelling at you on Twitter. They're happy.

DAN_SHAPPIR: I had a friend who worked at a certain company, I'm not going to name any names, but after several years of deploying to productions to actual customers, they were still using a debug build because they could never get production build to actually work. 

AIMEE_KNIGHT: My feelings come from working at a company where whether it was true or not, there was a joke made in all hands that we might not make payroll because customers stopped paying their bills because there were so many bugs. And that just, no. 

AJ_O’NEAL: Was it in PM? It was in PM, wasn't it? 

AIMEE_KNIGHT: No, it wasn't. It wasn't. 

RAN_LEVI: Actually, I mean, that sentiment that bugs are kind of inevitable in software is something that I encounter a lot. Being a developer myself and talking to many, many developers, it seems as if it's inevitable in software. But I try to think a bit of it in a more like meta-level. And I asked myself when I approached that topic, I mean, why is that? Because in other fields of engineering, making mistakes, although making mistakes is human, so many mistakes and so many, I mean, the statistics says that the chances of getting a software project on time, in budget and without, you know, and kind of conforming to what the specifications of the customer, when we're talking about big software projects, not trivial ones. We're talking about specifications. 

DAN_SHAPPIR: Ha ha ha. 

RAN_LEVI: Exactly. Chances are extremely low relative to other fields of engineering. We're talking about 25% of failure in projects that go over 18 months, for example. And when it comes to projects that are larger, I mean, we're talking about years and many tens or hundreds of developers, the chances of complete failure is almost 50%. And in 10% of the cases, the software is never used at all. That's the statistic that I found when I researched the topic, which is an amazing statistic. 

DAN_SHAPPIR: Yeah, but can you define? Can you define failure in this context? Because just saying that something like failure means nobody uses it. Does it mean it's like nobody? What does failure actually mean? 

RAN_LEVI: Great question. And I mean, after a lot of thought, I came to the conclusion that when we're talking about success, we should probably be approaching it from the perspective of the client who ordered the software. And that means that the project should, I mean, of course, be relatively bug-free. There'll always be minor bugs, but not it shouldn't be any major bugs. It should be on time or relatively on time and it should not be over budget in an overly expensive way. If you're building a building or a bridge or you're trying any other creation in the engineering world, that's the general assumption that what success is and it doesn't it almost never works in the world of software when we come, when we're coming to huge software projects. And that's a problem actually that's been bothering, you know, researchers and people in the field, academia, and in the industry for many years. The first, the first major conference on software development back in the 1960s, I think it was, already defined that as the software crisis back in the 60s. And it hasn't improved a bit from the sixties. Remember what kind of software we, we, people wrote in the sixties. We're talking about what punched cards probably. And so much developed more developed now. And it's still almost impossible to get a huge software project on time, on budget and within constraints. It's a big problem. 

CHARLES MAX_WOOD: Yeah. 

DAN_SHAPPIR: But I want to push back a little bit on that because it would seem based on what you said that all because all software is such a mess, then by necessity all software companies should be like in a bind, like have really huge issues and be totally unsuccessful. Yet, if we look at the most successful companies in the world today, you know, you can argue about Apple, but all the other ones are like software or software driven companies, you know. Google and Facebook and effectively Amazon. And I think Apple now makes as much money from software, I think as from hardware. So, so if software is so bad, if nobody can successfully deliver software, how is it that the biggest companies in the world are software companies? 

CHARLES MAX_WOOD: So here's, here's, here's one thing that I have as a theory here is that, and I was trying to break in earlier to say it, but I didn't want to interrupt anybody, but now I do. And that is that. A, software is much more malleable than a lot of the physical products, which basically make up the other engineering disciplines, right? You know, I mean, even electrical or electronic engineering, you know, if it's not built right physically, it just won't work. Whereas with software, we've kind of got this infinitely malleable set of things, you know, we can go in and we can change it anywhere at any time. And with most of the other physical stuff, you can at least do a physical inspection and say, that's falling down or this thing is not connected to this thing in the right way or things like that. And in software, it's sometimes easy to overlook that. The other thing though is that with bugs being inevitable, and I do believe that minor and sometimes major bugs are just, you do the best you can and some of that stuff is going to seep through, the difference between the Facebooks and Googles and stuff like dancing really comes down to that they know that they're going to have bugs, and they have a robust system for dealing with them when they occur. And that's why they are successful in the way that they are. And so, you know, they kind of take advantage of it being infinitely malleable and they find sometimes elegant solutions to it. But they have a plan for this happened. We didn't expect it to. Here's how we rally and here's how we take care of it. 

RAN_LEVI: I'm sure that's at least part of the explanation. Perhaps another explanation is that software is very valuable. So even if you don't get it a hundred percent right, you can still probably earn enough

money for making it because it does bring huge value to clients, even if it's not perfectly right. I mean, if a building collapses, it's a tragedy because then people die and you probably go out of business. But if a software... 

CHARLES MAX_WOOD: And nobody can use it anymore. Right? 

RAN_LEVI: But software crash, I mean, the windows blue screen of death. We've seen it. Everybody's seen it. It's a building, it's equivalent, at least to me in the sense of what we're talking about, to a building that has crashed, to a building that has collapsed. Except that when it comes to software, we can always reboot, and unless it's a satellite in space or an aircraft in flight, it's usually not a big deal. But it's still there. 

CHARLES MAX_WOOD: I wanna reboot a building. 

RAN_LEVI: Yeah.

DAN_SHAPPIR: There was actually is an interesting story about the building that was rebooted they had this building I forget where it was that they had constant like system problems in the building like electricity would malfunction and the air conditioning and whatnot. So at one point they just took everybody out of the building shut down completely all the electrical supply to that building and then waited for like a couple of minutes turned it back on and it and it was functioning properly after that. So they effectively rebooted the building. 

CHARLES MAX_WOOD: Wow. 

AIMEE_KNIGHT: Here's like another like very strong thought that I have if I can break in. So we've kind of, I feel like talked about this before, but as somebody who came into software engineering from a different field, a very unpopular opinion, I think among some of people I've worked with before is that software developers, by and large, we are really spoiled. Really, really, really spoiled. And I think, I think we lose focus a lot of the times that like developing for fun and developing for your employer are very different. I think, especially in the JavaScript community, we tend to like get really opinionated about our tools and just, I don't know, like in other industries. I feel like, you know, the customer decides like you don't get to necessarily, I guess you get to pick your tools to an extent, but sometimes the customer has to decide. And I don't know, I don't know if that's like also, you know, part of the fact is that a lot of times like it's these startups and the founders don't really understand code. So the developers can kind of like wiggle their way around things, but yeah, like just, I don't know. It boggles my mind that it's acceptable to spend tons and tons of cycles, like playing around with different, you know, libraries and frameworks, but you know, it, it's acceptable to ship code that's not tested. Like it just blows my mind that it's okay to do that. 

RAN_LEVI: The past years, past 10 years or 20 years, I think there's big realization that codes needs to be tested. I mean, test developing development is, is really got a good hold, I think in the industry, but I can, I'm connecting to what she said there, because when we're talking about the root causes of why there are, why software is so hard to get right. I quote here the, I think one of the luminaries in the field, his name is Fred Brooks. I maybe some of the listeners already heard the name because he wrote exactly the very famous book, the mythical man month. And in it, he tries to kind of analyze why software is so hard to get right. And his conclusion is that software is so hard because it's basically a reflection of the human thought process. And when you're dealing with human thought processes, what happens is that each developer is kind of unique and he equates it, I think it was with mechanisms of tiny, of small handheld clocks. If you get, if you give the clock to a clockmaker and he opens it. He expects to find the same kind of mechanisms in, in, in the same models of clocks, because it's the same, basically the same mechanism over and over again. But when it comes to software engineering, software is never the same. You'll give the same problem to two different developers. They'll probably write two very different kinds of codes. And I think that ties into what you said about why do, why are developers so picky about their tools and why they are so opinionated because they connect in their minds with different tools that fit their thought processes. Some like declarative languages, other imperative languages. It's very, very tied to your way of thinking. And that's what makes software so hard. And it's also hard because it's very... In other engineering fields. It's often possible to kind of mask the complexity of, of designing. I mean, in, in architecture, for example, you can have schematics. It's, it's, it's very hard to create a schematic in software because as you probably all familiar with yourself, some processes in software are reflected in the time domain, other in the spatial domain, and there's very hard to create one schematic that captures every aspect of the complexity of software. So that's something that I think Brooks here really, he has a great point. And his answer to the complexity is not a specific methodology of design. You know, it could be agile, waterfall. No, he says two things. First, try to buy software instead of creating it because buying is always the safer option. And the second one is more oriented towards the culture of the company, the software company. He says that some humans are inherently better at creating good software than others, we call them, I don't know, rockstar developers or just very proficient developers and the company should encourage them, keep them, nurture them, allow them to develop because these are the people who can make good software because their brains are more capable to it. 

AJ_O’NEAL: You were you were treading on some thin ice there, buddy. People on Twitter people on Twitter do not want to hear that. I mean, you're talking about two things that are not really popular right now. One, you're talking about like people being born with gifts that are different from other people that make it unlikely for some people to attain that same level as others. And two 

RAN_LEVI: but I think it's very interesting to hear your opinion. 

DAN_SHAPPIR: I think it's kind of obvious. I mean, look at it from the sports perspective. I mean, no matter how much I practice and how hard I try, I will never be as good as Lebron James. I will never be good enough to play in the NBA. And it just means that I'm not as good as some people are at playing basketball. It doesn't say anything about my worth as a human being. I think people conflate the proficiency of people in certain fields with the worth or value of that person as an individual. And those are definitely two very different things. So I do definitely think that there are some people who are just more proficient at creating software than others. It's, you know, based on my experience, I've met some amazing developers who could do stuff that nobody else could do. Now, it's not just about being able to envision systems. And by the way, the interesting thing here is that there are various developers that are gifted in different ways. So some developers are really good at banging out, working, bug, or I won't say bug free, but you know, mostly bug-free code very, very quickly and rapidly. Others are very good at being able to like design the over the overarching structure of systems. Others are better at communicating their ideas throughout their organization. So like people can be like contributing to the organization in different ways. In fact, it's usually preferable to have different people able to contribute in in different ways. But again, just because you're not as good as a developer as somebody else does not make you like worth less as a human and also may not actually mean that you're worthless to their organization because maybe you can contribute in other ways. So that's, that's my take on it. Thank you. 

AJ_O’NEAL: Go on Amy. 

AIMEE_KNIGHT: Well, I would say it depends on the company and there is, there's like Dan said room for everybody, but like some companies you have to move fast. And there's room for error and there's room to ship more bugs. Some companies, like if you ship bugs, the stakes are really high. So you need to hire based on your company. And some people need to hire very meticulous engineers that might go a little bit more slow and steady. And some places need to hire people that can just go really fast and aren't as meticulous. 

RAN_LEVI: I think that's the exact reason why I place so much emphasis on culture and the importance of culture in software companies, the reason why I host the Wix engineering podcast about developer culture, because it's easy for us as engineers, as developers to focus on better tools, on better, you know, methodologies of development, standardization, et cetera, which are all important aspects of the field. No doubt. But many people don't understand. I think the importance of the culture of a company to, for example, have the developers open for new ideas, of doing things each one in a different way or learning from one another, of being confident enough to innovate in places. These, I mean, since software is a product of the human thought process, as I said, culture is what kind of sets the mind it makes the mindset of the developers, especially if you've been in an organization for a long time, you kind of get set in the way of thinking of the company. I've done that myself in all the companies that I've been to. So founders of companies, managers need to be, I think, very acutely aware of what kind of culture are they encouraging within their organization. And if they don't get that culture right, if they don't pay respect to that aspect, they might have bad software even if they hire great people. I've seen that happen in many, many places. 

DAN_SHAPPIR: I would like to actually also, and I seem to be the guy pushing back this time, so I'd like to push back on another thing that was said before, which was the, like, comparing software to other engineering fields. I feel that this does a disservice to software because I think there is, like, significant inherent difference between software engineering and other forms of engineering. And I think you actually touched on this in the Hebrew podcast where you discussed this topic before. And that's in software, we really solve unique problems each and every time. I mean, an analogy that people like to make about software quality is like, imagine that you were driving your car to work and like every drive out of a hundred, the car would explode and kill everybody in it. But that's not an accurate comparison. Because in many ways, cars have not changed during the past almost 100 years. Bridges have not changed in a lot of, wait a minute, I'll get to greater detail on that. Bridges have not changed for something like 2000 years. Software, every bit of software that you write is like almost totally different from any other software that's ever been written in a lot of ways. And the problems that get solved are always unique. Now, when you do look at cars, and think about how modern cars are different than let's say cars from 10 years ago, you'll find that a lot of the difference is that cars today have a lot more software in them than cars that existed like several years ago, like cars that were like 20 years ago didn't have any software and now almost every car does have software and then suddenly you realize that you know software and cars is crashing or like phones, phones like the Nokia phones. Yeah, the Nokia phones used to be so stable because they literally had no software in them other than the built-in operating system, which wasn't that, this like wasn't so far away from the actual hardware. But modern phones like the Android phones, well, they crash all the time and they crash all the time because their computers in our pocket and it's like the exact same software and software problems that we have anywhere else. So again, I think going back to my initial point, I think that comparing software engineering to other fields of engineering minimizes the challenges that software engineers need to contend with compared to other fields of engineering. Now tell me how I'm wrong. 

CHARLES MAX_WOOD: No, I just want to go into carburetors versus fuel injection. But anyway, that's neither here nor there. 

RAN_LEVI: Yeah, I think you're right Dan. I used the... Yeah. the comparison to other fields of engineering as a starting point of my discussions usually, because that's what people outside of the software world, that's the kind of comparison that they are probably thinking about. These guys are so suck at being an engineer that they can't even get software right. Why? I mean, the building stands. Why can't software be as good? But you're right. Software is inherently different I mentioned one aspect, which is the hardship of concealing or dealing with complexity by schematics, for example, in architecture, but also take, for example, hardware design in electronics. I was an electronics engineer for a long time. If I want to add more memory to a computer hardware, all I do basically is duplicate more memory cells. If I had one gigabyte, I'll add another gigabyte. No problem. It's, you can't usually do that in software to hide complexity. You can't just duplicate stuff. So yeah, engineering in other fields and software engineering is, there is a fundamental difference. 

AJ_O’NEAL: So two things. One, I have a 2006 Prius. It scares me because so much of it is controlled by software and it's one of the first cars to do that. And it is quite buggy. Like sometimes it doesn't turn on. Or you have to like park it and turn it off and turn it back on. Thankfully, nothing's ever malfunctioned while driving. But just in the, the like turning on, turning off phase, I've got it stuck where like the gear shift doesn't respond. It won't go into reverse. It won't go into drive. Everything seems fine. Got to power it down, power it back on again. That's so scary to me to have software in cars. 

RAN_LEVI: You know, when I thought to be afraid of flying. And I was never afraid of flying until I became a developer. 

AJ_O’NEAL: Well, so I've got a buddy. 

RAN_LEVI: Being afraid of flying. 

AJ_O’NEAL: I've got a buddy who's a pilot and a software developer and he says one of the things that scares him is autopilot, not because autopilot, he's actually not afraid of the software. He's afraid of the conditions that the software can't handle and people not getting their flying time in because they're getting their flying time in on autopilot where they're not really checking their gauges. They're not really taking control of the vehicle and ensuring that it's responsive. They're not familiar with what the plane flies like anymore. And so in the rare occasion that there is a problem, the pilots are less prepared to deal with it because they've had less actual flying hours and experience. But that's a different tangent. So the other thing I was going to say kind of piggybacking on Dan is, so yeah, when I think the biggest problem in software, the most difficult challenge is that people don't know what they want. And I think that happens in every area of the organization. When we talk about a building, now I don't, I'm not a contractor. So, I mean, we could, I've lived in houses where it was very obvious that they were working with an architect and they didn't know what they wanted because you've got bathroom with a slide door coming into the living room next to the garage door. And it's like nobody wants a thin slide door bathroom in their living room because of someone you know so there's definitely when it comes to custom houses I could definitely see that there's people who obviously didn't think through what they wanted because if they did they they wouldn't put the bathroom right there where everyone can hear them tinkle. But in general, in the building we want a couple of things we want it wired for communications. We want it. And gosh, I mean, like AC ducts are terrible. Like even in housing developments, like AC is something that almost always fails because you've got to route the, the ducks at jaunty angles. And it ends up that like, from one room to the next, for some stupid reason, the AC vent goes like straight up over almost every house that I've lived in has the wiring wrong. When I moved into, to, to this townhome. All the light switches are backwards. Like you flip one light switch that should turn on the hallway light, instead it's turning on the kitchen light. Like almost every single, like common sense. First light switch in a room should be the light for that room. The next light switch, if the room has a fan, should be the fan. The next light switch should be the light switch that connects the connecting room. None of that is this way, right? So in the sense of like, how do we build the building? How do we make sure that it can withstand its height and minor earthquakes and, or flood damage if it's in an area where it needs to be, three or four extra feet off the ground. I think we've got that covered, but I would argue the people that are building buildings, in a lot of cases, they don't know what they're doing either. And it's not really well thought through either. And when you live in a home like that, which many of you have, you see that someone didn't think this through. Somebody didn't test. Somebody didn't flip on the light and say, hey, is this light actually connected to the right thing? We had our cable was wired to like our, no, not our cable. The ethernet was wired to the telephone jack in the kitchen. And the telephone jack was wired to the ethernet jack in the, in like the living room, the bedroom ethernet was like not connected, right? So when I got into here, I started messing around with all the wiring and everything, getting it set up right. So I, you know, can have my office on ethernet and have ethernet to the TV so that we don't have buffering all the time, whatever. But software is even worse because, okay, if you want to consider like the building, okay, we've got web servers, you know, we've got web stack frameworks and they do the right thing. They can compress, they can like all the standard stuff that's well defined. They can do, they can compress the data. They can tell you what size it is. They can tell you the characteristics of the data so that the client knows how to interpret it. So if you, you know, if you think about the architectural structure. We've got a lot of that in place, but where the problem comes is people don't know what they want and people don't, on all sides. My primary benefit as doing contract and consulting work is helping people figure out what they want because normally I'm coming into a bunch of just wrong assumptions. You look at this even if you just look at job posts. How many job posts are asking for like, they want a PHP developer, they want a Java developer usually to me that's a clue that they just don't know what they want. You know, cause if you knew what you wanted, you, you wouldn't say like we want to build this in PHP or like even what's really coming right now. Like everybody's like, we need a react developer. You talk with somebody, well, what do you need? Well, we need an email form. Okay. What else do you need? What else is interactive about your site? Really? We just need an email form. We need a reactive developer to build out our, our web app. Well, no, you, you don't. So you've got miscommunication just on every side from the clients and then between developers, between managers. And the larger the organization and you kind of reference like the larger the organization, the worse the outcome is, but the more opportunities you ever miss communication because the salespeople are talking with the customer, they're misunderstanding what the customer wants because most times salespeople aren't actually in the domain of the customer. They're relaying that to middle management, middle management's creating criteria for that. They're relaying it on over to the developers. So by the time the requirements get to the developers, the requirements are already so screwed up and the developers are told, okay, go, go build this. And then, you know, if they spend too much time trying to plan, it's like, well, you know, you're just spinning your wheels, which is often true. You're not getting this done. So it's like, okay, let's get to implementation, but then you're, you're, you're trying to build it. And even, you know, the word agile is just like the biggest four letter word, because it's, it's a complete lie. People just, they do waterfall development and they, they call it agile. They build out these requirements. They don't have a feedback cycle with the customer. They push and deploy something. And then it doesn't work. And they, well, why not? We're agile. Well, because you didn't actually do anything that's agile. You just took your old process and then let the manager call it agile. Anyway, like huge rant there, but lots of stuff to unpack. 

RAN_LEVI: Oh, that's exactly right. I mean, when people started creating software back in the 40s and 50s, they started with waterfall because that's, that's the basic process of almost all engineering. You take requirements, you create some sort of spec document and then you create the project based on it. But it obviously didn't work for software. That's where Agile came. But I think you're right. The most basic ingredient in Agile is actually the feedback loop. If there's no feedback loop with the client, because really clients don't know what they want, then the whole concept of Agile doesn't work. So yeah. 

CHARLES MAX_WOOD: Yeah. what AJ is talking about here is a lot of this comes, comes down to essentially knowing, you know, having experience, right? So having that thin door on the bathroom next to the living room, you know, you have a couple of embarrassing moments and then the next place you move to, you make sure that it's got a solid door on it, right? You know, the, the kinds of things, I mean our house, yeah, there are a few light switches that are in places where the first year we lived here, you know, I'd walk, into a room and I'd slap the wrong wall trying to turn the light on. And, you know, and so it's that kind of a thing. And so there's a certain level of experience there that you're looking for. There are certain things that you just kind of have to learn the hard way. Right. And yeah, I also agree that enough, enough job listings. Yeah. Where they say I need a react or a Java or a Ruby developer you know, with so many years experience, yeah, they generally don't know what they want. And the reason is, is because they don't understand the problems they're trying to solve, which isn't necessarily even their fault, which is interesting too, right? Because, you know, you've got some manager, some startup founder, or somebody else who's not really ever going to be in a position where they're going to have to understand it at a level where they could accurately indicate who to grab. But yeah, if they can, if they can boil down what they need, to, yeah, a certain set of requirements. They can bring somebody in who has a certain level of experience with UX. You can start to mitigate some of those things. The other thing that's nice though is that in order for me to fix like the light switch, I'm thinking of one light switch in particular in my house, that I would love to move. I'd have to move it to the other side of the door and the other side of the wall. I'd actually have to cut holes in my wall and pull wire through. And the reality is, is with software. Fortunately, it's kind of nice in the sense that I can just go in and I can Refactor that piece of software and refactor the parts that make assumptions about how that works. And at the end of the day 

RAN_LEVI: a point because it's yeah, it's gloriously famous Hard fair fair enough. Yeah to change monolithic software I mean, yeah, you touch something and if you if you're not really really careful to break everything 

CHARLES MAX_WOOD: Yeah, if everything's coupled to it. Yeah, you know 

DAN_SHAPPIR: Yeah, you know, to refactor the light switch on the door and you'll do that and you'll find out that the handles are now reversed. 

CHARLES MAX_WOOD: Yeah, you've got you. Well, the problem goes all the way back to the breaker and now I have to refactor the whole breaker box. 

AJ_O’NEAL: Oh, right. And I lived in a house where the jacuzzi tub in the master bedroom was connected to the light switch in an opposite bathroom that was further away. And the breaker would trip and oh, 

CHARLES MAX_WOOD: yeah. 

AJ_O’NEAL: So people don't get houses right. 

DAN_SHAPPIR: But what do we do to get software right? I mean, we've been talking about how bad software can be. What can we do about it? 

RAN_LEVI: So that goes back to the point which I raised earlier, which I think, which is culture, the culture of the company, because as Charles mentioned, I mean, experience as an example is very important. Software, you make a mistake once, you'll probably won't return, won't turn that same mistake again, but not all software companies really try to keep their developers, you know, happy and, and, and learning and growing. Some companies say, okay, so he'll work here for a few years and then he'll go and then they will hire somebody else. If you understand the complexity of getting software, right. You understand that keeping some somebody in the company for many years with intimate knowledge of why our specific software in the company is so complex in that certain aspect is a very important part of making a successful software in the company. If you won't get your culture right, if you'll drive developers away or you'll take a developer which you can pay him or her less because you don't really value their experience right. You'll be ruining your software without even realizing it. You'll have, you know, you can invest in getting the best code editors and getting the greatest and shiniest fastest servers. But that's not what's going to help you keep your code correct. It's the people, it's the thought processes that you need to nurture and keep. And hopefully, I mean, good companies really do take good care of their developers. But not all of them. I've heard lots of horror stories. 

DAN_SHAPPIR: Yeah. 

RAN_LEVI: I can tell you stories. 

DAN_SHAPPIR: Yeah, I think it's also kind of an inevitable situation in the market right now. I mean, we've been talking about it on several shows that the average experience of a JavaScript developer these days is around three years. So like 50% of JavaScript developers have three years or less of experience. That certainly creates situation in the software development industry, at least, you know, the one involving JavaScript where you can, you would probably find a lot of organizations where, you know, the senior developer would be the one with two years of experience. So this whole concept of, of base of avoiding bugs based on experience is going to be very challenging in this type of a scenario, I think.

 

Are you stuck trying to figure out how to get to the next stage of your developer career? Maybe you're just not advancing fast enough in the job you're in, or you're trying to break in in the first place, or for whatever reason you keep going to interviews and it's just not working. You want to land that dream coding job, but it just doesn't seem to be working out. Well, John Sonmez has written a book for you called the complete software developers career guide. He walks through each stage of the development career and all of the things that you need to do in order to move up, keep learning keep growing and find that next job that's going to get you where you wanna go. So if you're stuck and trying to figure this stuff out, go pick up the Complete Software Developer's Career Guide. It's the number one software development book on Amazon. It's sold over 100,000 copies so far. I actually have friends of mine that reach out to me and go, hey, do you know this John Sonmez guy? Cause his book is awesome. So go get the book. You can get it at devchat.tv slash complete guide. That's devchat.tv slash complete guide.

 

RAN_LEVI: And why do developers quit companies? I mean, most of the people that I know, they quit not because of specific pay. I mean, if somebody offers you lots more money, we had Amazon come to Israel at some point two years ago, I think. And there's a kind of, there was a brain drain from other companies because Amazon was, were offering huge salaries. But that's kind of rare. Most of the, most of the developers I know quit companies or moved to different companies because the management was not good enough because they wanted to try new technologies and new ideas and they had no space for that in their existing company. And it's a shame because all you need to do is, you know, give somebody the, the, the opportunity to try something new. Maybe like Google did many years ago. I don't know. They're still doing it. They gave their developers one day off a week to try their own projects which was back then, talking about 15 years ago, it was a revolutionary concept. Giving your developer a whole day in a week to do whatever he pleases or she pleases, it's an amazing concept. And it worked. Gmail and other products came from that culture. 

DAN_SHAPPIR: I do want to bring up the topic of salary for a minute because here's a certain pet peeve of mine. Because again, going to some of the research. You mentioned Fred Brooks and going back again to that book, The Mythical Man-Month, one of the interesting findings that he shows in that book, which was written a long time ago, but I assume that one is still correct, that certain developers contribute dramatically more than others. We kind of discussed, we touched on this subject before. He showed that there was like a difference of like, I know that everybody hates that 10 X developer argument and everybody defines it wrong and it's a big thing, but it is true that certain developers contribute significantly more than other developers. Like, 

AJ_O’NEAL: this is just the Pareto distribution. This happens in every industry. Like anytime you look at something.

DAN_SHAPPIR: But if you contribute three times more to the organization, let's not call it a 10x. Let's just say that you don't contribute 10 times as much. You just contribute three times as much as other people in the organization. 

AJ_O’NEAL: I think 10x is more likely. 

AIMEE_KNIGHT: Yes. 

DAN_SHAPPIR: Yeah, probably. Yeah, but let's put the exact factors aside. My question is, suppose you're contributing X times more to the organization than other developers. Do you earn X times more? And the answer is Never. I mean, you at best, at best, yeah, really rarely, at best, the, the, the like within the same level, the best-performing developer in the organization, and the least performing developer in the organization, there'd be at most a factor of like 50%, or maybe 100%. But never.

AJ_O’NEAL: Generally speaking... 

RAN_LEVI: I don't think it can work, Dan. Nobody can... I mean, there won't be an organization if there are so much disparity in salary. Even if it is somehow, I mean, you can give an excuse for that disparity, grounded in reality, no organization will survive such disparities between peers of the same level, I think, from my experience. 

AIMEE_KNIGHT: Pearson? I want to, I want to chime in. Here's the thing I think people sometimes don't realize though, with that, which like brings me back to kind of what I was saying at the beginning is what are you measuring as far as contributions? Because there are developers who can write tons and tons of code and, but I think sometimes the motivation to do that is stemmed from like their own curiosity. And because of that the contribution doesn't actually affect the bottom line for the company. So yes, they're writing code, but are they helping the company turn a profit? Not always. DAN_SHAPPIR: Okay. I'll just say this. I think that in the end of the day, if you find any, any organization and you ask people honestly, like who is the most contributing developer to the success of the company within a certain group people will likely have a common answer. People usually do know who is the one contributing the most. So I'm putting aside all various fancy ways of measuring it. And I totally agree that measuring by lines of code, that reminds me of like Dilbert strips. That's not realistically what you want to measure based on. So I do want to mention though, another possibility of improving software quality. So we talked about culture and about motivating people and getting experienced people to stay. The other thing that 

AJ_O’NEAL: I want to make one comment before we move on. 

DAN_SHAPPIR: Sure. Go for it. 

AJ_O’NEAL: Okay. I, junior developers make more money than senior developers from this regard. If it takes a junior developer four hours to do something that it would take a senior developer to do, the junior developer is going to make twice as much money. So that's, I, this is my argument against the idea that if we if we were to focus on, I don't think there's enough senior people to hire, but if we were to focus on hiring senior people, you would have a better ROI. 

DAN_SHAPPIR: Anyway, the other point that I wanted to raise is that you can, like assuming that you're going to have bugs in your system, you could overcome this in a sort of way that's kind of similar to how biological system works, by building resiliency into the system or making the system able to quote unquote recover from bugs. So you can build your system in such a way that basically says, yes, things are going to malfunction. Things are going to go wrong. But I'm going to be able to cope with that. It's not going to become catastrophic, because I have resiliency built into the system. 

RAN_LEVI: And I think that this is a frame to catching exceptions, et cetera. 

DAN_SHAPPIR: It could be low-level stuff like catching exceptions. It could be high-level stuff like having multiple data centers so that if one data center goes down you can route traffic to some other data center instead or it could be being able to having like monitoring systems on your production and being able to quickly roll back things that you push into production if you see indications that the things are not behaving properly. So all of these systems assume that something is going to go wrong and then build resiliency into the system to overcome these problems and not turn them into a catastrophic situation. I think again, going back to your podcast episode that unfortunately to our listeners again is in Hebrew, you gave the example of that the electric electrical problem that kind of blacked out like the entire East Coast of the US. I don't remember when it happened, but the problem there was that they didn't have resiliency for the particular situation kind of happened. It was sort of like a disease that attacks the immune system. The problem, I think you said there that the problem was that the malfunction was actually in the software that did the monitoring, and consequently they didn't realize that they actually had a problem. So they didn't have resiliency for that particular situation. Trying to build resilient systems, I think, is the solution for a lot of situations where software problems can become catastrophic. 

RAN_LEVI: But I have to raise a point here about resiliency, is that resiliency comes with its own set of costs and issues. In my days as an engineer, I usually worked for companies, military equipment companies. And as you're probably aware, I mean the demands of military grade equipment are usually much higher in terms of resiliency and other aspects than commercial software. Which meant that the development process was much, much, much longer. We're talking about years sometimes to create software that could have taken a smaller startup weeks to month to create because of the demands for you know, extra layers of protection, extra backups, extra checks and re-checks and re-checks, which means that if that's the way of handling complexity in software or making sure that we create almost bug-free software, not many organizations can probably handle the costs of that methodology that way. It's very difficult to create resilient systems both in hardware and software. 

DAN_SHAPPIR: I totally agree, but I think that some of the changes that are happening in the software ecosystem are kind of making it easier for us. Previous companies that I worked for, we would release software literally on DVDs, like once or twice a year. And once you sent that DVD over to the customer, then it it was out the door. You couldn't make any changes in it. And if you did want to make any changes, it was this whole process. And sometimes some of these customers were not willing to accept fixes above a certain rate because they had this whole validation process. And it was just too expensive for them to receive patches at like more often than let's say once every every two months or so. So you literally had to really work hard at ensuring that, like you said, software was kind of almost quote unquote perfect when it went out the door and it was really problematic. But today when we've got software as a service, as it were, and we're delivering software, let's say from the web, and it's definitely true for a lot of our listeners, after all we're a JavaScript podcast, it means that we can push to production much more quickly, we can roll back from production much more easily. And as long as, again, the system doesn't catastrophically fail, we can kind of deal with it because if there's a problem and we're able to identify it quickly enough, we are generally able to provide a fix for it also fairly quickly before hopefully, too many customers notice. And it's definitely something that we need to leverage. Let's put it this way. 

RAN_LEVI: Yeah, I think that you're 100% correct on that. Let's keep in mind that with the new tools and ways to distribute software, as you said, A, there comes bigger challenges because if, for example, in your old companies with the DVDs, you had X number of clients to support, now a software company in a global environment via the internet probably has hundreds times more clients to support, which means more complexity. And B, the tools that we sometimes use to kind of offload that complexity, for example, patching in, you know, if you update your application via the internet, we are basically offloading the complexity from our software to the platform software. For example, the Android or iOS platform that handles the patching for us. So we're basically moving the complexity. There is still the complexity, but it's now being moved to a different company, which can help us. But that means that if a Google engineer made a mistake in Android in some way, now all the companies that are reliant on his software are now going down with him. And I think we've seen occasions where AWS crashed, and then Reddit crashed. And and Instagram crash and everybody crashed because one company's infrastructure failed somehow. So, it is easier to create more complex software, as you said, because the tools we have now are better. But the basic premise of bigger software equals more bugs still kind of holds, I think, from my experience. 

DAN_SHAPPIR: Oh, you're definitely true. But from my perspective, we kind of, you know, it's what you're describing is true by definition. I mean, if, if there's a catastrophic, but if I'm right, developing software for Android devices, and there's Google deployed version of Android with a catastrophic bug, I'm going down whether my own software has bugs or not. So and so as long as I'm kind of reliant or dependent on that system, I might as well try to take advantage of it and leverage the benefits because I'm going to suffer the bad consequences regardless. 

RAN_LEVI: So I might as well enjoy the ride. 

DAN_SHAPPIR: Yeah, exactly. 

CHARLES MAX_WOOD: That's it. I'm going to go farm pigs. 

RAN_LEVI: No, I mean, creating software is so much fun. I wouldn't do, if I could, I would probably stay all day in code with bugs and with the rubber ducks you have to talk to to debug them. Creating software is such an amazing experience. I wouldn't change it. My rubber duck is a jerk. 

CHARLES MAX_WOOD: Anyway, we are sort of getting toward the end of our time. One thing that I thought was interesting though, is that you brought up, and I love stories. So if I get somebody to tell me a story, I'm like, boo, yeah. And you, you mentioned in the information that I looked at something about the Denver airport. And baggage claim? 

RAN_LEVI: That's a great story. That's one of the archetypical stories of software development. It's kind of a cautionary tale. We're talking about the Denver International Airport, which was renovated in the late 80s. And as part of the upgrade and changes in the airport, the Denver municipality wanted to add a baggage transportation system transports baggage from the airplane to the people in the airport and they designed on paper What was supposed to be the most sophisticated baggage system ever created? We're talking about think it was a system with tens of thousands of carts and you know motorized tracks that would transport baggage in real mean the luggage would change tracks in real-time. And it was supposed the baggage would fall into carts. The luggage would fall off one track and there would be a cart waiting at the exact right time to pick it up and take it somewhere else. It was supposed to be a science fiction kind of a system, except that after three years of development, it wasn't even close to being ready, of course. It was already late as it should be. And it took another year until they actually demonstrated the working system for the first time. The reports from back from the newspapers talk about the big demonstration with journalists and the mayor kind of, you know, cutting the ribbon and all stuff. But that demonstration turned out to be, you know, farce. People describe it as being in a Charlie Chaplin kind of movie luggage flying through the air, carts were found, barcodes not scanning the right luggage at the right time. Nothing worked. And people were laughing but crying at the same time because we were talking about a system that I think it costs almost $400 million to create. And Denver was losing a million dollars a day each day that the software wasn't deployed yet. And it's a sad story because after five years almost of development, the Denver municipality had no, no choice, but to scrap most of the system because it never worked. And whatever small part of it remained, actually, none of the airlines agreed to use it, except I think it was United Airlines, which did, but after a few years. In which the system broke down so often that it cost another million dollars a month just for maintenance. They also gave it up and they moved back to, to position back to manual luggage carrying across the airport, which is a kind of a sad story. I mean, it's, it's a, it's a very, very typical story of how a team of, I think it was only 20 developers back then trying to get something right. But changing requirements, story we all know about. I mean, clients always change their minds and changing and always being in a rush to get something out of the door when it's not ready. And of course, there's also the technical aspects of hardware. 300 computers back in the 90s trying to speak to one another in real-time. That's a real technical challenge, and it failed miserably. So Yeah, I really suggest to our listeners to check out the Wikipedia entry for the Denver International Airport baggage system. And there are lots of, you know, analysis done by companies, you know, consultant companies about that situation, what went wrong. It's a real eye-opener. It was for me, at least. 

CHARLES MAX_WOOD: Wow. 

 

A couple of years ago, I put out a survey asking people what topics they wanted us to cover on devchat.tv. And I got two overwhelming responses. One was from the JavaScript community. They wanted a React show. And the other one was from the Ruby community and they wanted an Elixir show. So we started both. The React show though is React Roundup. And every week we bring in people from the React community and we have conversations with them about React, about the community, about open source, about what goes into React, how to build React apps, and what's going on and changing in the React community. So if you're looking to keep current on the current React ecosystem and what's going on in React, you definitely need to be checking out React Roundup. You can find it at reactroundup.com. 

 

CHARLES MAX_WOOD: All right, well, let's go ahead and head into our picks. I love the story, by the way. Now I wanna go see what all the details were. And of course I could have done better. 

RAN_LEVI: Check out the FBI's virtual case file story, which is another story of huge software project crashing down and burning crashing and burning. Check it out on Wikipedia. It's a really interesting story. It's six hundred million dollars that went down the drain this time. 

CHARLES MAX_WOOD: Oh that makes me feel better. I don't pay taxes in Denver but I do pay taxes in the US. So yeah anyway yeah let's go ahead do some picks. Dan do you want to start us off with picks? 

DAN_SHAPPIR: Yeah why not? So since everybody's telling funny stories about software bugs I decided to also pick two funny stories about software bugs as my picks. So one interesting story is the French rocket launch, the Ariane 5 rocket launch in 1996, which was, they were, it was a combination of a development project that cost $7 billion. And what happened was that 40 seconds after launch, the rocket crashed, tumbled and crashed. And when they did an investigation, it turns out that it was due to an uncut software exception being thrown, because they converted the 64-bit number into a 16-bit number, and there was an overflow, and that caused an uncut exception, which caused the whole thing to crash. And the funny thing is, was that the computation wasn't actually even needed after the launch. It was supposed to be a computation that only takes place prior to the launch. So it crashed due to an uncaught exception in software that wasn't even supposed to be a module that wasn't supposed to be running. So that's one interesting story and I'll share the link with that. And the other interesting story of a bug with interesting consequences, and this one is more I guess of a specification bug than a software bug, is what happened with the Mars climate orbiter that was supposed to orbit Mars and measure the weather there, and it crashed. And the reason that it crashed was that the specifications said that they were supposed to use metric units, but unfortunately, they sent the information using pound-force per second. So obviously when you're expecting values in one using one set of metrics, but receive them using another, things go wrong. And what happened was that the satellite went too low and then just crashed into Mars surface. And obviously, you know, getting satellite from Earth to Mars isn't cheap and takes a whole lot of time. So when it crashes, that's really sad. So these are two interesting software bug stories that are my picks for today. 

CHARLES MAX_WOOD: Wow. 

RAN_LEVI: Reminds me, there's a famous picture circulating in the Internet of the girl who the woman who coded the Apollo 11 mission computer. And she's standing in that picture next to a huge pile of pages, which is supposed to be the software running in the spacecraft. And when I looked at it, my first reaction was, if I was an astronaut and I was aware that this is the software that's supposed to land me on the moon. I would never go on that spacecraft. They probably never understood how complex the software is. And it was written on paper. 

DAN_SHAPPIR: Yeah, so that engineer is Margaret Hamilton. And she's amazing. She's one of, in my opinion, she's one of the heroes of our field. And I think it's like the whole, like the fact that the Apollo made it to the moon, like doesn't stop astounding me to this day. Yeah, it's incredible. And she certainly had made a significant contribution to that. And by the way, the funny thing about it is that they, like, as I recall, like a year or two ago, they released that software on GitHub or something. And within 24 hours, there was already a pull request on it. 

CHARLES; Nice. I love that. Amazing. All right. AJ, did we get your picks? 

AJ_O’NEAL: We did not, but oh, we will. Oh, we will. All right. So I'm going to, there's so much stuff this week. I'm going to try and narrow it down and save some for next week. First of all, I finally got the magic keyboard two and the magic trackpad two. I've been holding off on this knowing that it's going to have to happen. Eventually my magic trackpad one, the, the metal little flippy do on the bottom that causes it to click is starting to degrade in performance to where sometimes it will stick and not complete its click. And I've been really, really, really hesitant on the Trackpad 2 because it seems like on the MacBook it's all software-defined. It's like a little sound and a buzzer rather than an actual click. But the standalone Trackpad 2. If it's software, if it's not actually clicking, if this is just a speaker and a little rumbler inside, I can't tell. To me, the Magic Trackpad 2, the standalone feels like it's actually physically clicking. The click is different. It's actually kind of nicer because it seems to click equally from any position that I touch it, which is a good indicator that it's probably software, not physically clicking. It's just me feeling a little bzzz or something, but I don't know. I can't tell even the force click, like it unclicks on the way up and I can feel the unclick and I don't know if they just fix the drivers or what, but it doesn't have the lag that I mean, most people I've been using the MacBook 2012. So most of you are already used to the software to find trackpad. But for me, this, this is like, this is a big step. Okay. But yeah, it doesn't seem to have that lag. Like when I press it, it seems to click exactly when I press it and not have that like 100, 200 millisecond delay where I'm like, where's the click? Oh, there it is. That was obviously software, not hardware and the keyboard, the butterfly keyboard. I think, no, not butterfly. What is this? Scissor switch. Yeah. Butterfly was bad. Scissor switch. Scissor switch is good. It's, it's nice. So, you know, if you're, I know there are like five of you out there that are still on the Mac book, 2010, 2011, 2012. If you're that person, the magic keyboard and the magic track pad. Yeah. They're going to take some getting used to. You might have a visceral reaction to it. But usually a couple days, it actually isn't so bad. I'm starting to like it. So I'm gonna give that a plus one. Also, Final Fantasy I, Dawn of Souls, or I guess Final Fantasy I and II are titled Dawn of Souls. I'm playing it on the Game Boy Advance attachment to the GameCube with GameCube, can't say things today, through the HDMI adapter on my projector. And I actually had to scale the screen down because when it's that big pixelation is so not pixelation per se, but when the things are so large, it's actually more difficult to discern the images when they're a little smaller. So I have it at like half the size of the wall instead of the whole size of the wall so that I can, so that's easier to distinguish what the characters look like. But anyway, the best, best way to play Final Fantasy one. So I'm going to link to like what I use to do that. But also, I just want it like Final Fantasy one is a very great game. Like I'm pleasantly surprised. This is my first time ever playing it. And it's just, I just like it's, it's completely open world. You can go from one side of the sea and then it wraps back around to the other side of the sea. So that was unexpected. I thought it would be like, you know, the earlier Zelda's where when you hit the edge of the sea, it's just like, okay, can't move any further. No, it just wraps around. Like you're on a complete world. The, the story is good. The, the game plays good. Like I'm supremely impressed at no wonder it, it, you know, was such a hit. I, I just, I couldn't have imagined that the original final fantasy would be this pleasurable to play, but it is. And I'm really, I'm really enjoying it. I could encourage other people to check it out. One thing I can't stand though, which works to your advantage. The random encounter rate is through the roof. Like in some areas, you, I mean, it's difficult to explore the map because you're having so many random encounters that when you come out of it, you're like, wait, was I going to East or West just then? So that's one thing that is not the best about it is just random encounters, way too high. And then last thing much quicker, LS deluxe. So LS is, you know, pretty boring and stable and old and we like that. And that's great. LS deluxe is better in a couple of ways. It has nice syntax highlighting and you do need to, well, you don't have to, you can use an alias to tell it to show icons. Never. But you do need to have the nerd font installed and I've got an easy installer for the nerd font, because if you visit the GitHub repo, it's like super confusing. So I made a little cheat sheet for that. And yeah, so it'll show you like an M icon for markdown files, like a document with an M it'll show you in folder icons for folders. It colors all particular types of things, a particular color. It's just, it's just really nice. And it's cross-platform, which means that, you know, you can work it on windows too. So you can have nice LS everywhere you work. And yeah. So shout out for LS deluxe also called LSD, but I call LS deluxe for the purpose of that's what its official name is, even though it's abbreviated LSD. And if you search for LSD the results that you're going to get are going to be varied. Whereas if you search for LS deluxe, 

RAN_LEVI: it's more interesting though. 

DAN_SHAPPIR: Yeah. 

AJ_O’NEAL: Results you're going to get are probably going to be more honed in. So just kind of got a cheat sheet for that, for how to set your aliases. If you, you know, if you haven't been setting like LL and LA and so on and so forth, now's now's a good time to go ahead and start using those and no better way to use it than with LS deluxe. It also gives you a treat. Which is nice. It gives you a better version of tree. That's all. 

CHARLES MAX_WOOD: All right. I'm going to throw out some picks. I've really been enjoying. I'm down to the last book on the light bringer series, which is by Brent Weeks. And it's, it's terrific. It's called the burning white. And anyway, great, great fantasy series. So I'm going to pick that just cause I've been super enjoying it. And then yeah, there was something else I was going to pick and I am blanking. We watched The Martian again last night, which is terrific movie. It was funny too, because I was sitting there with my father-in-law and he asked me how it compared to the book. And so I started pointing out all the things that were different between the two. But yeah, I really enjoyed that as well. So I'm going to pick The Martian. And one last thing. So this week, I am getting down and dirty with the podcast Starter Playbook. So you can start picking up the course. So if you're interested in starting a podcast, I'm doing a reviewers edition, which means that...You get the videos as I finish editing them and putting them together and putting them out. The course, when I'm done with it, is going to cost somewhere in the ballpark of $1,000. But I'm looking at putting that up for $250. So if you want to get the podcast starter playbook and start a podcast, that's the way to go. I'm going to move pretty quickly into the podcast playbook itself. And that's going to be much more around actually building out a team and working your podcast from a little bit more of a professional approach. So usually it's either business people who are willing to put the money into not having to do the editing and posting and things like that, or people who have grown their podcast to the point where they can get enough in affiliate income and things to pay somebody to edit their stuff. And then it'll walk you through hiring editors and setting up, growing your podcast with SEO and growing your podcast by appearing as a guest on other shows and getting guests on your shows and things like that. Some of that will be in the starter podcast, starter playbook, but not all of it. So just be aware. That's what I'm working on. I'm also working on another course for programmers is the MVP, the most valuable programmer. And we talked a little bit about kind of the 10x programmer situation and how some developers contribute more than others. And I'm going to basically put together a course that teaches you how to be that person that's contributing three times or 10 times or however you want to measure it. But you know, teach you how to be that go-to person on your team, on your development team, because there are certain things that these folks do. And if you're doing them, then you're going to level up to the point where you're going to be able to be that person on your team. So anyway, those are my picks. 

RAN_LEVI: Very important for beginning developer. 

CHARLES MAX_WOOD: Yeah, absolutely. And the stuff you could do right away. Like none of this stuff is, Oh, well, I have to have three years under my belt and then start doing no, no. A lot of it really just comes down to how you stay current, how you know what's going on, how you pick up new technologies, how you pick up all of the other essential skills. Somebody said we don't use the term soft skills. We use essential skills and I like that. So I'm stealing it, but how you pick up all those other essential skills, right? So that you're contributing to your team. And it's not just, I write more better, nicer, prettier code than them, but actually. You know, I am driving this forward in a way that benefits the entire team. You know, so I'm coaching, I'm mentoring, I'm, I'm helping make good decisions on what technologies we use. I'm making, helping make good decisions on how we architect and arrange our code, how we test our code, how we validate our code and all of those things go into, you know, how we, how we work together as a team. So yeah, so we're going to dive into a lot of that stuff too. So anyway, MVP and yeah, Ron, what are your picks?

RAN_LEVI: I'll go with a book as well. I'm a big science fiction nerd. So I'm reading now a book called The Three Body Problem. It's from Chinese author, I hope I'm not mispronouncing his name, Lu Shiqing. And it's actually not a new book. I think it was released almost 10 years ago and even more. But I started reading the series just a few weeks back and it's a great science fiction book. It's very, very interesting to see science fiction written from the Chinese perspective, the Chinese culture. I've been reading science fiction, Western science fiction for many, many years. Reading Chinese science fiction is a very new experience for me, but it's a great story and really very insightful. It's what's called hard science fiction. It's science fiction that's heavily based on real-world physics and ideas. So it's very recommended read if you love science fiction. And in general, AJ mentioned games and being an old timer, I'll recommend something that I'm sure most of our listeners will raise a brow of. It's called MUD, short for Multi-User Den Dungeon. And what it is, it's a genre of games that was actually started late in the late 70s. And it's an entirely textual adventure games. There are plenty, tens of thousands probably of such games across the internet, all using old telnet technology. If somebody is familiar even with the name, but these are fictional worlds, which are totally played in text. You know, give, put, take these kinds of commands. And although it seems so anachronistic, you know, playing games in text only, when we have, you know, great graphic cards day and virtual reality and what's not. I find that there's no alternative to the power of imagination. And some of my most emotional and powerful experiences in games were in those textual universes. So if you're looking, if you're a gamer looking for a totally different experience, check out MUDZ. It will blow your mind if you can handle the steep learning curve. 

DAN_SHAPPIR: Ron, I'm curious. Did you play Rogue at any point? 

RAN_LEVI: Rogue? 

DAN_SHAPPIR: Yeah, you remember that textual maze game? 

RAN_LEVI: Yeah, I know the name, but I don't think I've ever played it. No. 

DAN_SHAPPIR: Give it, try to find it online and give it a try. 

RAN_LEVI: I will. 

DAN_SHAPPIR: Enjoy.It's not, it's, it's, it's not so much text-based as it's using text for graphics because it's that old, but, but it's fun. 

AJ_O’NEAL: So I, I'm going to mention Dunnit because this is something that almost everybody that's listening probably has on their computer. Well, everybody has a Mac at least. Dunnit is a text-based game. I don't know if it quite falls into the category of mud, but in terms of gameplay, I think it would, it would meet that requirement. It's something that's super accessible. Because all you do is copy and paste the command emacs space dash bash space dash L D U N N E T hit enter and boom, you are playing one of the little Easter egg games that exists on most Mac and Linux computers. 

CHARLES MAX_WOOD: Nice. I actually put up a list that I found on Wikipedia of a whole bunch of muds as well. So yeah, that's fun. Yeah. All kinds of stuff. All right, Ron, if people want to connect with you online, where do they find you?

RAN_LEVI: So the Wix engineering podcast is on wix.engineering slash podcast. Also search for Wix engineering podcast. You'll probably find it. And I'm on Twitter at at Randlevy R A N L E V I. And I'm, I'm also on Facebook search for Randlevy. Lots of levies in Israel, but probably I'm no, I'm an old Facebook user. So hopefully they'll find my name. 

CHARLES MAX_WOOD: Awesome. All right. Well, we'll go ahead and wrap this one up. Thanks again for being here with us. 

RAN_LEVI: Thank you very much guys. It's been a pleasure. 

CHARLES MAX_WOOD: All right folks, till next time, Max out. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C A C H E F L Y dot com to learn more.