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