Speaker 1: Right, Hello everybody, and welcome to another episode of Mind.
Speaker 1: I'm your host today, Calm Gazi, and I'm joined on
Speaker 1: the panelist by first time panelist Jack Hamison.
Speaker 2: Hey Carl, how are you doing.
Speaker 1: I'm fine, Good to have you, Good to have you, Yeah,
Speaker 1: great to be here. Awesome. And our guest today is
Speaker 1: Tyler Hawkins.
Speaker 3: How you doing? Thanks for having me.
Speaker 1: So, Thailer, let's just start off by maybe you're telling
Speaker 1: us a bit about yourself and obviously why you're famous.
Speaker 3: Sure, So, I'm Tyler Hawkins. I'm a senior software engineer
Speaker 3: at Adobe. I've been doing front end development for about
Speaker 3: seven years now and blogging and tech writing for the
Speaker 3: last year and a half. I don't know that I'm
Speaker 3: necessarily famous now, but I do enjoy blogging and writing
Speaker 3: and it's it's opened up some opportunities and giving me
Speaker 3: a chance to talk to people like you guys.
Speaker 1: Awesome. Great. So obviously I kind of made what stuff
Speaker 1: today's show would be your article on pink code and React.
Speaker 1: But I guess before we kind of go into that,
Speaker 1: and let's just maybe dump it deep into your background
Speaker 1: and to how you got into tech and how you
Speaker 1: got into your kind of job now and how I've
Speaker 1: been through yourself off.
Speaker 3: Sure, Yeah, so I have a bit of a non
Speaker 3: traditional tech background. I didn't have a degree in computer
Speaker 3: science or anything like that. For a long time. I
Speaker 3: was actually a psychology major. For about two and a
Speaker 3: half years. I was pretty intent on, you know, finishing
Speaker 3: up my bachelor's and going to get a master's or
Speaker 3: a PhD and doing some form of counseling. But about
Speaker 3: midway through that, i'd taken some statistics classes. Those are
Speaker 3: some required classes just when you talk about doing research
Speaker 3: and psychology, and I really enjoyed the statistics part of
Speaker 3: it and kind of the more hard science as opposed
Speaker 3: to the softer social science of psychology. So I started
Speaker 3: getting really into that, and then stats actually kind of
Speaker 3: traded a nice segue into coding and programming. Statisticians will
Speaker 3: often use programming languages like R or SaaS or even
Speaker 3: just SQL for managing data in a database, and so
Speaker 3: that was really where I first got introduced to coding.
Speaker 3: I just remember learning R and seeing how we could
Speaker 3: create you know, these simulations. It was just a few
Speaker 3: lines of code, it was super cool to me. Or
Speaker 3: you could write a few lines and generate this beautiful
Speaker 3: graph just out of literally just a few lines of codes.
Speaker 3: That was really exciting for me. So at that point
Speaker 3: I was almost I think I was. I think I
Speaker 3: was in my second semester of my junior year. So
Speaker 3: if I was to switch to computer science at that point,
Speaker 3: I would have had you know, probably three more years
Speaker 3: just to get my bachelor's degree. So figured I probably
Speaker 3: wouldn't do that, so I stuck it out with statistics.
Speaker 3: That's that's officially what my degree is in. But at
Speaker 3: the time I was, I was working part time at
Speaker 3: a tech company called qual Tricks. They were a software
Speaker 3: as a service company. When I was working just just
Speaker 3: doing tech support for them as a product specialist, so
Speaker 3: a lot of just troubleshooting and problem solving and whatnot.
Speaker 3: But that provided really nice and afterwards, you know, I
Speaker 3: told them I'm looking for a software engineering job, so
Speaker 3: it's just a question of can I do that here
Speaker 3: or do I need to go look elsewhere. So they
Speaker 3: offered me a job working on our professional services team,
Speaker 3: just doing custom one off work for clients, building neat
Speaker 3: little small projects. They were often you know, like a
Speaker 3: week or two projects at a time, so pretty small scale,
Speaker 3: but it was a good introduction to a lot of
Speaker 3: I guess, unique, unique problems to solve, and then from
Speaker 3: there if I've worked at a few other companies. I've
Speaker 3: worked at an e commerce company called Unique, a ed
Speaker 3: tech company called Instructure, Workfront that works as an operational
Speaker 3: system of record, and then Workfront was recently acquired by
Speaker 3: Adobe back in December of twenty twenty. So now here
Speaker 3: I am at Adobe.
Speaker 2: Wow. I love Adobe.
Speaker 4: I used to work in Macromedia before it became Adobe,
Speaker 4: and it's a fantastic company.
Speaker 2: Yeah, really great place to work.
Speaker 3: Yeah, they're a great place.
Speaker 2: So when did you start with React? Yeah?
Speaker 3: React was let's see early twenty seventeen, so it's been
Speaker 3: about four years now.
Speaker 2: Fantastic.
Speaker 4: Sort of looking into your article, I'm curious as to
Speaker 4: your take on typescript and how that might change this
Speaker 4: clean coding approach.
Speaker 3: Sure so, I think, I mean clean code applies regardless
Speaker 3: of whether you're writing typescript or just plain vanilla JavaScript.
Speaker 3: I've used typescript in past jobs. We're not using it
Speaker 3: right now, at least in the repos that I primarily
Speaker 3: work in. I know other places that the company are
Speaker 3: I don't know I still have mixed feelings on it.
Speaker 3: I enjoy the type safety. I enjoy that it's explicit
Speaker 3: about the data type and that it provides these static
Speaker 3: analysis and static type checking and error checking to prevent
Speaker 3: you from using unexpected data types. There is also a
Speaker 3: lot of complexity that stems from it, especially if the
Speaker 3: types aren't maintained properly. You might have like a complex
Speaker 3: type or maybe an object for lots of different properties,
Speaker 3: and then people start, you know, slowly how code goes,
Speaker 3: and it gets bigger and bigger until it becomes all
Speaker 3: the spaghetti code. Now you have these spaghetti types that
Speaker 3: people are trying to override and whatnot. So if you're
Speaker 3: getting use type script, I think you have to be very,
Speaker 3: very devoted to it and make sure it stays nice
Speaker 3: and maintained for sure.
Speaker 1: Yeah, I mean it's funny. I think, actually use your
Speaker 1: article and I'm looking at it. I was actually trying
Speaker 1: to at work, trying to set some kind of guidelines
Speaker 1: regarding Funtain development because when I joined initially the company,
Speaker 1: front of my grade from Angulo to React. So for
Speaker 1: the last two years been doing that and then we
Speaker 1: started working on a new project recently as well, so
Speaker 1: then I think, okay, in order first play, which you
Speaker 1: kind of move faster in the future, we have kind
Speaker 1: of a guideline for front end development and all the
Speaker 1: good stuff, and actually an article looking at it now.
Speaker 1: And one thing that I kind of struggled with per
Speaker 1: se is obviously, when it comes to clean code, it's
Speaker 1: very subjective, right, what is clean for you? For somebody
Speaker 1: or it is a mess? Right, So when you come
Speaker 1: to think about clean code, how do you kind of say,
Speaker 1: maybe you're kind of guidanizeding and your body is okay,
Speaker 1: even though what I've written for me is what is clean? However,
Speaker 1: are they principles you kind of use a wider and
Speaker 1: across the whole field are usable? Yeah?
Speaker 3: Absolutely. So that's a good point is that clean code
Speaker 3: is pretty subjective to me. I guess how it would define.
Speaker 3: Clean code is just code that's easy to read, it's
Speaker 3: simple to understand, it's neatly organized, and that really lends
Speaker 3: itself to making it easier for future developers to pick
Speaker 3: up on the code. You know, they can instantly dive
Speaker 3: into the code base and understand, and also makes it
Speaker 3: a lot easier to refactor or extend the code later.
Speaker 3: As you're you know, building out new functionality as the
Speaker 3: app evolves and grows. But you're right in doing that, Like,
Speaker 3: it's it's a pretty subjective principle, right, or subjective idea
Speaker 3: of okay, what what what makes clean and what's not?
Speaker 3: And so I think that's important to call out, right,
Speaker 3: especially like I've written this article of some things that
Speaker 3: I find helpful when writing React code, But it doesn't
Speaker 3: necessarily mean that you'll find it helpful. You might have
Speaker 3: very different, very strongly held opinions that contradict my own,
Speaker 3: and that's that might be okay, right, there might not
Speaker 3: be a right or wrong answer, But even with that, like,
Speaker 3: there definitely are still some generally accepted principles, not just
Speaker 3: in React, but across all programming languages, right, Like, it's
Speaker 3: pretty commonly accepted that we should use clear variable names
Speaker 3: instead of just naming your variable T, it should be
Speaker 3: you know, whatever time or whatever you're representing, right, Or
Speaker 3: rather than having a comment that says increment counter by one,
Speaker 3: let's just have our code be explicit and clear to
Speaker 3: write that, right. So there, there still are some generally
Speaker 3: accepted principles when it comes to writing clean code.
Speaker 1: Yeah, So with the article. What made you want to
Speaker 1: write then and actually publish it. I'm assuming there's something
Speaker 1: that happened to be in your in your own development
Speaker 1: that made you want to actually make this article, write
Speaker 1: it down, and then obviously share it because it's it's
Speaker 1: a big thing. I guess, kind of saying Okay, this
Speaker 1: is what I think is keen code, right, and then
Speaker 1: people read that and then discuss and say I agree,
Speaker 1: I don't agree, But what was the kind of beginnings
Speaker 1: of the article for you?
Speaker 2: Yeah?
Speaker 3: So I'm a big fan of reading, just like the
Speaker 3: classical tech programming books. So I have read Clean Code
Speaker 3: by Robert Martin Refactoring by Martin Fowler. Those are probably
Speaker 3: the two biggest ones just when it comes to clean
Speaker 3: Code and Refactory as their titles say, and rightly so
Speaker 3: like these books focus more on general principles that would
Speaker 3: apply to any programming language. I think the original Refactoring
Speaker 3: was written with Java examples, and then they recently released
Speaker 3: a second edition in I think it was like twenty nineteen,
Speaker 3: but that's been re updated to all be written in JavaScript,
Speaker 3: which is super nice for me as a front and developer.
Speaker 3: But so all of these principles that they've that they've
Speaker 3: outlined are more general programming sort of language agnostic principles. Right,
Speaker 3: they should be true regardless of whether your front end
Speaker 3: or back end or Python or C plus plus or whatever. Right,
Speaker 3: And so in thinking about that, I wanted to sort
Speaker 3: of get more specific of, Okay, we have these general principles,
Speaker 3: and now in my job, I'm primarily writing React, and
Speaker 3: so are hundreds of thousands of other developers, So how
Speaker 3: can we take these principles and make them even more specific?
Speaker 3: Of like, how do we how do we distill these
Speaker 3: into what makes React code clean for our very specific
Speaker 3: use case. So that was sort of the intent, And
Speaker 3: then the other part of it is like, there are
Speaker 3: you know, useful automated tools you can use, So things
Speaker 3: like es lend to establish best practices so that enforces
Speaker 3: the consistency. You can use tools like Prettier for formatting codes,
Speaker 3: so now you don't have to have arguments anymore of
Speaker 3: should we have semi colons or no semi colons, or
Speaker 3: trailing commas or no trailing commas. You can just pick
Speaker 3: one and have Prettier format it for you. So those
Speaker 3: are super helpful and essential tools. But then there's also
Speaker 3: still things that aren't necessarily enforceable, right, So like if
Speaker 3: you think about a clear variable name, like a tool
Speaker 3: like pretty or easlink can't tell you yes, that variable
Speaker 3: name makes sense to a human, Right, that's more subjective
Speaker 3: and it's where people get involved. And so that's kind
Speaker 3: of where my article is more focusing is not the
Speaker 3: syntactical differences, but more just what makes this understandable for
Speaker 3: a human.
Speaker 4: So when I'm looking at your code, it's interesting to
Speaker 4: see you're creating these closures inside the component. Have you
Speaker 4: looked at things like use callback and use memo and
Speaker 4: what's your take on those?
Speaker 3: Yeah, so use callback and use memos, So those are
Speaker 3: really handy REACT hooks, right, So working with function components,
Speaker 3: and they're both essentially memoization techniques, right, so where you
Speaker 3: can take some value that's expensive to compute and memorize
Speaker 3: it so that you're not constantly recalculating that, and so
Speaker 3: those can come in handy when you are realizing that
Speaker 3: you've had that you've that you're having performance issues. Pretty
Speaker 3: commonly accepted ideas that you don't want to prematurely optimize
Speaker 3: your application, right, And so for the most part, I
Speaker 3: tend to avoid use callback and use memo until I
Speaker 3: recognize that it might be a problem because there's an
Speaker 3: overhead to that, right when you when you memoize something
Speaker 3: and you have this cash that's created, that does take
Speaker 3: some overhead. And so if you're trying to memorize everything,
Speaker 3: you actually will have worse performance than if you hadn't, right,
Speaker 3: So there's a fine line to draw. And so yeah,
Speaker 3: that typically the advice is just don't until you realize, like, hey,
Speaker 3: this is behaving pretty slowly, then let's go figureze figure
Speaker 3: out what we need to go memorize.
Speaker 1: Sure, yeah, and also I'm looking at your result. One
Speaker 1: thing I actually stop do now was actually before I
Speaker 1: used to use a lot of kind of effect and
Speaker 1: for example operator and instead of using a ternary. And
Speaker 1: I think I also do an article by Kensey Dodds
Speaker 1: about the same thing saying that actually it's better to
Speaker 1: have the ternary as opposed to sometimes this kind of operator.
Speaker 1: So I think it's good because for me, my philosophy
Speaker 1: has always been underpinned by I read this comment in
Speaker 1: a book by Kyle Simpson, which was the U Don't
Speaker 1: Know JS series, and he said that developers write code
Speaker 1: for developers, not for the computer. So your your code
Speaker 1: read by add yourself in tomorrow or in a few
Speaker 1: months time, in a year's time, or your colleagues. So therefore,
Speaker 1: always try to write code that makes it easier for
Speaker 1: you in the future or your code has come in,
Speaker 1: look at it, understand it, and actually get it working.
Speaker 1: And it's something I actually seen when I was looking
Speaker 1: at the source code for React, for example, I came
Speaker 1: across that they use variable names are very explicit and
Speaker 1: quite long, right, which for me looks quite odd, but
Speaker 1: actually it helps you actually make sense of what's happening
Speaker 1: because even though the name for the vailable might be
Speaker 1: quite long and explicit, actually it makes it easy to
Speaker 1: work out to getting on. So I think on that front, definitely,
Speaker 1: that's how I can approach my clean code and try
Speaker 1: to wrap my code in that way where I'm trying
Speaker 1: to say, Okay, I want to communicate to my colleagues
Speaker 1: my intention, or maybe try to make it clear that
Speaker 1: I'm trying to do the X, Y and Z and
Speaker 1: all at comments when I'm doing something, which maybe is
Speaker 1: not the best practice, but because in this particular example,
Speaker 1: it's the best way and actually works. So that's how
Speaker 1: I approached it. I don't know if you've also had
Speaker 1: a similar kind of viewprint and how you do your
Speaker 1: code as well.
Speaker 2: Yeah.
Speaker 3: Absolutely. I can't remember who said it. I want to
Speaker 3: say it was like ken Beck, but it's somewhere along
Speaker 3: the lines of anyone can write code a computer can understand.
Speaker 3: It's a lot more difficult to write code a human
Speaker 3: can understand. Right. And then another really important principle is
Speaker 3: that code is read a lot more often than it
Speaker 3: is written. You know, like in my day to day
Speaker 3: job as a software engineer, I will spend a lot
Speaker 3: of time doing code reviews prior to merging code. I'll
Speaker 3: spend time reading through the code base as I'm trying
Speaker 3: to you know, troubleshoot or debug some issue that I'm
Speaker 3: working on right that someone may have written eight months ago.
Speaker 3: You may spend your time in meetings, and so if
Speaker 3: you look at like how often you actually spend time
Speaker 3: writing code, like, it's probably like ten to twenty percent
Speaker 3: of my day is actually writing code versus reading code
Speaker 3: or discussing, right. So yeah, I mean there's a lot
Speaker 3: of value in writing this clean code and making it understandable.
Speaker 3: Because that's a majority of your time and your codeker's time. Yeah.
Speaker 2: Also looking through your code, it's interesting.
Speaker 4: I'm looking at the undefined props one and where you
Speaker 4: are sending in a handle click and it it's interesting.
Speaker 4: Have you looked at the optional chaining operator question mark
Speaker 4: dot and just come out, well, I guess last couple
Speaker 4: of years I have.
Speaker 3: Yeah, the optional chaining that was in the Yes twenty
Speaker 3: twenty release.
Speaker 4: Well, yeah, I think that could actually be a lot
Speaker 4: easier here. You know, we basically just question mark dot
Speaker 4: on the invocation of handle click and there you go.
Speaker 2: It's if it's there, it works. If it doesn't, it doesn't.
Speaker 3: Yeah, the optional chaining is great when it comes to
Speaker 3: ye being uncertain of whether a certain property or method
Speaker 3: exists on an object.
Speaker 4: Absolutely, it definitely helps, like, as you say, like clean
Speaker 4: out with the code so that you know, if you
Speaker 4: have like a deeply nested thing in a structure, you know,
Speaker 4: data dot first name or data dot name dot first
Speaker 4: or something like that, you can easily just say, Okay,
Speaker 4: if it's there, then it's this, and if it's not,
Speaker 4: then you can back off and get to whatever your
Speaker 4: default value is. And it definitely pairs it down from
Speaker 4: those nasty, nested ifs we have to used to have to.
Speaker 1: Do absolutely so with clean code. What impact have you
Speaker 1: seen in your work person or maybe in your teams
Speaker 1: when you've tried to actually use these principles if we see,
Speaker 1: let's say, an improvement and probability as the code become
Speaker 1: much eier to work with over time, What have you
Speaker 1: seen impact wise from what you've actually be sharing in
Speaker 1: your audible?
Speaker 3: Yeah, absolutely so, there has been a lot of benefits
Speaker 3: as far as like even just discussing these things, right, So,
Speaker 3: like if we were to go through this and do
Speaker 3: like a team training or something, right and just just
Speaker 3: having a shared understanding of certain principles or styling conventions
Speaker 3: that we agree on, I think is huge, right because
Speaker 3: now we're all using the same language, we're using the
Speaker 3: same terms, we're writing code, and hopefully mostly the same way, right,
Speaker 3: And so that makes it very easy for it to
Speaker 3: transfer from one person to another. You know, if I'm
Speaker 3: reviewing your code, I don't have to get used to
Speaker 3: your style and then I have to get used to
Speaker 3: Jack styles or review his code. Right, We're all we're
Speaker 3: all kind of writing the same way, So there's a
Speaker 3: lot of value in that. And then even just like
Speaker 3: trying to pick us specific principle and focus on it
Speaker 3: for however long, a few weeks or a month, whatever,
Speaker 3: we've seen a lot of value in that. So, for instance,
Speaker 3: this isn't one actually I think it is mentioned at
Speaker 3: the bottom of the article. But just like extracting logic
Speaker 3: out into a clearly named function, you might have like
Speaker 3: I don't know, I'm trying to think of a good example,
Speaker 3: but basically just a whole bunch of conditions. Right, so
Speaker 3: you might say, like if condition one and condition two
Speaker 3: and condition three or condition four or five, then do
Speaker 3: this thing. And it's like it may be clear to
Speaker 3: the developer when they're writing it of like why I'm
Speaker 3: writing this if statement, but at some point, like the
Speaker 3: intent of that can be it can be misunderstood or misinterpreted. Right,
Speaker 3: maybe that's not well documented, that's lost. And so there's
Speaker 3: a ton of value just like it's extracting that condition
Speaker 3: out into a function or into a variable that says
Speaker 3: like this is check for user or whatever, right like
Speaker 3: this is why I am doing all these conditions in
Speaker 3: this if statement. Anyway, So that was that was just
Speaker 3: a simple example of something we had focused on of Okay,
Speaker 3: let's let's start extracting this code into functions. And as
Speaker 3: we do that, like the code becomes a lot more
Speaker 3: I guess self documenting and a lot more easy to understand, right,
Speaker 3: because now you've got this code extracted out, and so
Speaker 3: now you basically just have high level steps of like okay,
Speaker 3: I'm going to check if the user is logged in,
Speaker 3: then I'm going to fetch their user data, avatar or whatever. Right,
Speaker 3: so you have these very clear steps. That's almost like,
Speaker 3: I mean, it's not pseudocode, but it's it's a lot
Speaker 3: more human readable to just read, like here these three
Speaker 3: functions that are being executed, as opposed to digging through
Speaker 3: one hundred lines of code of you know, this is
Speaker 3: what's actually going on underneath the hood.
Speaker 4: So, building on Carl's questions, so when you are going
Speaker 4: through these with your team, you know these principles, how
Speaker 4: do you find decide when you say, okay, this is
Speaker 4: this one's really important? You know, somebody pushed it back
Speaker 4: They're like I wouldn't do it that way, I would
Speaker 4: do it this way, or something like that. How do
Speaker 4: you decide, Okay, this is a really important one. This
Speaker 4: is the one I'm you know, willing to go to
Speaker 4: town on, you know, versus we can agree to disagree
Speaker 4: on that. How do you make that? How do you
Speaker 4: weigh those choices?
Speaker 3: Yeah, it's a good question because software engineers in general,
Speaker 3: I feel like we're pretty pedantic people and we like, no,
Speaker 3: we have made strongly held opinions about things that really
Speaker 3: don't matter.
Speaker 2: Right.
Speaker 3: No, it sounds like this is ringing a bell. Yeah,
Speaker 3: but honestly, like when it comes to that kind of stuff,
Speaker 3: like I feel like it's I mean, it doesn't have
Speaker 3: to be complicated. You can have a discussion of Okay,
Speaker 3: I like it, I like writing it this way, you
Speaker 3: like writing it that way. We can talk about if
Speaker 3: there actually is a value or a benefit to doing
Speaker 3: one over the other. If there is, right, like, hopefully
Speaker 3: you can have a discussion and show like, Okay, this
Speaker 3: is clearly better, it provides whatever better performance or you know,
Speaker 3: whatever it is, right like, this is objectively better. And
Speaker 3: if it's not, if it's a question of do you
Speaker 3: like semi colons or no semi colons and javascripts like
Speaker 3: to me, it doesn't matter, Like, let's just pick one
Speaker 3: and We'll go with it because really, probably what's more
Speaker 3: important than the standards that you do pick is just
Speaker 3: that you have a standard and that you enforce it.
Speaker 3: And that comes back to just like the s lent
Speaker 3: and Prettier tools, right, you can configure those, So just
Speaker 3: pick a standard and go with it. It honestly doesn't matter.
Speaker 3: Just be consistent.
Speaker 4: Yeah, I couldn't agree more honestly when people ask me,
Speaker 4: what's your favorite lnting standards? Like whatever is in the
Speaker 4: es lend r C and is managed by Prettier and
Speaker 4: does it when I hit save, That's where I'm at.
Speaker 2: You know. So if you want to do Sammy Colins,
Speaker 2: you do you well, whichever.
Speaker 5: Hey, folks, if you love this podcast and would like
Speaker 5: to support the show, or if you wish you could
Speaker 5: listen without the sponsorship messages, then you're in luck. We're
Speaker 5: setting up new premium podcast feeds where you can get
Speaker 5: all of the episodes released after Christmas twenty twenty without
Speaker 5: the ads. Signing up will help us pay for editing
Speaker 5: and production, and you can go sign up dot tv
Speaker 5: slash Premium.
Speaker 1: Yeah, so on that with React. In your opinion, Tyler,
Speaker 1: do you think there are things about React that make
Speaker 1: it harder to write clean code or easier. For example,
Speaker 1: I know that in my experience, one of the issues
Speaker 1: that I come across or people say to me, is okay,
Speaker 1: because it's so flexible, right, I can do one thing
Speaker 1: ten different ways, So that I guess makes it harder
Speaker 1: to have a clean code because I could maybe spend
Speaker 1: time working on this particular stutuf or programming in rects.
Speaker 1: I dream and then you're working on this startup programming
Speaker 1: and reacting kind of clashing. But I mean, for movie point,
Speaker 1: are there things that make it harder in React? We've
Speaker 1: in code and things that make it easier code.
Speaker 3: Sure, that's a good question. I don't know if I
Speaker 3: would say that it makes it harder to write clean code,
Speaker 3: but I do get where you're coming from, right, is
Speaker 3: like React is somewhat unopinionated, Like if you were to look,
Speaker 3: you know, maybe the differences between React and Angular, Like
Speaker 3: React is presented as a UI library, whereas Angular is
Speaker 3: presented as a UI framework, right, and so Angler is
Speaker 3: very opinionated as to this is the Angular router that
Speaker 3: we use, and this is the Angular animation library that
Speaker 3: we use. Right, But with React, we don't have that
Speaker 3: at all. We have to choose between what state management
Speaker 3: system are you going to use? Is it going to
Speaker 3: be the context API or redex or something else. You know,
Speaker 3: what are you going to use? Yep, yeah, those are
Speaker 3: the big ones. What are you going to use for
Speaker 3: CSS stuff? Is it going to be the emotion or
Speaker 3: CSS modules or tailwinds. So there are tons of different
Speaker 3: opinions or options out there, I should say. And so
Speaker 3: I mean that's almost a different discussion to me is like,
Speaker 3: you know, how do you how do you choose the
Speaker 3: right tool? How do you make decisions as an organization?
Speaker 3: But regardless of what tool you choose, like, I think
Speaker 3: you can still write code in a clean way, you know,
Speaker 3: regardless of what solution that you're using.
Speaker 1: Yeah, it's fine for me. I actually find the fact
Speaker 1: that reacts is flexible actually kind of makes it easier
Speaker 1: because you know, you're not having to follow a path, right,
Speaker 1: let's say that angler or whatever. You're able to adapt
Speaker 1: to maybe what the team likes the best, what the
Speaker 1: skill set is in the team. And I mean that's
Speaker 1: for me anyway, Maybe other people that prefer to be
Speaker 1: handheld and be total Okay, this is this is the
Speaker 1: way to do it. In other way, it's wrong, But
Speaker 1: personally I like that about React that I don't have
Speaker 1: to always follow a path. I can kind of work
Speaker 1: my way there, and I can then kind of learn
Speaker 1: from other people's ways as well. So yeah, that's kind
Speaker 1: of how well approached it really.
Speaker 3: Yeah, absolutely, I would agree. I think it's fun to
Speaker 3: be able to kind of pick and choose, especially if
Speaker 3: maybe there's one solution that works best for your particular application.
Speaker 3: Like I'm just thinking of, like going back to reducts
Speaker 3: and middle, where you might use something like reducts THUNK
Speaker 3: that's honestly therey simple middle where it's it's like literally
Speaker 3: like thirteen lines of code this is the whole average,
Speaker 3: or you might have something like reduc SAGA, which is
Speaker 3: far more complex but far more powerful, and so yeah,
Speaker 3: then it kind of comes down to of like, Okay,
Speaker 3: we do have whatever these very convoluted actions and effects
Speaker 3: that we need reduct SAGA to handle versus our actions
Speaker 3: and reducts setup is fairly simple and FUNK serves their needs.
Speaker 3: So yeah, I think that flexibility is great, being able
Speaker 3: to choose the right tool for the job. The hard
Speaker 3: part is making that decision of what is the right tool, right.
Speaker 1: So yeah, yeah, so I think this is a good
Speaker 1: point you segue into your article on clean code of tests.
Speaker 1: So I think we've covered like the clean coding of
Speaker 1: reaction for for a bit. So when it comes to tests,
Speaker 1: how are these same princeps applied to testing to make
Speaker 1: your code again cleaner, readable, and better to work with
Speaker 1: you and your colleagues.
Speaker 3: Yeah, so with clean code with tests. So this was, yeah,
Speaker 3: a different article I'd written, and this one focuses a
Speaker 3: lot more on not so much in just making code
Speaker 3: pretty or coming to a certain standard, but more as
Speaker 3: far as like how you actually organize your code. So
Speaker 3: there are a lot of really important principles in there,
Speaker 3: so like, for example, structuring your test like it's pretty
Speaker 3: common to structure them and like this arrange act assert
Speaker 3: sort of set of groupings right where you first set
Speaker 3: up your test fixtures and then you actually act on it,
Speaker 3: perform some operation, and then you assert that the expected
Speaker 3: behavior occurred. So I mean that's huge just as far
Speaker 3: as like writing very clear sections of your test. There
Speaker 3: are a lot of other principles as well, so things
Speaker 3: like using test object builders, so that helps you know
Speaker 3: reduce the amount of duplication in your code, kind of
Speaker 3: keeping things dry there. And test builders if you or
Speaker 3: listeners aren't aren't sure what they are. They're essentially methods
Speaker 3: that can be used to build commonly used objects. So,
Speaker 3: for example, if you have like a user object or
Speaker 3: a whatever, any sort of common object working with, rather
Speaker 3: than creating a new user every single time and having
Speaker 3: like twenty lines of setup code in each of your tests,
Speaker 3: you can define define these helper functions where you can
Speaker 3: essentially just create a new user with either using some
Speaker 3: default values or some overrides that you provide. So it
Speaker 3: really helps make it more maintainable, so that you can
Speaker 3: just create a new user in one line of code,
Speaker 3: as opposed to know, however many lines that uses to
Speaker 3: actually generate that object. I don't know how much more
Speaker 3: you want to go into. We've got We've got all
Speaker 3: sorts of things we could talk about with tests.
Speaker 4: I do love that first acronym that you have in there,
Speaker 4: so that the test should be fast, independent, repeatable, self validating,
Speaker 4: and timely. Could you talk to me a little bit
Speaker 4: about self validating and timely on that?
Speaker 2: Yeah?
Speaker 3: So, yeah, the whole, the whole acronym first, so fast independent, repeatable,
Speaker 3: self validating timely. That comes from I think that one's
Speaker 3: from Uncle Bob in Clean Code. He's got a chapter
Speaker 3: on unit tests. But so when it comes to test
Speaker 3: being self validating, it's very important that tests either return
Speaker 3: as passing or failing, as opposed to just returning a
Speaker 3: message saying like here was the test output. You know
Speaker 3: your your function returned ten, You're exactly and so like
Speaker 3: in the React world, that's one of you know, the
Speaker 3: big complaints of snapshot tests when you are testing your components. Yeah, everyone,
Speaker 3: everyone hates snapshot tests, right, But that's that's one of
Speaker 3: the problems of them is that snapshot tests are not
Speaker 3: self validating. They just tell you that something changed, and
Speaker 3: now it's up to the human to verify of, Okay,
Speaker 3: was this a correct change because I've changed something the
Speaker 3: source code and therefore my snapshot test updated, or is
Speaker 3: this an unwanted change? Did I accidentally modify something that
Speaker 3: I didn't mean to? And so again it's it's not
Speaker 3: self validating. The human has to provide some sort of
Speaker 3: judgment there and often what happens then, I'm sure you know,
Speaker 3: is with snapshots is that the developer just says, yes,
Speaker 3: update and.
Speaker 1: Except to the changes.
Speaker 3: Right now, we've updated our snapshots and we haven't really
Speaker 3: validated at all, and so that's huge. And for the
Speaker 3: most part, I mean, test frameworks today are self validating, right.
Speaker 3: You write a test, either passes or fails, and it
Speaker 3: reports your test successes or error. So that's mostly taken
Speaker 3: care of. But that's a hugely important principle that I
Speaker 3: think we might take for granted. And then your other
Speaker 3: questions you asked about writing tests and timely manner. Yeah,
Speaker 3: and so this is a big one, just as far
Speaker 3: as like I think writing code responsibly. So to me, like,
Speaker 3: you shouldn't be writing any sort of code really, whether
Speaker 3: it's a feature or a bug fix or whatever, without
Speaker 3: unit tests, right, or tests of some sort, right, whether
Speaker 3: it's integration tests or end end or whatever. You need
Speaker 3: to adequately test it because when you write the tests
Speaker 3: alongside your production code, you have a better understanding of
Speaker 3: how the test should function, or sorry, how the code
Speaker 3: should function.
Speaker 2: Right.
Speaker 3: You have the product requirements. If you're working on some
Speaker 3: new feature, you've probably talked to the product owner and
Speaker 3: the UX designer and you know the requirements and so
Speaker 3: it's up to you to write the test to say, hey,
Speaker 3: this is how this feature should work, and this is
Speaker 3: the expected behavior. And the opposite of that if you
Speaker 3: don't do that is let's say you've written your code
Speaker 3: and there are no tests. I'm sure we've all worked
Speaker 3: places where testing was not a priority at the company,
Speaker 3: and so now we have this massive monolith here of code,
Speaker 3: and people are afraid to make changes to maybe core
Speaker 3: parts of the application. You've got your authentication code, or
Speaker 3: maybe your e commerce company, so you've got your actual
Speaker 3: checkout and order processing code, and people are terrified to
Speaker 3: touch it to make any change because they're afraid that
Speaker 3: they'll break it. And now users can't log in or
Speaker 3: they can't complete purchases, and they're costing the company tons
Speaker 3: of money. And it's all because there are no tests there, right.
Speaker 3: The tests provide that confidence for you to be able
Speaker 3: to change your app and to refactor it and add
Speaker 3: new things in the future, because then if the tests
Speaker 3: are actually in place, they'll tell you when you've broken
Speaker 3: some thing. And so as we're trying to play catch
Speaker 3: up them. Let's say we're in that scenario where we
Speaker 3: don't have tests, and now we're trying to increase the
Speaker 3: code coverage and make our application a little bit better. Now,
Speaker 3: we might be missing some of those product requirements, right.
Speaker 3: We might have a general idea of what the main
Speaker 3: functionality of the code is supposed to be doing, but
Speaker 3: we missed the nuance of all the product requirements and
Speaker 3: all the discussions that were had when that code was
Speaker 3: initially being written. And so when that happens, you'll have
Speaker 3: you know, missed edge cases or just maybe a misunderstanding
Speaker 3: as far as the expected behavior.
Speaker 2: Yeah.
Speaker 4: Absolutely, I mean we mentioned the dreaded snapshot test, and
Speaker 4: those tend for me to come in when I'm adding
Speaker 4: unit tests to older code. And the me that was
Speaker 4: me three weeks ago that wrote that code decided not
Speaker 4: to write the test or whatever.
Speaker 2: I'm like, I'll just snapshot it. It'll be fine.
Speaker 4: But yeah, when it's timely, right, you say, Okay, the
Speaker 4: really important part here is the total when it's when
Speaker 4: you're trying to check out or whatever, and so you
Speaker 4: know you want to make a test that's specific to
Speaker 4: making sure that the total is right and not that
Speaker 4: like the entire component stack is exactly what you expected,
Speaker 4: which is what you're going to get from a snapshot.
Speaker 4: And that's why when you do those auto updates, it's
Speaker 4: like maybe maybe the total change and that was the
Speaker 4: bad thing, or maybe it was just some class name
Speaker 4: and it's you can't really tell the difference unless you
Speaker 4: really drill down and do it, look at the gift
Speaker 4: to get this and all that. So I totally get
Speaker 4: why those two things are super important, and they kind
Speaker 4: of work.
Speaker 2: Across each other.
Speaker 4: It's like, yeah, you gotta get the right test and
Speaker 4: also write it right then because when you have it
Speaker 4: in mind, that's important.
Speaker 3: Absolutely.
Speaker 1: Yeah, And I guess also on testing, I'm looking at
Speaker 1: some root put number six, which is about edge cases
Speaker 1: and boundaries, and I feel that we sometimes either either
Speaker 1: either go to extreme and we develop edge cases too much, right, oh,
Speaker 1: we just forget about the motrone. And I think that
Speaker 1: reminded that. Yes, actually always try to think if I
Speaker 1: was like, how can I break my code right, or
Speaker 1: how can I break this feature and test that kind
Speaker 1: of edge case where if that happens, if the stars aligning,
Speaker 1: if it's on a windy day, if the moon is up,
Speaker 1: then this gonna happen. So yeah, that's a good point.
Speaker 1: So I guess A question which kind of ties pieces together?
Speaker 1: Is Okay? So let's say I've heard your argument and
Speaker 1: I say, okay, okay, I agree with you. Clean code
Speaker 1: is a way to go. I like your tips, I
Speaker 1: like your testing tips. However, one, how can I make
Speaker 1: this a day to day part of my workflow?
Speaker 2: Number one?
Speaker 1: And crucially, how can I then introduce into my team?
Speaker 2: Right?
Speaker 1: Because obviously this is a new worth working and it
Speaker 1: requires us to change our mentality our workflow, but we
Speaker 1: see that benefit. However, how do you get from the
Speaker 1: theory in your articles to actually be the practical day
Speaker 1: to day coding for it?
Speaker 2: Yeah?
Speaker 3: So basically, how do we take these principles and start
Speaker 3: implementing them if we're a team that hasn't in the past, right?
Speaker 1: Yeah?
Speaker 3: Yeah, So I think code reviews are a very crucial
Speaker 3: part of this process and being diligent in code reviews.
Speaker 3: So if let's say your company was not as serious
Speaker 3: about tests and now now they are they want to
Speaker 3: write tests and increase the code coverage and whatnot, we
Speaker 3: need to actually put our money where our mouth is
Speaker 3: and make sure we do those things right. And so
Speaker 3: if you let's say I'm reviewing your code and you've
Speaker 3: checked in code and you haven't written tests. The responsibilities
Speaker 3: on me then, as the reviewer, to say, hey, the
Speaker 3: code looks good, but I can't approve this until you
Speaker 3: write tests, right, And so that's sort of the human
Speaker 3: gate check or gatekeeper right there of doing that, And
Speaker 3: so that requires all of us to have this shared understanding. Right,
Speaker 3: it doesn't work if Jack is over here and he'll
Speaker 3: prodge your code no matter what. So you're just going
Speaker 3: to send all the mrs to Jack. And so it
Speaker 3: sort of requires kind of that team effort, right, so
Speaker 3: we have this shared understanding that yes, this is what
Speaker 3: we do. We have tests. Another thing that I've found
Speaker 3: very helpful when it comes to code reviews is just
Speaker 3: using like merge request templates or pull request templates, depending
Speaker 3: if you're a get hub or get lab user. But
Speaker 3: so those templates are essentially a checklist, right of Typically
Speaker 3: when I create a merged request template for a repot,
Speaker 3: would have something like, what's the description of what you're changing?
Speaker 3: You know, so give me a one or two line
Speaker 3: summary of what this is all about, maybe a quick
Speaker 3: test plan of how someone could verify that this is
Speaker 3: working if they wanted to go manually check it out,
Speaker 3: and then there might be a checklist as well of
Speaker 3: like literally, just have you written unit tests? Have you
Speaker 3: cross browser tested this? You know if you support I
Speaker 3: E eleven or whatever? Right, have you made sure user
Speaker 3: facing text is translated if you support different languages, or
Speaker 3: have you you know, made sure that your your code
Speaker 3: is accessible for screen reader users keyboard navigation. So just
Speaker 3: having that checklist in place provides just a little nudge
Speaker 3: and a little reminder of like, okay, I've checked in
Speaker 3: my code. Now I go through this checklist like oh okay,
Speaker 3: I didn't write test. Let me go back and take
Speaker 3: care of that. Anyway, those are two small things I
Speaker 3: think could help a lot.
Speaker 4: Have you thought about rolling this out at Adobe? And
Speaker 4: how would you think about doing that? Somebody's really big
Speaker 4: like Adobe.
Speaker 3: Yeah, so that's that's a tough question when it comes
Speaker 3: to Adobe specifically, because you know, Adobe has acquired a
Speaker 3: lot of different companies, right, They're made up of tons
Speaker 3: and tons of different technologies and platforms and whatnot. And
Speaker 3: so even though I'm working at Adobe, I'm still largely
Speaker 3: working within like the Workfront application that's now part of
Speaker 3: the Adobe Cloud, right, And so oftentimes the different applications
Speaker 3: or different product teams will operate pretty independently, right, so
Speaker 3: we might have different standards of different things, but we
Speaker 3: actually are rolling this out when it comes to work fronts.
Speaker 3: Is we've got these merger request templates in here, right,
Speaker 3: and you know, at least in the teams I've worked
Speaker 3: on were very strict and saying, okay, this the MR
Speaker 3: does need to have tests included. So yeah, we've got
Speaker 3: we've got a little bit of a success story there
Speaker 3: that we've we've rolled this out and it's working well
Speaker 3: so far. So things are Things are good?
Speaker 2: Cool.
Speaker 4: Did you build a kind of internal community around advocating
Speaker 4: for that and trying to get that done like within
Speaker 4: your team?
Speaker 3: Sure? Yeah, So, I mean we have you know, team
Speaker 3: trainings that we do, We have lunch and learns that
Speaker 3: we will do as well. So you know, we've we've
Speaker 3: presented this at a luncheon learn and then gone through
Speaker 3: and added these merger request templates to different repos So, yeah,
Speaker 3: it was it was a good a good number of
Speaker 3: or a good combination of just you know, having these
Speaker 3: p s as and these trainings and announcements as well
Speaker 3: as you know a group of people that will go
Speaker 3: in and do those things and actually enforce enforce those
Speaker 3: rules and principles. Awesome.
Speaker 1: So in actually, so, at what stage in your career
Speaker 1: did this become important to you? Would would you say
Speaker 1: it was when you were when you becoming a mid
Speaker 1: to senior or jus mid. At what stage did you say, Okay,
Speaker 1: you know what, actually clean code is actually something for
Speaker 1: me now which is very important as opposed to I
Speaker 1: know it's good, but it's not that important to me
Speaker 1: at the moment.
Speaker 3: Yeah, that's a good question. Probably in the more yeah,
Speaker 3: mid level range, I would say, I guess I'm starting
Speaker 3: to start to care more about the clean code honestly,
Speaker 3: as as a junior engineer, you know, at least for me,
Speaker 3: like I'm I'm just trying to get my work done,
Speaker 3: you know, like I'm early in I'm early in the
Speaker 3: or new in the field and early in my career,
Speaker 3: and you know, maybe I'm struggling to even do whatever
Speaker 3: task is asked with me, right. And so I I
Speaker 3: get this task done, I have this feature working, and
Speaker 3: I go check in the code right. And that's a
Speaker 3: mistake that a lot of us make, you know, whether
Speaker 3: we're junior, mid or senior or whatever is that we
Speaker 3: get the code working and then we stop, right. But
Speaker 3: that's that's like just the first tap, right, So we
Speaker 3: should first get the code working and then we should,
Speaker 3: you know, make sure it's it's nice and clean, so
Speaker 3: we could do whatever factoring we need. Maybe we've written
Speaker 3: tests already because we're doing TVD, or maybe we're going
Speaker 3: to write test now after the fact, and then after that,
Speaker 3: maybe we do performance testing and make it more performance right.
Speaker 3: So I'm trying to remember who said this. I think
Speaker 3: it was Kent back again, but it's like make it
Speaker 3: what does it, make it work, make it right, make
Speaker 3: it fast, something like that. Anyway, So just like not
Speaker 3: stopping right in that process. And sorry, I feel like
Speaker 3: I'm going off on a tangent here from your original question.
Speaker 1: Yeah, because I'm It's something I find myself thinking about
Speaker 1: a lot more. Is when I started off a key,
Speaker 1: I also have a nontep backgun, right. So I came
Speaker 1: from journalism and learned how to program, got pot my
Speaker 1: first job, and I was just Okay, I have to
Speaker 1: get this working. I have to understand how that I
Speaker 1: have to work out what you're doing in the first place, right,
Speaker 1: And it works, I'm happy and move on. And then now,
Speaker 1: as I've been in the field for for years now,
Speaker 1: I'm now going to think more about, Okay, what can
Speaker 1: I do to make the team better or to make
Speaker 1: the team perform better? Right, And it's these things like
Speaker 1: clean code, which are not very easy to measure, right,
Speaker 1: you can measure how clean code maybe helps the team,
Speaker 1: but it's intangible, and you know it's there because you
Speaker 1: then see over time that the code bases become cleaner
Speaker 1: to work on. It's easy to write, to write bog fixes,
Speaker 1: to write features because a new different company jump in
Speaker 1: and then a short amount of time kind of get upscratched.
Speaker 1: So yeah, I think it's one of those things where
Speaker 1: it takes time to actually begin to appreciate just the
Speaker 1: impact having clean code can do on your team, your
Speaker 1: company and you you as a deb as well. And
Speaker 1: I think, yeah, it's a thing where I think you
Speaker 1: need to make I think you need to have made
Speaker 1: these mistakes before and listen code which is a mess, right,
Speaker 1: and then trying to go back and unpick it. It's okay, now,
Speaker 1: I see why my clean code is is needed as
Speaker 1: opposed to trying to jump into it.
Speaker 3: Yeah, absolutely, Like that experience is pretty key, right, like
Speaker 3: having worked at places just going back to testing again,
Speaker 3: like having worked at places that don't have tests versus
Speaker 3: places that have very good test coverage and a good principle.
Speaker 3: Like there's a huge difference, right of you know, having
Speaker 3: actually been in that situation of Okay, I need to
Speaker 3: go modify or authentication code, Like okay, cross my fingers,
Speaker 3: I'm going to go merge this, like I help it
Speaker 3: works right as opposed to my tests are passing, I
Speaker 3: feel good about this, let's submit the code. So like
Speaker 3: just having been there and having experienced that like helps
Speaker 3: a ton of Like, man, there's a huge difference just
Speaker 3: in my developer experience, and that you know, makes a
Speaker 3: difference for all of the engineers that are working at
Speaker 3: the company too.
Speaker 2: Yeah.
Speaker 4: Yeah, I think there's a lot of folks who are
Speaker 4: looking for a path to go from like junior to
Speaker 4: senior or the team lead up that line, and one
Speaker 4: of the things that I think is really important is
Speaker 4: having a care about the code quality and putting in
Speaker 4: that time and up leveling the rest of the team.
Speaker 3: Yeah. Absolutely, I mean I know that's specifically something you
Speaker 3: that a lot of companies look for in it more
Speaker 3: of a senior engineer type role is not just are
Speaker 3: you an efficient individual contributor, but can you help make
Speaker 3: other people better as well?
Speaker 2: Right?
Speaker 3: Can you mentionor those people with less experience, can you
Speaker 3: help them also have that same appreciation, right, that same
Speaker 3: appreciation for clean code and for testing and taking pride
Speaker 3: in their work is a huge part of it, that venturing.
Speaker 1: So just kind of come to the kind of end
Speaker 1: of the discussion, I'd like to touch upon the fact that
Speaker 1: you've written quite a lot of articles and looking at
Speaker 1: your website, have got a lot of kind apps you
Speaker 1: could have built. So clearly you have I don't know
Speaker 1: how you do it, but clearly you have time to
Speaker 1: produce a lot. So I guess the question is, and
Speaker 1: as somebody also who has written a few articles there
Speaker 1: and there, what are your kind of tricks for being productive?
Speaker 3: Right?
Speaker 1: So when it comes to penning your articles, how do
Speaker 1: you do it? Is there kind of a workflow you
Speaker 1: have for research, writing, editing, publication promotion, right, and then
Speaker 1: also looking at all these kind of demops to go
Speaker 1: on your website, how do you also do that as well?
Speaker 1: Do you have a workflow where you're able to kind
Speaker 1: of push out and pump out all these apps and content,
Speaker 1: which obviously helps you as a programm right to learn
Speaker 1: new skills, shopping your skills, and give you stuff for
Speaker 1: your articles as well.
Speaker 3: Yeah, so a lot to unpack in there. So let's
Speaker 3: start first with the demo apps and stuff.
Speaker 1: So yeah, so.
Speaker 3: Yeah, I've built a decent amount of you know, little
Speaker 3: side projects and pet projects. I think on my portfolio
Speaker 3: I probably have I don't know, seventy or eighty projects
Speaker 3: on there, some demo apps and whatnot. A good chunk
Speaker 3: of those from when I was first learning to code.
Speaker 3: So that was one of my strategies of actually teaching myself.
Speaker 3: So again, I had that statistics degree, and I for
Speaker 3: the most part, I was generally self taught when it
Speaker 3: comes to coding. So I did a lot of online
Speaker 3: courses and you know, watched plural site videos and did
Speaker 3: free code camp projects and code Academy courses and all
Speaker 3: that good stuff. And so really the best way that
Speaker 3: I find that I learned is by doing. And so
Speaker 3: oftentimes it was just like, Okay, I want to figure
Speaker 3: out how this thing works, so we're going to build
Speaker 3: an app, right, as opposed to just reading a tutorial
Speaker 3: or watching a video, we're going to actually do this, right,
Speaker 3: So now I have the hands on experience of how
Speaker 3: I can, you know, go build this feature or work
Speaker 3: with this new technology. Right. So a lot of them
Speaker 3: were built just as like a personal learning experience and
Speaker 3: then also to build up that portfolio.
Speaker 2: Right.
Speaker 3: So again not having a CS degree, I feel like,
Speaker 3: especially if we're starting in your career, you have to
Speaker 3: almost kind of work a little harder to prove yourself right.
Speaker 3: Of I don't have this degree, but I can code, right,
Speaker 3: I can do it. And so having that portfolio to
Speaker 3: point to and say like, look, I built this. It's
Speaker 3: it's a full stack app, and it has authentication and
Speaker 3: it does all these things right, sort of provides that
Speaker 3: proof that hopefully at least have some understanding of what
Speaker 3: you're talking about and some level of expertise that was,
Speaker 3: you know, a while ago when I was when I
Speaker 3: was first getting started. Nowadays, a lot of the apps
Speaker 3: that I'm creating are honestly for the articles, so maybe
Speaker 3: I'll be working on some sort of proof of concept.
Speaker 3: A few of my last ones in there, I think
Speaker 3: we're like graph ql focused. So I did one of
Speaker 3: like implementing a graph ql API on top of an
Speaker 3: existing rest API. And then I didn't just want like
Speaker 3: a boring, you know, to do app app, So I
Speaker 3: made a dad joke database and anyway, so it fetches
Speaker 3: the dad jokes and has a graph QO layer implemented.
Speaker 3: But so anyway, So so oftentimes like getting more into
Speaker 3: these articles. Now, I've been writing for about a year
Speaker 3: and a half, and so oftentimes I'll be writing about,
Speaker 3: you know, either things that I'm passionate about, so like
Speaker 3: these articles with the React clean code and clean code
Speaker 3: if unit tests, or things that I'm you know, just
Speaker 3: interested in and learning about. So I've been you know,
Speaker 3: studying graph ql a lot lately, and so as I'm
Speaker 3: as I'm preparing to write these articles, I like to
Speaker 3: have a demo app to show people how we can
Speaker 3: actually use it. And so creating these apps is more
Speaker 3: just the preparation for the article of like, Okay, how
Speaker 3: could we solve the problem of if we have an
Speaker 3: existing rest API and we want to move over to
Speaker 3: graph ql, is it possible to kind of have them
Speaker 3: running side by side as opposed to just cutting over
Speaker 3: And if so, how would you do that? And so
Speaker 3: the the demo apps sort of became the exploration of
Speaker 3: that sort of problem, and then the article then is
Speaker 3: just an overview of Okay, what was the problem, how
Speaker 3: did we tackle it, and what did we learn from this?
Speaker 3: So really they kind of just go hand in hand
Speaker 3: to support each other at this point.
Speaker 4: Yeah, absolutely agree with all of that. And when when
Speaker 4: you talked about doing your own projects to learn stuff,
Speaker 4: that is just absolutely so critical. I mean it's not
Speaker 4: just you mentioned proof of expertise, and it's not just
Speaker 4: to others, it's to yourself.
Speaker 2: Right.
Speaker 4: You hear a lot about imposter syndrome and people not
Speaker 4: feeling like they you know, they're they've.
Speaker 2: Got the skills.
Speaker 4: Best way to make sure that you feel like you
Speaker 4: have those skills is to try it out and do
Speaker 4: it and make stuff. And it gives you a lot
Speaker 4: of pride as well. And a lot of people ask me, hey,
Speaker 4: you know, how do I become a reactive and it's like, well,
Speaker 4: you can watch a lot of videos, but you just
Speaker 4: gotta do it. I mean, you can watch videos on
Speaker 4: AX juggling, it doesn't make you an AX juggler. And
Speaker 4: I wouldn't try juggling access after just watching some videos
Speaker 4: on it. You know, you gotta go out there, you
Speaker 4: gotta try stuff and build stuff, and then you'll get
Speaker 4: that confidence and you'll beat that imposter syndrome and you'll
Speaker 4: feel like you belong in the business.
Speaker 3: Definitely awesome.
Speaker 1: So unless there's anything else you fool, maybe we should
Speaker 1: touch upon who can move to picks?
Speaker 3: Now, sure, let's go to picks.
Speaker 2: Cool.
Speaker 1: So basically picks just basically we just though choose like
Speaker 1: an article podcast to show whatever that we were wanting
Speaker 1: to share. So I can start off with my pick,
Speaker 1: which actually is is actually based on the fact that
Speaker 1: I think I said earlier. I've been on the annually
Speaker 1: for the last week in a bit and I've not
Speaker 1: been plugged in as I normally am, and it's quite
Speaker 1: amasing just to have that refreshing time away from the
Speaker 1: screens and Twitter and plugging and all that all that stuff.
Speaker 1: And so that's my pick that if you can try
Speaker 1: and at least like find them maybe a week or
Speaker 1: so where you just put one down, just go outside
Speaker 1: or whatever and just give your brain the research. And
Speaker 1: I'm quite enjoyed that.
Speaker 2: So I'll be.
Speaker 1: Definitely trying to do to do more that than going
Speaker 1: forward let's go to Jack.
Speaker 2: Yeah, definitely take a take a week and or just.
Speaker 4: Take a day, but you don't have to code seven
Speaker 4: days a week, code code six.
Speaker 2: Take that Saturday, go for a hike, clear your mind.
Speaker 4: My pick for this week would be Joe tie It's
Speaker 4: a state manager from Daishi Kato and it's a re
Speaker 4: implementation of Facebook's Recoil and it's really interesting. It's an
Speaker 4: interesting different take on the state management. By creating, you
Speaker 4: can create these little atoms and they're interrelated and then
Speaker 4: when one changes, the other update. And what's really cool
Speaker 4: about Joe Time particular is he's actually integrated it recently
Speaker 4: with immer, which is an immutable library, so you can
Speaker 4: have an immutable atom, and you can have an ex
Speaker 4: state atom, which means you can have an atom that
Speaker 4: actually has any little state.
Speaker 2: Machine in it.
Speaker 4: It's very very cool stuff. So I'm really excited about
Speaker 4: all of Daishi Kato's state managers, but Joe Time Particular
Speaker 4: is really pretty cool, awesome.
Speaker 1: And then Tie up.
Speaker 3: Yeah, my pick. This will be totally unrelated, but I'm
Speaker 3: currently reading a book called Being Wrong by Catherine Schultz.
Speaker 3: I'm about halfway into it right now, but it has
Speaker 3: been excellent read so far. It is all about essentially
Speaker 3: the experience of being wrong. How you know, all most
Speaker 3: of us have a a pretty general idea that we
Speaker 3: are we are right most of the time. Right, if
Speaker 3: we didn't believe the things we believe, we wouldn't believe
Speaker 3: them by definition right, And yet we're wrong all the time.
Speaker 3: And it's it's been a really fascinating read, just into
Speaker 3: the experience of being wrong and how we can deal
Speaker 3: with it a lot more like typically when when we're
Speaker 3: wrong about something, we tend to feel upset or embarrassed
Speaker 3: or angry at being proven wrong. But her whole book is,
Speaker 3: you know, more about embracing, embracing being wrong and how
Speaker 3: we can learn from it. So it's been it's been
Speaker 3: a fascinating read.
Speaker 4: That's what being a pargmer is all about. Right, We're
Speaker 4: all we're very wrong until it's right, you know, until
Speaker 4: it works. Everything is wrong up until then, So you
Speaker 4: got to be comfortable with being wrong of the time.
Speaker 1: Yeah, I mean, I also speakle programming is basically being
Speaker 1: paid to work to work that out right.
Speaker 2: Exactly, you know I think paid well, yes.
Speaker 1: Yeah, and for me when that actually clicks. That essentially
Speaker 1: I'm not. I'm being hired to know things. They want
Speaker 1: me to use what I've learned to find out the
Speaker 1: best solution to whatever they working on right and for
Speaker 1: me that when that clicked, it changed how I approached
Speaker 1: my work. I was now less scared of not knowing
Speaker 1: what I was doing, and it can be being more
Speaker 1: open to you know what, this guts to be wrong,
Speaker 1: but that's fine because I'll be paid for actually saying, Okay,
Speaker 1: this is wrong, but this is how you fix it,
Speaker 1: as opposed to going in thinking okay, every single thing
Speaker 1: I do first time right is correct, which never never
Speaker 1: happens in our industry.
Speaker 3: Absolutely, there's a lot of value in having that humility
Speaker 3: to to not think you're always right, that you're you're
Speaker 3: okay with being wrong and maybe being proved wrong in
Speaker 3: the hopes of eventually getting it right right as a team,
Speaker 3: as opposed to just always being right.
Speaker 4: It's a great opportunity. You know, when you think about
Speaker 4: it like you're that means that you're learning and that's
Speaker 4: a great thing.
Speaker 1: Awesome. So I'm trying of how can people get in
Speaker 1: touch with you if they want to say hello or
Speaker 1: asking you any more questions about clean Code.
Speaker 3: Yeah, if you want to check out any of my articles,
Speaker 3: I'm fairly active on Medium and dev I also read
Speaker 3: a lot on d Zone and Hafernoons, so feel free
Speaker 3: to check out anything there. If you want to get
Speaker 3: in touch with me, you can find me on LinkedIn.
Speaker 3: I think I'm the only Tyler Hawkins that works out Adobe,
Speaker 3: so it should be able to I'm on Twitter as well.
Speaker 3: I honestly don't don't tweet that much. I'm not super active,
Speaker 3: but feel free to chat with me there if you'd
Speaker 3: like as well.
Speaker 1: Awesome. So yeah, I'll post the links to your verious
Speaker 1: social profiles on the guest notes. So yeah, that's a
Speaker 1: little beat so, but thank you so much for today
Speaker 1: til it's moody, informative. Thank you for your time, and
Speaker 1: I'm definitely going to be going back to your clean
Speaker 1: Code article and try to clean one or two more gems.
Speaker 2: And episodely, thank you for sharing. That was great.
Speaker 3: Yeah, thanks for having me. It's been fun.
Speaker 1: Awesome. So that's over today's show. Thank you, Sumpch and
Speaker 1: I'm seeing you next time. Thank you.