Relicans Director of DevRel, Jonan Scheffler talks to to Software Engineer and Serial Entrepreneur William Shepherd about how he’s loving life working in DevRel for OneSignal, his love of Typescript, how learning design patterns is integral as a dev, and his piece of advice to others? Don't focus on trends. You don’t need to know everything.

Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.

Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.

Welcome back to Polyglot. I'm Jonan. I'm the Director of Developer Relations here at New Relic, and I'm joined today by my friend, Will. How are you, Will?

William Shepherd: I'm doing well. How about yourself?

Jonan: I'm hanging in there. It's Monday, and the same rule always applies on Mondays: they're terrible. You're just sprinting as fast as you can. [chuckles] It would be more convenient, I think, if we just worked seven days a week 12-14 hours a day. We could get so much more done when you think about it.

William: I actually do that already, so it's fine. [laughter]

Jonan: I know, right? You're like, yeah, that sounds like DeVRel to me actually, which is what you do, right? You're a developer advocate. How long have you been doing that?

William: Three months. I'm very new to this.

Jonan: How do you like it so far?

William: So far, it's fine. I'm still learning all of the different areas of DevRel. I'm learning that it's a lot more broad than I originally thought. And I'm just trying to figure out where I can fit in.

Jonan: Yeah, I think it is maybe one of the most broad pursuits in our segment of the industry with maybe the possible exception of being a product person. When you're a product person, like, oh, okay, so your job is to build products, whatever that means. But DevRel is definitely broad as a subject. You got advocacy, and evangelism, and dev experience teams. And people in any given role within developer relations, you really have no idea what they're doing. They may be someone who writes documentation full-time or works on open source, or only produces content. It is definitely broad. What sort of work are you doing?

William: So I've done a pretty eclectic amount of things. I've contributed to our documentation. I've put together blog posts on how to integrate our product with other products. I've done a conference, and I'm trying to do the community stuff. And one of the things that I'm also considering is adding some typing so I can work in the developer experience with TypeScript.

Jonan: Oh, interesting. And you said you've done some stuff on integrating your product. What product is that? We haven't mentioned your employer. We should probably do that piece as DevRel people.

William: Yes. So I work for a company called OneSignal. We are an omnimessaging platform for marketers where we can allow you to send messages via push notification or in-app messages in your apps, emails, text messages. And we do segmentation so that you can message the right users at the right time, depending on whatever filters you have in place.

Jonan: That's a very interesting product. So this one OneSignal because it is one place to rule them all. And you're not just providing SMS services or email. You're doing all of it, any contact that we might have with our customer.

William: Right. And when you think about it, sure, you can integrate with Twilio, and SendGrid, or Mailgun, or any of these other tools. But then you have multiple things that you have to integrate with, which increases complexity, which increases surface area to bugs, and just all kinds of issues, so we handle all of that. But we add some marketing stuff on there as well for marketers to use without having to have teams do custom code in order to deliver the functionality.

Jonan: That's smart. It's a good product. I'm sold. I'm going to go sign up for OneSignal right after this show.

William: It's free. So you have no excuse not to.

Jonan: Okay, I'll try it out. So you've been working on a lot of things since you've been there. But being a newcomer to developer advocacy, what is it that you worked on before DevRel stuff?

William: Before DevRel, I was a software engineer for about a decade. I worked on all kinds of things, from mobile stuff when it was new, cloud stuff when it was new, desktop development when that wasn't new. [chuckles] I did some web development server-side, client-side, hybrid type of stuff, systems development, machine learning, business intelligence, data engineering type stuff. I've done everything.

Jonan: You really have done everything, which is a bold statement to make when it comes to software. But you've been kind of all over the place. What's your favorite language?

William: My favorite language is probably TypeScript right now, although C# is a very close second. I'm a big fan of Anders, [chuckles] all of his languages I love.

Jonan: Nice. TypeScript is rapidly gaining popularity, and I know very little about it. But what I do know is it is strongly typed JavaScript. Am I close?

