STEVE_EDWARDS: Hello from a very sunny Portland.
CHARLES MAX_WOOD: AJ O'Neill.
AJ_O’NEAL: Yo, yo, yo. Coming at you live from back cramps. Getting old. Back cramps.
CHARLES MAX_WOOD: I'm Charles Maxwood from topendevs.com. Now, AJ, you were talking about, as we were talking about what to talk about today, we had our guest cancel last minute, who apparently was Dan. He had something come up, but anyway, yeah, you were talking about like these. I can't, I can't remember the term you used for like of craftsmanship. OK, but yeah, it's the the one I'm familiar with is the the Python one.
AJ_O’NEAL: Zen of Python.
CHARLES MAX_WOOD: Yeah. But then you've also got I mean, I've seen some that are just kind of like Minaswan and in Ruby, right, where it's Mets is nice and so we are nice, which is, I guess, not a craftsmanship thing. It's a community thing. But
AJ_O’NEAL: yeah, I would I would not. But I think Ruby has dry. I think that Ruby invented dry and rest.
CHARLES MAX_WOOD: Yeah, and Rails also has convention over configuration.
AJ_O’NEAL: Which that is an anti-principle, but that's another argument.
CHARLES MAX_WOOD: It's an anti-principle.
AJ_O’NEAL: Well, it goes against the Xenopython explicit over implicit, but maybe we, how do you wanna do this? Do you wanna go over the whole of them and then dig down into them or what?
CHARLES MAX_WOOD: Well, I'm kinda curious just because I guess I see some value in it, not every community has them. And so I'm wondering, is there something about say, you said Go has one as well, right? Kind of a list of principles that they try to adhere to.
AJ_O’NEAL: Yeah, the Go Proverbs.
CHARLES MAX_WOOD: So is there something about Python or Go that tends to push people into saying, hey, we're going to espouse these ideas? We also have like the Agile Manifesto, which is more, I guess, generalized and has more to do with the process of writing software than the actual crafting of software writing code.
AJ_O’NEAL: Yeah. The agile manifesto is more about the man, the management process. I think anybody who is a consultant should be familiar with the actual agile manifesto.
CHARLES MAX_WOOD: That's a whole other podcast episode.
AJ_O’NEAL: Well, because there's, I just want to be clear. People say agile and you know, they hear agile and they tune out because what they're familiar with agile is, is waterfall that's been rebranded agile. And that is broken down into say weeks or months rather than years. But, and I guess you could say that if you look at it under a certain lens, that agile process is just a waterfall process that is broken down into weeks or months, but it's, it's more than that in terms of, of a philosophy. And then if you are doing short-term work with multiple companies, the agile manifesto is something that I believe you really should take to heart as well as the 12 factor app.
CHARLES MAX_WOOD: Right. But let's throw back because the 12 factor factor app is another one that's kind of more generalized. It's not just one community,
AJ_O’NEAL: but all of these apply to everything. So the Zen of Python, literally, I don't think there's a single stanza that is Python specific.
CHARLES MAX_WOOD: No, that's fair.
AJ_O’NEAL: Is about craftsmanship and it is not about specifics of linting or anything like that. The go proverbs are a little bit more specific in terms that they reference things that are go things. But again, they are the go proverbs maybe can't as well be applied to some of the older languages, but modern languages, the go proverbs apply to really well because all modern languages have these sorts of features about them, which I, you know, we can go into that if we go into that.
I remember working my tail off to become a senior developer. I read every book I could get my hands on, I went to any conference I could, and watched the videos about the things that I thought I needed to learn. And eventually, I got that senior developer job, and then I realized that the rest of my career looked just like where I was now. Where was the rush I got from learning? What was I supposed to do to keep growing? And then I found it. I got the chance to mentor some developers. I started a podcast and helped many more developers. I did screencasts and helped even more developers. I kind of became a dev hero. And now I want to help you become one too. And if you're looking forward to something more than doing the same thing at a different job three years from now then join the Dev Heroes Accelerator. I'll walk you through the process of building and growing a following and finding people that you can uniquely help as you build the next stage of your career. You can learn more at devheroesaccelerator.com.
CHARLES MAX_WOOD: Okay. So there's so much there that I kind of want to respond to, but I'm not going to.
AJ_O’NEAL: Well, do do. I mean, why not? I mean, call me out if you think I'm wrong. I am I'm ill informed on something or, or if you just disagree that the committee method works or.
AJ_O’NEAL: it was, but he was a strong arm. He was the face. Yeah. He was the one that you could believe in. No one else was getting up, giving conference talks and saying, this is what the future needs to be. This is what we should believe in. This is a path that will take us to success.
CHARLES MAX_WOOD: So I guess the other thing though, is that does then a Python then come from Guido? Is that his name or?
AJ_O’NEAL: Sorry. Yeah.
STEVE_EDWARDS: Guido van Rossum.
AJ_O’NEAL: Yeah. So it does not come from Guido. It comes from Tim Peters. But it is part of the, there's, there's these things called PEPs P E P. And I don't remember exactly what that stands for, but this one actually came out fairly early on. This was PEP 20 back in 2004. So a little bit later than, than I thought it was, but Tim Peters, I, I'm not super familiar with the Python community, but I am led to believe that he is one of the inner circle. Maybe he was just a rando. But let me Google that real quick and see. But this was something that was blessed by the inner circle and, and put forth in official Python documentation as this is what we believe in. And you see this Scala has one of these. I have actually, there's a list that I have, if I can find it where so Tim Peters known for his major contributions to the Python programming language and its original C Python implementation a pre 1.0 CPython user who was among the group of early adopters. So he was, so where you have say Ryan Dahl was the creator of Node and Dino now. And then Isaac's was one of the people early on that came into the inner circle. And then that became the NPM foundation and whatnot.
CHARLES MAX_WOOD: Right.
AJ_O’NEAL: So I, it sounds like that kind of thing. It was one of the inner circle people was the Tim Peters that came up with it. And like I said, it's in the official. It is actually built into Python. If you type import this, when you open a Python interpreter, it will print out the Zen of Python.
CHARLES MAX_WOOD: Okay. So what's the story behind the adoption of the Go Proverbs then? Is it the same kind of thing?
AJ_O’NEAL: Yeah, but it took a lot longer for the Go Proverbs to come about. And part of that is the mentality of the Go community is to move slow and deliberately. And there's this aspect of discovery. We're looking for patterns that are going to help us to have fewer errors and to have greater success in developing correct programs. And that's really the key thing. You'll notice there's no syntax sugar in Go. The idea, both that, Crockford echoed this as well. If you want syntax sugar, you should just use an editor where when you hit tab, it auto completes for you, right? And that's part of what the GitHub Copilot and some of those other systems offer a little bit better tab auto completion. In some cases, a little bit worse because you have to go delete more. But anyway that's the kind of thing where if you're doing redundant tasks that an automated tool could look at and see, oh, you want the same loop that you just did in this other file, but you want it to apply to this variable instead of that variable here. I can auto complete that for you. So there's a very little syntax sugar and it's more about over time. What do you learn about the language and its uses and its intentions and what went well with the intention and what didn't. And then they come out with, here are some defensible arguments that we can make about the language. Should I just read through the Xenopithon and the Go Proverbs?
AJ_O’NEAL: And by the way, Ruby does have a, an official one called the Ruby doctrine.
CHARLES MAX_WOOD: No, it's the rails doctrine,
AJ_O’NEAL: the rails, sorry. So the rails, it's rails.
CHARLES MAX_WOOD: So the rails doctrine does exist. And yeah. We should do a Ruby Rogues episode on that. Anyway, but yeah.
AJ_O’NEAL: Okay. So sorry, if there was a question there, I missed it.
CHARLES MAX_WOOD: There, there wasn't. I just, I just find it fascinating that we have this. So, so yeah. So I'm curious then as we go into this, cause you've been writing go lately, I think more than Python.
AJ_O’NEAL: Yeah. I was never, I was never big into Python early on when I was in college. I discovered Python because people talked about kind of the ethos of it that when you went to Python meetups back then, and I don't know what Python meetups are like now, but I imagine that because of the ethos of the language and the community, it's probably held over, over time, but there was a real strong sense of discipline and a strong sense of we're looking to find the best ways to do things and things that are easy to read and easy to teach and easy to understand, and that drew me into Python and that's in mingling with Python people granted this was early, early, early on where I had only used PHP and basic to that point. And then, and then school introduced me to Java and classmates introduced me to Python and Python Isis, it told me what this whole everything on rails was about. And then I went to the Ruby meetings and the Ruby meetings led me to node because someone had a Ruby meeting presented on node. And then, you know, the rest is history, I guess, conference talks and such, I learned about Go and then through friends, I learned about Rust, but that was kind of, yeah, I took a path to learn about these things and I never, so I never was deep into Python. I was just learning it to understand software better and didn't know what it was I was looking for yet in a programming language.
CHARLES MAX_WOOD: Makes sense. So yeah, so let's go ahead and dive into one of these. I don't know if we want to do a Go Proverbs or Zen of Python. One other thing that I'm curious about really quickly is, you know, I know you've been writing go, but is there one set of these that you identify with more than the other?
AJ_O’NEAL: I would say all of them tend towards the same. So I would recommend studying each of them. And as you're writing code, think to yourself, is this code defensible? Can I do I have a defensible argument for why I make the choices I make? Again, if you don't stand for something, you'll fall for anything. One of the great crockford isms is you're not paid to use every feature of the language. You're paid to create correct software that works well. And I think I also had a friend in college who, I think this quote comes from somewhere else and I, I might be flowering it up a little bit better than the way she said it, by the way, that I remember it was the constraint of the medium defines the art it's not in taking every Liberty that you create art. It's in constraining yourself to a certain set of values that you create art. So you could take some trash and some paint and everything that's around you and put it in a pile and call it art. And it wouldn't make any sense. But if you only took the trash and you didn't take the paint and you constructed it into something, it can become art because you did something unusual. You took odds and ends that were in a trash bin that you could clearly identify as this is the sort of thing and a trash bin, a Coke can, some paper, some paper clips, whatever. And you could call this office montage or whatever, kind of beside the point. But the idea of, well, people get really upset about the idea of their art. They think their code is their art and their white spaces, their art and your white spaces, you may see that as your art, but I'm going to argue that you shouldn't as a software engineer, because that is not what creates the, that's not what makes code run well, easy to read or fulfill any of the functions that it is supposed to fill. Whereas if you constrain based on principles and you selectively choose not to do things because you are disciplined in a particular way then I view then that to me that is the art of code is finding the disciplines that reduce what you use in a language to a set of code that is Expressive in a way that is more correct.
CHARLES MAX_WOOD: You hurt my feelings.
AJ_O’NEAL: I probably did I probably heard a lot of people's feelings, but you know if they listen to the podcast they're getting they're getting more accustomed to that
CHARLES MAX_WOOD: anyway So, yeah.
AJ_O’NEAL: So let me go through the Zen of Python. I'll just go through it quickly. I won't do any commentary and I'll go through the Go Proverbs. And you'll see the Zen of Python is very applicable to all code and it's quite subjective. It's a little less concrete, but here it is. The Zen of Python by Tim Peters. Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although, practicality beats purity. Errors should never pass silently, unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. And I am gonna comment there, that is one of my favorites. There should be one and preferably only one obvious way to do it. Although that way may not be obvious at first, unless you're Dutch. I think that's because the inner circle was mostly Dutch. Now is better than never. Although never is often better than right now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea. Let's do more of those. That is the Zen of Python. And if I go over to the Go Proverbs, they're not quite as maybe poetic, but so Go Proverbs by Rob Pike, simple, poetic, pithy. Don't communicate by sharing memory. Share memory by communicating. Concurrency is not parallelism. Channels orchestrate, mutexes serialize. The bigger the interface, the weaker the abstraction. That's a great one. Make the zero value useful. Empty interface says nothing for those not familiar, marker interface. Go format style is no one's favorite, yet go format is everyone's favorite. A little copying is better than a little dependency. Those are words to live by. Cisco must always be guarded with build tags. Sego must always be guarded with build tags. Sego is not go. With the unsafe package, there are no guarantees. Clear is better than clever. Another one for the fortune cookie. Reflection is never clear. Errors are values. Don't just check errors, handle them gracefully. Design the architecture, name the components, document the details. Documentation is for users. Don't panic. Now, the Go Proverbs, if you are only familiar with untyped languages, then a lot of these things may not make sense. The Go Proverbs are intended for languages that are concurrent, meaning, well, that means a couple of different things, but let me be a little bit more broad than that. For programs that are intended to run on multiple CPU cores at the same time, and for languages that have a more strict type system than what Python provides. Because Python does have a strict type system, but it's not as strict as Go. And Go actually came out of Python. Go is a spiritual successor to Python. If you listen to the early talks that comes across fairly clearly. I don't know if they explicitly stated, I believe that they do. I believe that they actually do reference that the goal was to make something that was as pleasant as Python, but as powerful as C.
CHARLES MAX_WOOD: Right.
STEVE_EDWARDS: So here's a little clarification question for you, AJ. You had said complex is better than complicated. What's the difference?
AJ_O’NEAL: That's actually one of the ones that I don't understand that well. And I went to look for a talk where somebody explained that and I did not find one at the time that I was looking for it. But I think that it probably has to do with the say, think of complexity and computer science terms that sometimes you have great cyclomatic complexity, meaning that there are lots of branches in the code. If else switch calling out to another function that calls out to another function. So I would say that that is complex and that there are many pieces that must interact together. And I think that complicated is when I would say complicated code comes out of, for example, have you ever tried to dry something up? So for those not familiar, DRI, one of the Ruby principles, don't repeat yourself. Have you ever tried to dry something up? And at the end of that refactor, your code is more difficult to understand than it was before.
STEVE_EDWARDS: Oh yeah.
AJ_O’NEAL: That is what I would consider complicated. You are making choices about which things should be variables and which things shouldn't be variables and how something should work to try to force it into a pattern that's hopefully you realize before you're done, it doesn't actually fit with. And so the code is not just complex and that it has many interactions, but it's complicated and that the interactions are not intuitive, easy to read or likely to produce correct results.
CHARLES MAX_WOOD: Right.
CHARLES MAX_WOOD: Right.
CHARLES MAX_WOOD: Right, I know that makes sense.
AJ_O’NEAL: Of course, it does fly in the face of what some people are taught. So for example, with the reintroduction of C-sharp, through TypeScript, people are going back to things that we know are bad. But that's what it is. It's not even, it's not even, I mean, you're laughing.
CHARLES MAX_WOOD: You have to go punch. You have to go punch that every time.
Are you ready for core web vitals? Fortunately, Raygun can help. These modern performance metrics play an important role in determining the health of your website, which is why Raygun has baked them directly into their real user monitoring tools. Now you can see your core web vital scores are trending across your entire website in real time and drill into individual pages to focus your efforts on the biggest performance gains. Unlike traditional tools, Raygun surfaces real user data not synthetic, giving you greater insights and control. Filter your score by time frame, browser, device, geolocation, whatever matters to you most. And what makes Raygon truly unique is the level of detail they provide so you can take action. Quickly identify and resolve front end performance issues with full waterfall breakdowns, user session data, instance level diagnostics of every page request, and a whole lot more. Visit raygon.com today and take control of your core web vitals. Plan start from as little as $8 per month. That's raygon.com for your free 14 day trial.
AJ_O’NEAL: But in languages like C sharp and Java, what we learned and C plus plus is that the complexity of inheritance type systems is bad and leads to code that's difficult to reason about. And bad as a moral word. And so we need a technical reference to say why something is bad. If the moral good of code is to write correct code that is easy to read and easy to reason about and easy to enhance in the future, then we know that inheritance type systems are bad because inheritance type systems make code less visible, it less clear on where certain properties of an object come from, and they make it more difficult to modify the program to add additional use cases. There are numerous reasons that we can empirically say inheritance type systems are a bad idea. And so the way that languages like Go and Rust handle this are a more modern approach with a looser coupling of how the type system works. And you can write more expressive code that is more correct and easier to extend. And you use different features to do this. But anyway, I got off the rails there, as I often do. Never. All right,
CHARLES MAX_WOOD: well, we're kind of getting toward the end of our time. What were you calling these again?
AJ_O’NEAL: So I call these creeds of craftsmanship. And I put a link there to enumerate some of them because most languages have them and most of them tends towards the same thing. Although there are some of the Ruby ones and Python ones come into conflict because Ruby is of the mindset of convention over configuration, which I don't think has to be in conflict with explicit over implicit, but the way
CHARLES MAX_WOOD: that the rails more than a Ruby idea.
AJ_O’NEAL: Oh, okay. And I, I, sorry, I get those mixed up because I was introduced to Ruby through rails. And so some of the creeds, I,
CHARLES MAX_WOOD: most people were. And to be perfectly honest there too, sometimes there's conflict between, uh, the core ideas that are espoused at the Ruby and Ruby core level and the rails and rails core level as well.
AJ_O’NEAL: Oh, okay. Well, in any case, I don't think that these things have to be contradictory. I think that you can prefer convention over configuration and you can have very well known conventions, but at the same time, you can do it in a way that's explicit. For example, generators, you generate a file and you have a convention that has been set out and when you generate the file, the file has stub code that follows those conventions, but I don't like the idea of you run a single command without a config file and it does a bunch of magic and you don't know why one option is chosen over and over and over. That's no, that's your opinion. Not about the creed itself. There's definitely benefits to convention over configuration. And I do not doubt that, but we have the Zen of Python, the Go Proverbs, wet, dry and aha. You've definitely heard of dry. If you've been a developer for more than six days, I mean, that might be a little bit ungenerous, but dry is one of those things that gets pounded into you very early on in your career. And then wet is something that you may hear of hopefully you hear these three together because they're complimentary. Dry is don't repeat yourself, which is what leads to very complicated code if you adhere to it in a sense of practicality beats purity. If you are purist of don't repeat yourself, then you will end up writing complicated code that doesn't do anything sensible because all words can be condensed down into a single column of words, if that makes sense. Every construct of code is repeated because we need for loops in multiple places. We wouldn't abstract away every possible condition of a for loop into one function. Anyway wet is write everything twice, which is basically saying, yes, don't repeat yourself, but make sure that you've written it twice first. And what I will say is typically three times is what I go with. I go with, if I write similar functionality three times on the third time is when I start to say, maybe I should abstract this. If I only wrote it twice, I may never go back and abstract it. But if I get to the point of writing it three times, I might say to myself, well, this looks like something where it may benefit from abstraction, I have to investigate, because sometimes the small differences, the small nuanced differences between two similar bits of code are so different in the way that they're used that if you try to abstract them, you end up with what I talked about earlier, complicated abstraction, where the abstraction no longer is indicative of what the code is supposed to do because of its switch statements and stuff make it complicated. And aha is avoid hasty abstraction. So the three of these, they go hand in hand. They're not in conflict, they're in concert. And so I'd suggest that you learn examples of all three of them together, and you will be a great software developer in that regard. And Kenzie Dodds is the one that coined the term avoid hasty abstractions. I was trying to come up with one. I think I came up with a Rye, which was, I don't remember what it was, but it basically was the same thing, avoid hasty, I don't remember, repeat yourself with purpose, purposefully repeat yourself or something. Ripe, ripe. That was trying to do repeat yourself with purpose, but he coined the term aha. And I actually think that that one is better than, and I'm glad that someone came up with something that, that captures that sentiment. The agile manifesto is more about process, especially as if your contractor 12 factor app is about deployment. It's about how do you, how do you structure your code so that you will be able to deploy it effectively? It has to do with how you use environment variables, secrets how you prepare the code to be deployed in the system. So it's a little bit higher level, but still worth knowing. You've got the laws of UX, which we didn't touch on at all, but these are principles that anybody who is doing HTML and CSS should be familiar with, and particularly anybody who is doing design. And if you have on your resume that you are a UX person and you do not know the laws of UX, one, you're not a UX person. Okay, that's a little harsh. There is discipline that is necessary to differentiate between UI and UX. UX is not just about putting pretty colors together. It is about creating a user flow that works towards human psychology. And the laws of UX are kind of the canonical textbook principles that you would learn if you studied UX in any formal fashion. So they include things such as, I'll just rattle off a few here, aesthetic usability effect, which everybody gets that one. Unfortunately, that's, that's the the catchall of if you can't do anything to make the UX better, just make it pretty instead. That one everyone understands. Doherty threshold, Fitts' law, gold gradient effect, Hicks' law, Jacob's law, law of common region, law of proximity, law of prognons, law of similarity, law of uniform connectedness, Miller's law, Occam's razor, Pareto principle, Parkinson's law, peak end rule, Postol's law, serial position effects, Tesler's law, von Restoroff effect, Garnet.
CHARLES MAX_WOOD: Wow.
STEVE_EDWARDS: So what about the law of the jungle? Is that in there too?
AJ_O’NEAL: I think it is.
STEVE_EDWARDS: Okay, good. Kill to be killed?
AJ_O’NEAL: But this. These are principles that if you adhere to, you cannot help but fall into the pit of success with happy users. I would just say that the very first one I mentioned, because it begins with a letter A, I think these are in alphabetical order, if that was right. I don't know, maybe they weren't. But the aesthetic usability effect is the one that's like the empty interface. It is to be used with extreme prejudice because it is the easiest to do and it has the worst results. But anyway, you've got the rails doctrine, things like rest convention over configuration. Well, actually those are different rails. Oh no, they, these are in the actual optimized for programmer happiness menu is a Macassi, which I guess I'd learn what that is.
CHARLES MAX_WOOD: If I'm a causey,
AJ_O’NEAL: oh, Macassi.
CHARLES MAX_WOOD: Yeah.
CHARLES MAX_WOOD: Yeah. Well, I don't know. I mean, I think a lot of it just comes down to personality and willingness to push on stuff. I find that some people have the personality of just not wanting to rock the boat. So even if they're right, they just don't want to go and say the thing that's true. But at the same time, I also find that other people, you know, they're willing to go out there and yeah, maybe they're a little more cantankerous and they're willing to go out and defend a hard to defend position or defend a correct position even though they know it's going to be a fight.
AJ_O’NEAL: Well, this is the funny thing in software development is that there are positions which are not hard to defend. They're extremely easy to defend. They are, they are borderline obvious. They are along the lines of if A then B, if B then C, then of course, if A then C. This is something they are, they are reductionist principles that applying the most base level of I don't know, I'm using fancy words. Let me, let me rephrase that and not sound so pretentious. So we get if a then B and B then C then of course, A equals C meaning if, if one cause creates an effect and that effect creates another effect, then the original cause will always create the final effect. This is the principle of the transitive property of geometry is what it's called. You. You learn this in middle school, although you may not remember it because you may have hated that class and it may have been really tough with all the triangles and all that.
CHARLES MAX_WOOD: Yeah, but the point is, is that some of these things go against kind of the common accepted way of doing things and there's gonna be some pushback and some people just aren't willing to, they're just averse to conflict, even if they're right and even if it's easy to defend.
STEVE_EDWARDS: Yeah, I've seen that in other open source communities. I can remember one discussion in particular and another community where they were trying, I believe the issue was trying to determine, well, actually it was across multiple issues, whether it was a new technology to be adopted or a way of doing something. And the complaint was that it was always the people who were the most vocal who got what they wanted, not necessarily what got the most votes or what had the best-
CHARLES MAX_WOOD: Or who made the best argument.
STEVE_EDWARDS: The best argument for it, right? It was who was the most vocal and whoever was the most vocal, and in some cases maybe well-known, those- the points that were being pushed by those people is what got adopted as compared to, you know, really looking at what is the best option and why.
CHARLES MAX_WOOD: Awesome. I'd be curious just to see what it is.
AJ_O’NEAL: So do you want me to read it?
CHARLES MAX_WOOD: Um, yeah. And then we've got to wrap up cause I'm, I've got a hard stop.
CHARLES MAX_WOOD: All right.
CHARLES MAX_WOOD: Cool.
STEVE_EDWARDS: That sounds very joyous.
CHARLES MAX_WOOD: Mm-hmm.
Hey folks, it's Charles Maxwood and I just wanted to jump in here and let you know about something that I'm doing. It's free. It's out there just to help you get answers to your questions about the things that you're running into with your career. So if you have questions about how to get further ahead in your career, how to start a podcast, how to get a better job, how to get a raise, how to deal with a situation at work with your boss, or just maybe you're stuck and you don't know where to go next. You know, how do I get from junior to senior, senior to whatever's next? How do I become a speaker? How do I get to the next level? That's what I'm out here to do. So every Wednesday at 12 o'clock Mountain Time, I'm gonna be doing a call and it's gonna be free, totally free. Go to devchat.tv slash level up and you can register for the call. It's using Zoom's webinar software. So it's pretty straightforward And what we're gonna be doing is I'll do 10 minutes and I'll just show you how I do some form of how I level up and then we'll just answer questions. And it's not gonna be a question and answer like, hey, what's your favorite flavor of ice cream? And then I say, rocky road or whatever, right? Instead, what we're looking for is more along the lines of, yeah, I have this situation, how do I handle it? I'm trying to figure this thing out, how do I figure it out? I'm trying to stay current, how do I stay current? And if you have any of those kinds of questions, I'll bring you on the call. We'll ask some deeper questions. We'll make sure we get you a solid answer. And I'm really looking forward to helping some people out. There will be no sales, no selling, no nothing on these calls. It is literally just 10 minutes of training and then Q&A. So you can go check it out at devchat.tv slash level up.
CHARLES MAX_WOOD: All right, well, I'm gonna go ahead and push us to picks. We're kind of over time. I definitely need to go take care of some stuff. So Steve, do you wanna start us off with picks?
STEVE_EDWARDS: Sure, I'll go with my dad joke for the day, which a little bit of exclamation Chuck and I have what is otherwise known as the chrome dome. I prefer to think of it as God made only so many perfect heads and the rest he covered with hair. But amen brother. So even though I have shaved my head for years, I still have a comb. I just can't part with it. And then also, you know, there's that whole fast and furious movie franchise, which I think nine is the most recent release. And I just heard that they're going to make a tenth iteration of that franchise. And they're going to call it fast 10 your seat belts. So those are my picks.
AJ_O’NEAL: I'm smiling, but you didn't quite generate a laugh.
STEVE_EDWARDS: Well, that's better than nothing.
CHARLES MAX_WOOD: You couldn't part with a laugh or a comb. OK. All right, go ahead.
STEVE_EDWARDS: He's got he has too much hair.
AJ_O’NEAL: The main thing that I would pick is this this list of the Creeds of Craftsmanship. It's something I reference bits of these quite frequently on the show. And this list is not hosted where I want it to be right now. It's just a get issue, but I think that that, well, you know, it works. But I know that I can be abrasive. I know that I have these strong opinions and sometimes that's a turnoff. So if you can just let your forgivingness or your whatever it is inside of you that looks over the flaws of others and, and is gracious enough to pick out the, the benefits that they have to offer despite their flaws. I implore you if you are, well, somebody that's listening to this podcast, you're involved in software to, to take a look at these, give them a glance over and give some of them a serious study. And as you're writing code, think about how it applies, think about what you can do, how you can avoid errors and how you can tend towards success. And if you do know of any other creeds of craftsmanship, I am going, there are a few others that I didn't go over at all, such as patterns and see closure rationale thinking and react. I don't know if that one counts or not. Scholar rationale. There's a few other ones that I know of, but if you know of some that I haven't mentioned, I would love it if you would make a comment on that issue and bring them to the fore because I'm always interested in, in seeing what else is out there. But. But please do take a look at these things because they, I don't know, I believe that they really will help you. And I believe that if we can tend away from these Twitter memes of HTML is a programming language and tend towards true principles of software design that help us be better as a community, and if we can find someone to lift up to be a great leader in that, it'll result in a better, sounds a little far-reaching, but it'll result in a better world. If we had software that was more accessible and more correct, it would result in, in a better world, more and people would have information to more knowledge, they would be able to use more tools and they would be able to rely on those tools. And I think that's, that's my plea. With that aside, there are, so I manage a couple of meetups, uh, somehow. I don't, I don't even know how that, that ends up working out, but I do. And recently, because of the way that the new meeting room that we're in is set up. We We had some trouble with the getting the TV connected and I've always had trouble with HDMI. It's it's because there's too many different standards. There's HDMI 1, 1.1, 1.2, 1.3, 1.4, and then there's the corresponding HDCP for every version of HDMI and every device in the chain always have to has to obey everything. And so whenever I get HDMI stuff, I've learned to try to get the best that's available, even if it costs twice or three times as much because there's a greater chance that plugging it into things will work. And it is, it is nigh unto impossible. No, it is impossible to find a HDMI certified coupler. If you need to extend an HDMI cable, those don't exist. Nobody has the cojones to, to certify their coupler, probably for a very good reason that if you have a coupler, it means that something is on the other end of the coupler, which means that your coupler is likely to fail an exorbitant amount because the cable on either side could have some slight mismatch in the hardware or, or built-in chip specification. Uh, but there is a brand called ZestKit and they do have certified cables. They do not certify their extension cable or their coupler, probably for the reason that I mentioned, but their other cables are certified and it appears that their coupler and extension cable live up to the same standards as their straight cables, but probably just don't get certified because anytime you plug something into something else, you know, then you'd get complaints and people would say, well, you certified this and you said, but you plugged it in something else that wasn't certified, you know, anyway, so I'm just going to put a link to the 10 foot HDMI cable from ZestKit and their coupler, because this is something that if you have had the struggles of trying to plug in things to HDMI and the screen turns green or magenta or it flickers or whatever, you know what I'm talking about. So for those of you that have that. There's, there's something that I hope can help you, especially if you're a meetup organizer or doing that sort of thing. And then of course, as always follow beyond code, if you'd like Facebook, Twitter, YouTube, uh, all right there. There's my personal live streams as well as the, the beyond code channel.
AJ_O’NEAL: Me too.
CHARLES MAX_WOOD: So yeah, digging those. So if you're into that, I'd go pick them back up again, but I'm listening to it on Audible. So there you go.
AJ_O’NEAL: Warning, there is some strong language in Leviathan Wakes, at least right out of the gate. I imagine there's probably some spicy scenes in there as well from what it seems to be alluding to.
CHARLES MAX_WOOD: Yeah, they curse a bit. They don't, I think they acknowledge that certain characters hook up with other characters. They, throughout all the books, you're aware of that. It doesn't get very explicit.
AJ_O’NEAL: Okay, good. It turns out in Lightbringer, well, my wife has warned me that there's some spicy scenes that are not as in as much detail as a good romance novel would be, but are more detailed than you might want to have playing in the living room with the kids.
CHARLES MAX_WOOD: Lightbringer.
AJ_O’NEAL: The Broken Eye, no not the Broken Eye, the Blinding Knife. Oh yeah. The first one was the Black Prism, the...
CHARLES MAX_WOOD: Yeah, yeah, some of those they get, it gets a little bit more. Anyway, yeah, good books though. Anyway, those are my picks and yeah, I'll go ahead and wrap this up. Till next time folks, Max out.
Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. To deliver your content fast with Cashfly, visit cachefly.com to learn more.