William: Close, yes. You could pretend that it's that. It doesn't really give you true 100% type coverage. But it gives you enough to avoid most of the bugs and the issues that you'd run into without it.

Jonan: One of the things I think that tripped me up learning JavaScript...So I've been playing with JavaScript since the late '90s when writing JavaScript was terrible, and there were no tools around it. And it was like, oh, okay, I know it's broken because it didn't work because nothing happened.

William: It hasn't changed.

[laughter]

Jonan: Yeah, it hasn't changed much. But nowadays, the tooling is so much richer. And one of the most confusing parts for me was the prototypal inheritance bit where you have like, I'm going to have an object. The common example is a car. This is a car object, and it has wheels. But then every new car I make, there's no reason that it can't just be entirely different. This car has wings and detail. And you can artisanally handcraft the independent objects by adding properties to them. That part took me a long time to wrap my head around and also the inheritance where different properties could come from, from that prototypal inheritance I believe it's called, which I think is unique to JavaScript as popular languages go.

William: I think you're right. I think you're right. What I can say to that is with every language feature, you can choose not to use it. Like in C#, there's multiple inheritance and all that kind of stuff. You can use it, or you cannot do it if you prefer not to live a life of pain.

Jonan: Yeah. I kind of feel that way about inheritance generally. I would much rather have a modules or mixin pattern in my languages or force one where I have behaviors that I'm adding to objects. I can decide that this thing is going to have some piece coming in. But it's very well-defined, and I know what to look for. There's no mystery as to how something came to have wings.

So we talked a little bit about your background with DevRel stuff. And of those things that you've heard about in your short three-month term here, kind of like that evangelism space, you're mostly talking about the product. You've got advocacy where you're back and forth and helping level up the product internally and owning a community potentially. And then you've got more of the experience stuff where you work on the product or in open-source technologies and help people understand. What of those spheres seems the most interesting to you?

William: I think the most interesting is working with people, specifically that. I'll find that I do a lot better when I have someone else to interact with. Because let's say that you have enough experience where it's like you are blind to the things that people find difficult or that they don't know, and you assume that everyone knows this; that's me, and I'm aware of that now. So I prefer to actually talk to people so that I can understand where they are. They can tell me and ask me some specific things. What I tend to do is I may give a lot more information than they're prepared for. Because I can start here, and then I can wrap it around to how it relates to something else that's entirely unrelated, so they thought.

Jonan: Yeah, I feel the same way. I'm really excited about software, and so it's easy for me to run down tangents or to not recognize when the person that I'm trying to teach about a concept has lost the thread. I have developed some strategies over the years to check in with people. But when people are teaching me, it's sometimes frustrating when someone's like, "Okay, so we're going to be using a SQL database. Do you know what SQL is?" Like, yes, I know what SQL is. But helping them understand where I am with my knowledge and where I'm trying to go can be very frustrating for them to just check on, like, do you know HTML? Do you know CSS? Do you know what a web app is? What strategies do you have when you're teaching someone for adjusting? How do you check in with someone in conversation without sounding condescending, I guess?

William: Well, honestly, I'll just ask straight up. I'm not really a beat around the bush kind of person. It's like, "Do you know X, Y, and Z?" And I don't just leave it like an abstract like, "Yeah, I know SQL." I try to tease apart which specific things you know depending on what I'm trying to teach you. So let's say, for instance, we're doing SQL or whatever. I'm not just going to ask you, "Do you know SQL?" I'll ask, "Have you ever used the Common Table Expression?" "No." It's like, okay, then I know I should probably explain what that is and why they may be useful and show an example of one, that kind of thing.

So it's more so being more specific about what they know about a particular thing because, as you've stated, technology is kind of big. It's a lot. There are a lot of tangents you could go down. So it's important to orient yourself in what things you should talk about and what things you can kind of skip.

Jonan: And had you asked me if I knew SQL, I would've said, "Yes," but after this episode, I'm going to go and google Common Table Expressions right away.

William: [laughs] Yeah, there's a lot.

Jonan: Next time we talk, I'm going to be all about those Common Table Expressions. So, what sorts of things do you think you're particularly interested in around software? Like, if you had a choice, you're running a school, and you're going to focus on one particular piece of the curriculum, just because it's yours and you're fascinated by it, what do you think you would do? What do you think is most helpful to people or maybe most engaging for you right now?

William: This is a tough one because what's most engaging for me is probably not the most helpful for others.

Jonan: Sure.

William: I really enjoy the theory behind some of the algorithms and the data structures that we use and programming language design. I really love that. But if I'm looking for engagement, I would likely go off of how to be pragmatic in your development. That's one thing that I feel is a skill that maybe you develop over time. I don't know if everyone does, but it's something that I've surely developed over time where you start to understand that you don't need a perfect solution. You don't need the fastest solution. You need a solution. And so long as you have a solution, you can iterate to get to wherever you need.

Again, the pragmatism is like, do you even need that? Is it really going to make an impact? If the answer is no, then why do it? And this is very much shaped by my last job where I was building a product. I had to kind of shift away from being purely...I love computer science type of stuff. So like, oh, well, it doesn't matter if I do this because I laid there with it. So it's reshaped my focus to the user. For engagement, I think that would be the most engaging I think, but who knows?

Jonan: I think it's content that a lot of people need. It took me a long time to learn that. That's the product of pain of all of those pull requests that I spent so much time on yak shaving a particular feature because it was fun, interesting. I wanted to get it right. I needed to make sure it could scale. I had to be prepared for changes. What do they call this here? YAGNI, You Ain't Gonna Need It.

William: You Ain't Gonna Need It.

Jonan: Yeah. Keep it Simple, Stupid, of course, KISS. I think that has leveled me up as a developer more than any one thing, in particular, starting to realize that the only thing that really matters is impact for the end-user. And while it's fascinating to me to go and figure out the most efficient way to do this, or to optimize this, or I made this 18% faster, unless it has real-world value, if I'm saving the company money, or I am shipping something that's going to make the company money, then we may not have a company in the end when the time comes [chuckles] for me to keep building. So this is a good, I think, area to tease apart a little bit.

What other recommendations would you have for people early out in their career around that kind of stuff? We got KISS and YAGNI. We've covered already helping people focus on; I don't know, structure around things. We talked a little bit about modules or mixins as a pattern in software, keeping things organized, maybe. Do you have any tips?

William: Yeah, learn design patterns, whether you use some or not. I worked in consulting earlier, and one of the things that I had to do was learn all of these different design patterns. I think it was Gang of Four that I read, and I've read that several times. And it's useful because as a consultant, you're working across different companies, different types of projects, different levels of engineering. And it's incumbent on you to get in and understand what's going on in a very short period of time.

I feel like if you learn these design patterns and you start to see how they are applied, you can apply them yourself, which automatically makes your code more approachable to future developers because Gang of Four is a book. It's knowledge that anyone can go get on Amazon, and they'll deliver it to you tomorrow. You can go and learn these things. They put names to types of problems and the way that we go about solving these problems. So just learning that would be a great first start.

I wouldn't get too much into the tactics until you actually start to understand why these patterns exist, and what they were meant to solve, and how they've been expanded to solve different types of problems, and how you can use these same patterns in your current work. So, if you're doing a refactor, instead of just saying, "Oh, I think it would be this, this, and this." It's like, well, understand these patterns and say, "Well, this pattern is probably what I'm trying to do. Let me just implement that and see how it will work."

Jonan: It's very easy as software engineers to decide that we must invent a new wheel to solve this problem without first knowing all of the wheels that exist in the world, right?

William: Yes. And honestly, I think that's number one in being pragmatic. It's just like, understand what's around. Don't just jump into a solution because that solution that you think is a solution may not be a solution. It may be an anti-solution in solutions clothing.

Jonan: So the book that we're talking about here, The Gang of Four, you can google this, but we're talking about Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, whose name I'm almost certainly butchering who wrote a book called Design Patterns, very famous book in software engineering circles. If you haven't read this book, it's worth having on your shelf. And it's not a thing that you need to read cover to cover necessarily. It's not a novel. Just go in there and find a pattern and go play with it. Another one around the subject of object-oriented software that I really enjoy was Practical Object-Oriented Design in Ruby. It's written by Sandi Metz.

William: I have that book.

Jonan: Yeah, great book. Very good for people, especially earlier on in your career, trying to wrap your head around object-oriented programming can be difficult. And there are a lot of great resources out there. That book is also commonly known as POODR, P-O-O-D-R. I think poodr.com is where you can find that.

William: To dovetail off of what you just said, that's a really good point. One book, Gang of Four, talks about a language, but it's mostly abstract from language. I think that it's really useful to read these types of books in multiple languages. So when I read the object-oriented one in Ruby, I don't know Ruby, but that's not the point; the concepts are the things that matter. And if you can start to understand that the concept is at a higher level than the language, then you really get a lot of power from that where you're like, no, it doesn't matter what language I do something in; the process, the patterns, all of that remains the same.

Jonan: Yeah. Learning to see beyond the language that you're working with, I feel like is the biggest step to moving out of that beginner zone. I remember speaking often early on in my software career about this intermediate wasteland that exists where you go through the beginner section, and there are infinite tutorials about how to make a to-do app or really any kind of app, recreate Twitter, recreate Hacker News, whatever you want to build.

And then you get into this place where finding intermediate content or finding your way through it, because there are so many different topics to cover, can be very difficult. And if you try to use the same approach that you used as a beginner in your studying where you go and find this thing, go start to finish, find this thing, go start to finish, you end up with an infinite pile of work in front of you and no real progress. I think a really important step there is to start looking for books like Design Patterns, POODR. What other books would you recommend for people who are well into that intermediate space trying to make a promotion to senior, maybe?

William: Pragmatic Programmer. Honestly, a lot of the books that I would recommend for being a better software engineer most of them are not programming books. I imagine most of the people who listen to this show understand that yeah, they may be an engineer, but they don't spend most of their day coding. They probably do a lot more communication to people, not to computers. So it's like that kind of thing, making sure that you can make yourself more efficient, you can manage your own work, that kind of stuff. I think that's the most important thing.

Jonan: Yeah, absolutely. I was very disappointed to learn...I know a lot of people don't like this style of work, but I was pretty excited about just being heads down and typing away at my computer. And I was very disappointed to learn coming into the industry that most of my time is in meetings and communicating about the work that's going to be done, and how the work is being done, and how it was done, and not so much just typing. But in the end, I quite like people, so it's fine. Many days as a software engineer, I have lamented the fact that I didn't have a solid block of four or five hours of just coding because I love it. I enjoy that piece.

William: Well, keep in mind the job is problem-solving. That's really the job. It just so happens that we implement our solutions in code. And honestly, I wish that was something that I would have known before I got into the industry. Because like you, I was just like, I guess I'm going to have to code. In fact, I didn't want to get into software engineering because of that fact, because I don't like coding that much. I'm not like some people; I can do it, but I'd prefer not to if I can.

And it was just a realization that's like, oh, solving problems isn't what I was doing in school in my data structures class. That's not solving a problem because, first off, problems are never specified that clearly where it's like you know what the problem is. Normally, it's our job to go and actually figure out what the problem is because oftentimes, what we think the problem is or what it is on first pass turns out that there is actually a fundamental problem. And if you solve that, just like in computer science, you automatically solve all the other ones.

Jonan: Yeah, I've definitely come around to the code as little as possible thing as I've developed a healthy hatred of computers over the years.

William: Totally understandable. [laughs]

Jonan: All of the late nights of frustrating technical support with my parents over the phone. Yes, I am with you and decreasing the surface area you're exposing yourself to. We're talking a lot about pragmatic design. But I think one of the mistakes I made very early on in my career was to just have...like in an object-oriented setting; I’m quite excited about separation of concerns. So I'm going to make the most granular pieces, and I'm going to have them spread far and wide and then not realizing that your surface area for bugs is just massive at that point. And you have objects that are reaching out to each other like collaborators that really have no business collaborating. You can very much simplify the interfaces between them. It's easy to explode outward in complexity when you try to focus on doing granular work.

To bring it back a little bit to your employer, OneSignal is exactly that kind of solution. Like, sure, you could go and implement all of these things yourself where you have your SMS and your email provider, and then you have your MarTech piece where you're doing analysis of your audience and making sure the right people hear the right things at the right time. Fitting all of those under one umbrella has tremendous value. That same pattern can be applied to our software architecture, I think.

William: Yeah. And in fact, I do see that trend happening more and more. For instance, I can use GitHub for almost all of my stuff now, builds, deployments. It communicates with Slack. It communicates with all of my infrastructure. So if I need to deploy something or roll back something, I have an action that I can take off to do it. And it's like, sure; I could do all these in separate scripts. Sure, I can do that, or I can just leverage this platform that I'm paying monthly for and let them do it because chances are they're going to do a better job.

And that's not necessarily because they're better engineers; it's more so that they have more exposure to the problem. Like, they operate on a worldwide scale. Most individual developers probably have never shipped something that 25 to 30 million people use on a daily basis, whereas they have that. So, yeah, I think it's important to try to leverage the work of others where you can. That's what we do now in real life. We leverage the work of the people who come before us. It makes no sense to reinvent everything.

Jonan: I think it's very funny that I specifically I'm waxing philosophical about being pragmatic in my work because I'm in the business of building nonsense. A particular variety of DevRel includes things like cloud-connected artificially intelligent robotic waffle makers so that I don't have to flip my wrist 180 degrees to turn my waffle maker over by myself. Like, that's a nonsense product. I really like that kind of stuff and having an opportunity to play with toys like that.

Like, I'm building a drink dispensing robot that runs Kubernetes on the robot. There's no reason to do that. I'm just jamming in technology to make it as complicated as possible because it's interesting to me, and it drives my learning. But when it comes to actually shipping a product for a company, you want to take exactly the opposite approach. Fortunately, waffle bot is unlikely to be a company ever.

William: You never know. [laughs]

Jonan: Yeah, right? [laughs] 10 years from now, I’m in the business of producing robotic waffle makers. I distracted myself a little bit because I love my silly robots. Your point is around GitHub having access to all of this product knowledge. You mentioned something; you said 20 or 30 million customers, which I'm sure is approximately what they have there. They have this huge feedback machine effectively for any given feature that they ship so that their GitHub action to roll back a deploy is informed by all of those developers. And you have one brain plus the brains of the people that you read online, but you're never going to catch up.

And giving over the control to a third-party service is sometimes frustrating. I talk to developers occasionally who hesitate to use a third-party library to get a thing done. They would rather just implement it themselves because they don't know if that code is going to break in the future. Well, you're going to take a lot of time building a lot of things that already exist in the world. How do you feel about that? Where's your line?

Because in the JavaScript world, there was the bug a few years ago with left-pad. I guess it's not a bug, but there was a critical failure where a developer pulled their library, and it broke 30% of all the apps out there running in production because they just didn't have a version of left-pad. They were depending on it for their builds. Where's your line between something that you're going to build yourself and something you're going to use from someone else?

William: So, I'm going to use what I'm building currently as an example. I will always use someone else's stuff first because, at the end of the day, I'm solving a problem, and what tool I use, I don't care. I'm going to do whatever I can do to solve my problem first. And then I may go back and do a little bit more research, like look at cost. Is it going to cost me an arm and a leg to do this? And not just cost in terms of actual money but other costs in terms of what happens if they update their stuff and it breaks my stuff? Because it happens a lot where they'll do a patch upgrade or a minor upgrade and something changes, and your app breaks, and it's not clear why. So I look at that type of thing.

And I also consider how difficult is it for me to just do it myself? The difficulty is in doing it correctly. Sure, you can have a solution that works in the best-case scenario. But do I know all of the potential scenarios that I could face? So I tend to only do things that are algorithmic in nature or data structures in nature if I have to, whereas stuff that's like interacting with third-party systems or other frameworks, I don't touch that. I'll just use a library for it.

Jonan: How often do you write your own encryption libraries?

William: I will never do that.

Jonan: Never, ever, ever. [laughs]

William: I will never do that, yeah. That's one of those things where it's like, the difficulty is such that even if I did do it, I don't know if I've done it well. I'm pretty sure that I can't make myself as fast as some of the other people. I've met some people who blow me away with the types of things that they can do. Typically, they're like mathematics PhDs, and I'm like, I can't. [laughs]

I try to avoid doing anything that's unreasonable, and I think writing your own security stuff is unreasonable. Why would you do that? We have standards. How are you going to ensure that your stuff is actually standards-compliant? Do you have testing for all that? There are a lot of things that go into it that I guess you don't see when you're making that decision of like, oh, I can just do this myself. You're probably not thinking about all the other things that these people have thought of that you probably will never think of until something goes wrong, and you don't know why.

Jonan: Yeah. And with encryption, this is someone who's spent a 30-year career focusing on specifically designing these algorithms or maybe one particular algorithm and all of the math and the theory that goes into creating that thing. There's no way you're going to catch up or make an improvement. I think encryption is an obvious target for people when they're trying to start out.

I also wanted to touch back on your point about versioning. You had said someone makes a patch update to their library, and it has a breaking change in it. This is really a question for me whether or not they're following semantic versioning or something similar if you don't want to use semantic versioning specifically. You have some strategy to let me know when upgrading to a new version of your library is going to break some critical interface that I'm probably using because you presented it as the public API for that product.

And then I'm suddenly in the position where I have to be an expert in your specific thing. Now I've got to go digging through all of the source code. And is the cost for me having to go and debug all of those potential changes in the future greater than the value that I'm getting from using your code in the first place? The answer is probably if you're not using a semantic versioning strategy, if you're not making it clear to your users when those breaking changes are coming, I'm very likely to become an expert in your product over and over again as I debug those problems. And evaluating those future costs in breaking changes is a really important part.

William: I think it's also important to keep in mind that even if someone is following semantic versioning, a human is still capable of making a mistake. So they can easily say, "Oh yeah, this is a patch update." And there is just one thing that changed, a minor thing that changed. And it slips people's attention like, I don't know. Maybe this is something that you don't think this way. But I have a trust issue with a lot of stuff now where it's like, yeah, they're saying this, but it's like, I see how software is written. I've been around. It's like, can I trust this? That kind of thing. Maybe we need trust metrics for [chuckles] repositories. Like, can you trust that they're doing what they say they're doing?

Jonan: How many times have they been wrong? So, if you were starting out again if you rolled back towards the beginning of your career…I think we've given a lot of advice for people who are in intermediate stages trying to progress into expert-level work. But give us one golden piece of advice you think people could apply early on in their career to guide their progress towards where you are now being in a position to teach so many people about these things. What would you wish that you had known starting out?

William: I knew this, and I'm just going to say something that I think other people should know (And when I say I knew it, someone else told me, and it came from my college.) which is don't focus on trends. Don't think that you need to learn all of these other things. Like, you know, let’s be concrete. Don't feel like you need to know JavaScript, and Python, and Ruby, and SQL, and the list goes on and on. Instead, learn one thing. And when I say learn, I don't mean what a lot of people learn where it's superficial. I mean, learn that thing because you may realize that learning that thing is very similar to all these other frameworks because they all operate on the same underlying platform, either Linux, Windows, or macOS.

So understand the system that you use every day. If you don't understand your system, like, you can understand all of this stuff, the higher level stuff all you want, but it runs your computer. If you don't understand your computer, then there's a strong limit or a hard limit of how much you're really going to be able to do. Typically, it's when things go wrong. It's not when things are going fine or whatever.

But there are times where things have gone wrong, and I had to lean on my understanding of the file system, underlying Unix file system and how everything is representing as a file, even sockets and just understanding that I can redirect output to certain places so I can actually understand what's going on. And like the HTTP protocol, if something was going on and I'm not getting the request, all right, let me try and debug this thing. Let me just follow the thing on the system to see if it's getting there and work my way up.

Jonan: Yeah. I got some really good advice from an engineer I worked with early, which was that every problem has a solution. And you can get from here to there with a finite number of discrete experiments. But the finite number of discrete part, the discrete experiments part, was the hardest for me to get early in my career. I was very likely to repeat debugging steps around the same area and lead myself into situations where I'm not confirming the basics, where I'm reloading the page and reloading the page, and nothing changes. And I'm pretty sure CSS is broken, and also JavaScript is probably fundamentally flawed. And then I realized that I'm looking at staging and not production or vice versa.

William: [chuckles]

Jonan: Or my test is running against the piece of code, or my test isn't running. It's so easy to get ahead of yourself and make those assumptions, which brings us full circle back around to making assumptions about what your audience knows and coming to a place where you think that you already know the solution that you're headed towards. Assume nothing. Start from the very beginning and build on top of it. Really good advice.

William: Yeah, and check your assumptions along the way. Like, it's fine to have them, but I prefer to call them hypotheses. So it's like, state what you expect is going to happen and then do the thing. And if the thing happens or not happens, document it. If it doesn't happen, well, now you need to understand why it didn't happen. Sometimes understanding why is more important than getting it to work. And that's something that I've noticed specifically in the more junior people; it's just like, oh, it just needs to work, and it's like, not really.

Sometimes let's say, for instance, you're debugging an issue, and it turned out to not be an issue. It's only sporadic, and then all of a sudden, it goes away. Well, you have some people who would be like, okay, it works. I'm going to move on to the next thing. And then you have people like me where it's just like, no, no, no, it's a problem if I don't understand this. I need to be able to trigger this bug myself and then get it to not happen again so that I can be like, okay, well, we've solved the problem rather than, I guess, assuming that it fixed itself because there is no magic in this. Like, there's no magic.

Jonan: That's a really good point. I'm taking that one. I'm going to have to listen to this episode a couple more times and make sure I capture all of your nuggets of wisdom. It has been a pleasure chatting with you today, Will. This was a great episode. Do you have any parting thoughts for people before we call it a show?

William: Well, yeah. If you are new to this (I'm defining new as you've been doing this for less than three years.), there's a lot to know. There's a lot to know. Chances are you're not going to know most of it. So get over the fact that you feel like you need to understand everything because, in reality, you don't. And in reality, us as humans, there's a reason why there's so many of us, and we have books, like hundreds of millions of books. You're not going to know everything.

So don't get too down if you feel like you're not understanding something. Maybe you don't need to understand it. Maybe you can understand something else that someone else doesn't understand, and that's the point of being on a team. If you can do the same thing that everyone else can do, well, that's a pretty shoddy team, in my opinion, because everyone can only do the same thing. So just keep that in mind. If you're new, don't feel like you need to know everything.

Jonan: There's a reason there are so many of us, and we have books, my favorite quote from the whole episode. Well done. Okay, you can look up Will online. Is @iAmWillShepherd your Twitter handle? Am I correct?

William: Yeah. I'm there, and on GitHub, and on Instagram, and pretty much everything else, although I'm not that active. If people want to DM me, I'll try to get active. Like, tell me what you want, and I might do it.

Jonan: I want all of this in a daily content stream. Get your tweets and your blog posts and all of that in line because you got a lot of brilliant advice to share with the developers of the world. Thank you so much for coming on the show, Will. I hope you have a wonderful day.

William: Same to you. Thank you.

Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.