Steve sits down with returning guest host Drew Baker to talk about what makes a good programmer. They each list their top five characteristics and find that there is a lot of crossovers between their lists, and as always, go down a few rabbit trails on things like code comments. They end with Steve's famous dad jokes and some new exciting CSS features.

 

Hello everybody and welcome to another exciting episode of Views on View. I am Steve Edwards, the host with the Facebook radio and the voice for being a mime, but I'm still your host. With me today, I have one of my special returning guests slash co-hosts slash next genius, Drew Baker. How you doing, Drew? Drew Baker, I'm your host. I'm a huge fan of your show.

 

Great, Steve. Thanks for the intro.

 

Yes, Drew is my world traveling next expert. He is in LA with where his company Funk House is. Last time he was in Australia and this day, today he's in Milan. So he's trying to think I hit all seven continents or at least five of them here, before he goes back to LA.

 

Yeah, working on it. We'll see.

 

Working on it. He's the international next developer. Man of many skills. So today we are here to talk about what makes a good developer a great developer. And before I forget, I'm sorry, I always forget then. I'd like to say hello to our studio audience. How you doing everybody? Right, right. People, oops, sorry. Sorry, is he quiet? Quiet, thank you, thank you. Okay, so yeah, when the audience heard that Drew is gonna be on the show, when I put that on the list, I sold out a ticket so fast, it was crazy. So, anyway, so now that everybody's here, let's talk about developers, and good developers, and great developers, and at least our opinions of them, not that we're a great, well, I can't speak for Drew, but. I don't know if I'm a great developer. But we've each come up, and we haven't shared these lists with each other yet, five things that we think make a developer a really good developer. And so we'll just sort of go back and forth and see if we have some of the same things or different items. And I know my list isn't in any particular order. So Drew, you being the traveling expert guest, what's your first item?

 

Yeah, well I guess before I get into it a little bit, I'll give some context to my list and sort of my approach with it. I think that you want to approach these sorts of things and your kind of like programming in a bit more of like a generic sense, like I'm not going to give out tips that are like, you know, used to abs over spaces. That's not what I'm talking about. It's just more about sort of general best practices and approaches that I've noticed over my career when working with other people and what separates just kind of your run of the mill developer and the people that stand out and seem special.

 

Yeah, I mean,

 

So that's

 

we wouldn't

 

kind of,

 

talk about

 

yeah.

 

tabs or spaces because everybody knows it's spaces, right?

 

Yeah, I think that's probably a settled thing now, isn't it?

 

It's

 

But

 

settled science, right?

 

yeah, so anyway, my approach is a bit more philosophical in some of my answers, and I tried to kind of come up with a list that I think works for not just beginners but also people that are established and know kind of what they're doing already and thinking about how do I go to the next level. So that's my list. So with that in mind, my, and also my ordering is not specifically like, you know, in order of priority, it was more just in order of, I don't know, my order's not necessarily that great. It's probably could go in any order, but having said that, here's number five. So I think number five for me is consistency. And what I mean by that is, you should, be able to intuitively read through code or a view component or a view app, like a whole slide. And it should, like if you've done a good job at it, you should be able to kind of pick up the flow and guess where things are going to go based on the consistency that you have. So things like definitely use a linting tool, like Pretia or ESLint. Those things are actually more tricky to set up than you would think, but make a huge difference. And there's this great saying of, everyone else's... everyone's code formatting is terrible except for mine.

 

Amen.

 

And... and I think that that is a really good point and you should adopt a Pretia or an ESLint config and there's a bunch of sort of... default ones out there that everyone's kind of gelled around like the Airbnb one is one of the ones but view has a recommended view spec one and it'll be weird to you if you've never used them before because it'll do things that you don't agree with but that's kind of the point is that it doesn't really matter like across a team it doesn't really matter what the spec is as long as you're all doing it so definitely use linting tools for that have a naming convention that you kind of works for you or works for the team and stick to it. You know, like one thing that we do all the time at Funkhouse is we have kind of like blocks that make up grids, you know, and we just not grids in the CSS grid, just in terminology. And then we have sections. And so everything will be called like block work or block featured or block news or these sorts of things, right? Don't see all of that in someone else's code or the project you're working on and then go. Now I'm going to call it something else. Consistency. Go with what is in the project or the own, your own sort of convention that you've established. Same with like variable names or things like camel case and underscores in variable names and things like that. Whatever it is, just be consistent with it. Like if you're, if the project has like BEM style CSS classes, don't not do that on the one thing that you're building on. You know, stick with. what they've got there. And then sort of the last thing I'll add to that is, I'm not sure if this is a phrase anyone else understands, but I say it all the time, which is have a single source of truth. So if you're doing things like building something that relies on state and store, always use it. Always do it the same way and have. that one, like for example, a menu being opened or closed, like a sliding hamburger menu opening and closing across the whole screen. Have that all sit in one place, like in Nuxt, it would be in the store somewhere, and you'd have a variable that was sort of menu open close, or Pino, or whatever it is, might you've been using. Try and do that for everything then. Don't have some stuff being component level, and some stuff being in the store, and some things using events, and some, you know. Consistency, single source of truth. There is nothing more confusing than coming into an app that someone else has written, and you're trying to figure out like, what is controlling this thing being opened or closed? Because I thought it was over here where I see it clearly being open or closed, but then you find out, oh, there's this other thing. So single source of truth is always a good approach there. So that was my number five, what about you Steve?

 

Well, before I go to mine, I'll add a couple things on to what you just said regarding consistency. And in the particular app that I work on day to day, which is gigantic, I've seen pros and cons of that. Well, let me take it. I've seen what happens when you are consistent and when you're not consistent. So we've hired it, you know, over the past year, I've hired a couple of developers. And one of the things that our app is very good at is how we... name and structure everything for all our different entity types that exist in our particular application. So if it's an index, it's named something, something model index. If it's the main view page of something, something model show, if you know, so on and so forth. So we actually had a couple of developers come in and said, wow, it's real easy to understand where everything is because of the way everything's structured so similarly. So it really makes it easier for somebody to come in and and be able to grasp the scope of the application and where everything is if you're consistent with your naming and structuring in terms of how you do it. Now in other cases, everything that we do, all our content gets indexed from Mongo to Elasticsearch. But there are some times when we do searches one way from Vue and other ways from Laravel and that gets real confusing because we're not consistent. and makes it harder for us, we're sitting there. And so we have to go to the person that created it all, how does this work? Oh yeah, this and this. So the lack of consistency can certainly, can be a problem, but it's a very good thing when you do have it. Now, one of the things you mentioned was a linter, you used like ES linter pretty or something like that. We actually got away from that, trying to do that because of... trying to keep everybody's config files and IDEs in sync. And so we did use a backend approach we call style CI. And so what happens is when we make a commit to a branch and we push it up, it runs through all the tests, you know, our desk and unit tests and that kind of stuff. And then style CI runs it and makes any formatting changes. So you've got a standard for formatting for PHP files versus CSS files and view files and so on. And basically makes commits that fix all of that formatting for you on the backend. So that way we know that everything has format for everything and what it does is it adds a commit so that gets to be a little hinky sometimes from a git standpoint because then you got to pull down those commits but it's what makes things consistent from formatting standpoint.

 

Oh, that's

 

So

 

interesting. I hadn't heard of that.

 

yeah.

 

That's cool. I think I would urge the linting approach in your IDE if you can do it because it just, it's really interesting to write something and then, you know, save it and then see the linting result and being like, ah, and you

 

Yeah.

 

learn, you know, like now I've been doing it so long. I could probably write my code to match what the linting is going to do,

 

Right.

 

but, and it's also faster. Like a lot of the times you can just write like a a jumbler code like in a long line, knowing that it's gonna like get formatted correctly, you know, so it's good. But your point about the configs is totally true. And that's when I said earlier, like it's actually really hard, way harder than you think to set those things up is fully true. It's like very hard to keep that consistent across the team. Essentially, like what we did was just kind of force everyone to use VS code, because it

 

Right.

 

was like impossible to get it working in all the different ones.

 

Yeah, that's for sure. Yeah, we use a common, we use phpStorm as our IDE of choice, everybody uses it, and so that makes it easy for things like that, but moving on. So I'm gonna go sort of something along those lines and the ability to follow logical steps. And one of the things I like to talk about is debugging and figuring out what's going on, because no matter. you know, where you are with your writing code, or whether you're looking at somebody else's code. A lot of times you got to figure what's the problem. Or let's say you get a ticket, you know, we have a combination of tickets that we'll get for any particular sprint, there'll be new features that, you know, we're developing for our next release. Or, you know, bugs that people have found, that customers have found, that, you know, this isn't showing here, this, whatever it may be. And so you've got to be able to figure, figure out what's going wrong. Start from a step, okay, I've got this, let's go back to this step and this step and this step and work your way back through the chain of code. And if you don't do that, what I've seen with some younger developers that I've mentored in the past is that they don't follow that step. Well, this isn't working, okay, let's go look at this. Okay, let's hop back here and look at this. And a couple months ago, I had a developer contact me because he was... He couldn't figure it out. He had a bug ticket and he couldn't figure it out. So I said, okay, let's go here. So we started from here. Here's the view component that we're looking at. Something's not showing right. Okay, so what does that component need? It needs this piece of data. Okay, where does this piece of data come from here? Go through about four or five steps back and what it came down to was a missing prop that wasn't being passed into a view component. And it was, you know, it was fairly complex. You needed to know some things, but. I said, look, all we did was follow this step from here to here to here. You were jumping here and here and here and you would never figure it out at that rate. You got to just be able to follow, you know, the steps logically and code writing, um, you know, people will say is. Some people say anybody can do it. Some people say no, not anybody can do it. You know, there's all kinds of debate about there. But I think anybody can learn how to do it, but to be really good at it, you've gotta be able to do certain things. You gotta have certain creativity and certain troubleshooting steps. And this is one of those things. But anybody can do this. you know, step A to step B to step C. And it's very tempting if you're impatient, dang it, I gotta get this fixed and you start jumping around because it can't be that. It couldn't possibly be that. Yes, it could. So anyway, that's one of my steps is just the ability to follow logical steps either when you're building something or when you're working backwards, you're troubleshooting something and you, okay, it's broke here. How do I get back to where the problem is?

 

That's funny, that's pretty much my number four was, I say it all the time, which is like, think like an engineer, not like a hacker. And

 

Alright.

 

that's what my number four is, which is basically what you just said, which is have some logic to what you're doing, and think like, yeah, think like an engineer. What's wrong with this? Why is this wrong? Or I'm building this thing, what does it need to do? Design it. I'm not saying design it in Photoshop or Figma. I'm saying design it in the code sense. Like a lot of the times, for me, I will just pseudo code, which is in comments, write out what's supposed to happen. Take this array, filter it, map through it, remove this, add this, return it, right? You can just write that in comments. And a lot of times that will help you kind of figure out what needs to happen at each step. Another great tip that I try and preach here is You can write your return line first. Like if you, the first thing you write in a function is the return, like what is it supposed to return? Is it gonna be a string or an object or whatever it is? If you do that first, it often helps you work backwards from there rather than kind of like starting with just an empty function and then hoping you get to the return that you want. Don't do that. I would also say like leave lots of comments and the way to think about that is if someone less experienced than you, could they understand what you're doing? Because a lot of people just assume like, ah, I don't need to like explain this, it's obvious. Well, it's obvious to you. So definitely write comments. I don't think anyone is ever going to code review you and be like, this is bad because there's too many comments. You know, I don't think you wanna write every line doesn't need a comment being like, you know, explaining what a map, a JS map function does. but you know you do want to explain like i'm looking at this thing to do this thing you know i needed to filter out incorrect results or whatever might be uh... so yet that that would be the other one and and part of that thinking is also one function should do one thing don't have any side effects you know don't write a function that opens the menu and filters out the you know menu items and some other thing all in one that should be three functions that do each one, and stick to that. Don't have any side effects to your functions. Just do one thing. That's this functional programming, and I think that's a really smart way to do it. Yeah, and then on that note is, we have a whole bunch of utility functions that we use, and in Vue 3, that's like composables and stuff. And generally, you want one of those, I think you would want one of those per file. don't have a file with like 50 utility functions in it. It's way easier if you have one file, one function. You know, just like Vue, we have single file components, it's one component, one file. Although that is changing, you can have like multiple templates in a file and stuff now. But I still think it's a good idea, one file, one function makes it way easier. So that would be my number four, which just kind

 

Well,

 

of overlaps

 

so

 

with

 

to go

 

yours.

 

back to a couple of things you said there, the whole thing about code comments, you wanna talk about opening a can of worms. I have heard entire podcast episodes on comments, whether you should, where you shouldn't. There's two basic camps, as best I've heard it. One is if your code is good, you don't need comments. Which I find, yeah, there's some truth to it, but I'm tend to be. more of a commenting person, not as much as I'd like. You know, there's times where something's unique, you know, well, the reason I'm doing this is because this returns this value from here, even though you would expect this, you know, or something like that to explain a unique situation. Sometimes it's just for myself, because I've got something that's like, okay, I'm doing this, now I'm doing this, you know, to go back to my logical progression, I'm explaining what I'm doing. So I'm not, I'm at the camp, I'm certainly not in the camp where, no, if you're, to me, it sounds almost snobbish. to say, well, if your code's good enough, then you don't need comments. Well, no, that's not true. Code is code, and unless you wanna get in the internals of every function, sometimes you don't know it, it just helps to have comments there. But at the same time, I don't have a file that's 75% comments and 25% code, where you

 

No.

 

overdo it. I think comments are good, you keep them succinct, they explain what's going on, and it helps you to understand it, especially if somebody's new coming in.

 

Yeah,

 

Um.

 

I would add that Vue has a few things that, to that point of view, if your code's good, you don't need as many comments. I would say if your code's great, you don't need, you need no comments is not true. Like you definitely

 

Right.

 

would want to comment. But there's something like, for example, Vue props, you know, you have a few things on there like validation. There's a validation feature built into that. There's the required flag. There's default settings. All of those things really help meaning you don't need code. If you've got, this is required, you don't need a comment saying this is required. So there's those things that view helps you in that regard for sure. But I would say also that when I say comments, I also mean documentation. Like they're not the same thing, but they're the same philosophy, which is just explaining what you're doing. Like a good example is if you ever work on anything that's like HIPAA compliant, like healthcare related, requirements there legally is you have to document everything. It has to be very well explained. And that's purely for that everything we're talking about, just so that someone can see this and understand what's going on. And it enforces like a level of discipline and best practice. So I think getting in a good habit of that really does help separate you from the good and the average.

 

Right. All right, so let's go with my next one. I'm going to say, sort of along the lines of what we've been saying, maybe a little different, is just attention to detail. When I was first getting into computers and networks and stuff, this is back along 20 years ago, and I was working on getting an MCSE certification for Microsoft. This is in the days of Windows 2000. and so on, because I wanted it to help me at work. And one of my teachers gave an example from NASA that he had seen where they'd launched this rocket. And this rocket goes up, and all of a sudden, it goes sideways, like horizontal. And, hm, OK, something's not right here. So they go back, and they're looking through the code. And they found a missing colon. Had. was the root cause of the problem that had screwed up all the software. I can remember doing PHP back before I was using clean URLs in Apache. And I had this, you know, so you had one file per URL and everything was direct one-to-one map and I had this problem. I spent an hour... trying to figure out the problem. And it turned out to be, I finally had to get two files next to each other and flip back and forth really quickly and found out that I had an extra space somewhere. So little stuff like that can really cause big problems. And so you have to be very detail oriented. And anybody who codes knows that sometimes missing brace, a missing curly bracket, a missing semicolon, can wreak all kinds of habit. And actually what I'm gonna do is I'm gonna give an example that I ran into yesterday and combine it with another one of my items, which is knowing your tools, right? So when I first started out in computers, like I said years and years ago, I was doing tech support. And so I was supporting existing programs that I didn't write, but I was the one that was talking to the customers and helping them troubleshoot. And my customers, banks, and financial institutions, and we wrote software for them. So anyway. I found out that if I knew my program, the better I knew my program, the better I could figure something out. Because if you know how it should go, when something's not right, then it's easy to spot. Because, well, it should be doing this here, but it's not, so this must be wrong here at such and such a place. So yesterday, I'm gonna give this. story that sort of combines those two. So yesterday we'd been working on putting together a release and it had all these PRs that had merged into our branch and I was ready to merge it to our master branch and deploy it. And as a last step we throw it up on I guess you would call a staging site, we call it our beta site. Now our data is so huge that we can't copy it down locally from your production to have all of your data on your local database. And so we have, in Laravel, we have some scripts that pump in a bunch of BSON data and give us a test data set. But when we throw it up on our beta site, it's like there, but it's running against prod data, so you can run into problems. You can see things that might happen because maybe there's data out there that you don't have a relationship or something. All of a sudden this one main page was just blowing up. 500 internal server error was getting returned. It was dying, it was timing out. And it was right before I started to release it. And so me and my boss is out of paternity leave, so the other founder and I got on. It took us three hours of literally going line by line through code through. everything till we finally got down and we figured out what it was. And if you know anything about Laravel, you have thing called resources and resources are basically just a way to map out your data that's getting returned by the back end to the front end in JSON. And we found out that there was two sets of missing parentheses that were taking down our entire server. Because in Laravel, in the eloquent, when you're dealing with eloquent models, you can use what's called the fluent type of syntax, where you can chain things together. So it allows you to chain methods and things together. And when you have a particular relationship, if you don't include parentheses on the end, it just gives you the entire record set of whether or not that relationship. Represents, but if you do put the parentheses, it's just a builder It's not giving your whole set data set and then you chain other things on in this case. You wanted a count of something Hadn't put the parentheses in this particular relationship had tens of thousands of items in it But you didn't want it at that point yet. And so the server was just dying all because of two sets of missing parentheses So that was it was incredibly small and important detail to know And in this case, it was one, he wasn't being detailed, and two, he didn't really understand that part about Laravel, which is one of our particular tools. So, that. I could go on and on with examples of that, of how not knowing something really causes problems. Because, now, one, it's not only the developer's time, but it's wasting the time of people who have to figure it out later,

 

Yeah.

 

as compared to doing

 

That

 

that.

 

phrase of know your tools is such a good one. I'm sort of blown away with the amount of people that I run into that don't know how to reformat their computer. They've just worked at companies where they show up and they get given a computer and that's it. Can you imagine if I was a builder, I'm building a house and I didn't know how to repair my hammer?

 

Right.

 

know how to reformat your computer and reinstall everything and you know what NPM packages are being used those are that's just doing your homework and studying your tools like you said it's totally easy stuff to do and it's a good point

 

Yeah, you know, one of the big things that I've always used that's been incredibly useful is debugger. You know,

 

Yeah.

 

whether it's the browser tools for the front end or with PHP on the back end, it's Xdebug. And That has helped me solve so many things over

 

Yeah.

 

a course of time as compared to people that will always just console log and run it. Okay, now I've got to come back and do it again. Run it again to see what the output is as compared to being able to stop and look and see what's going on. And it helped me a ton yesterday.

 

Yeah.

 

And. to the point where when I came into Fluke a few years ago and I was working on a larger development team and they had just been using Drupal for a little while. And I was consistently able to figure out and solve problems using that tool that they asked me to give a training to other people on it because they saw how useful it was that I knew what my tools were. You know, in the view world, the front end JavaScript CSS world. A lot of times it's your browser, your browser tools. What are the things you can do in your browser tools that will make you more efficient? Whether there's a step-by-step debugger, there's the style, you know, looking at the styles, there's your network tabs, there's your console, you know, there's your looking at elements. And there's a lot of other tools that I still haven't mastered yet. I'll read articles all the times about all the things you can do in your tools that blow your mind, you

 

A

 

know,

 

pro

 

but.

 

tip for that one is the bundle analyzer that's built into Nuxt. Really interesting to see what's getting bundled into your final deployment and you'll, you know, I've looked at things that people have made and you'll be like, oh, you're bundling the entire low dash library for one

 

Hahaha

 

function, you know, or, you know, any of the moment JS and all these

 

Yes.

 

old like

 

Alright.

 

date libraries and stuff are like notorious for like.

 

Yeah.

 

bundling all the languages even though you just wrote three lines in English. So yeah, that's a good one. Yeah,

 

The

 

I

 

view

 

mean,

 

dev tools are another one. I use those

 

yeah,

 

quite extensively. Be able to

 

everyone

 

look and

 

should

 

see,

 

be using that.

 

here's my component, here's all the data, here's my props, here's my view X, here's my computed values, here's the parents, yeah, you

 

Yeah,

 

can step

 

I would

 

by

 

hope

 

step.

 

everyone listening

 

Yeah.

 

to this is using that. If not, I don't know how you would build anything. It's so critical.

 

My only problem with the latest ones is that they crash and burn a lot. I'm constantly

 

Yeah.

 

having to restart them. I didn't have to used to do that before, but now for some reason I do. And the other devs on my team have noticed that as well. So I'm

 

Yeah,

 

not sure

 

and

 

what's

 

switching

 

up with

 

between

 

that.

 

view two and view three is always a bit of a problem with those.

 

Yeah.

 

Cool. Well, that you mentioned burning other people's time because you didn't do something right. That kind of leads me to my number three, which was when you are part of a team, inevitably you're going to have to ask for help, which is totally fine and is good. You know, that's the whole point of being in a team. But when you go to someone to ask someone for help. You really should come with some solutions, not I've done nothing and please tell me what to do. Do not, the way I kind of phrase it is, don't cheat on the test. Like you make an attempt and make a few attempts and come to me with I've tried A, B, C and D. Either I don't know which is the right way to do it or which none of these worked and I'm kind of at a dead end but I tried them all. Nothing is more frustrating than someone coming to you with a, hey, how do I do this thing? Or the worst one is, where have we done this before? You know, can you point me at a piece of code that, you know, it's like, oh, so now I'm just like a human Google? Like we have these tools, GitHub, you have access to all this stuff, look for it. So one of your things should be, I looked through GitHub for it. I looked on Stack Overflow for it. Like those are easy things. Those aren't even, I'm a good programmer. Those are just, I did the bare minimum. So try a bunch of things before you come asking for help. The way I say it, it's sort of a story from my dad who works in construction. And you know, he tells this story of showing up on a, going to a job site in the morning and talking to a laborer and being like, okay, you gotta dig this hole from A to B. and I'll be back at lunchtime and you know, check on the progress, let me know if you have any problems. Show up at lunchtime, holes not dug. Why not? I didn't have a shovel. Find a shovel. So this is a saying that I always say to my team is like, find a shovel, don't sit around with nothing to do. Figure out what you need to get done and then try. Try something versus nothing. Oftentimes bashing your head against a wall. is the best way to learn. I, man, I did it, I did it this week. I'm building this crazy animated website for a client and we're using a lot of like CSS scroll snap effects which is sort of relatively new thing. You should check it out. It's really interesting. It allows you to kind of like lock the browser scroll into certain certain views that you want.

 

Oh, right.

 

I spent three days why it wasn't working in Chrome. It was getting like a lot of layout thrashing in Chrome. Worked great in Firefox, Firefox worked great in Safari, which has blowed my mind because generally nothing looks good in Safari. And I ended up sort of at wit's end, didn't know what to do, and so I wrote out a big stack overflow post, explaining all the things that I had tried, and inevitably writing it all out led me to the answer. I didn't even end up posting it. I just was like, God damn it, I figured it out. And so that led to like my point of like, you know, try things and then ask for help on, I think Stack Overflow is just brilliant. Like if you haven't wrote a post on there asking for help, you really should, it's such a great way to kind of like level up and it's also a great way to sort of solve your own problems.

 

What's the term for that?

 

For what? For

 

The rubber

 

solving

 

duck,

 

your-

 

you're rubber

 

Oh yeah,

 

ducking.

 

the rubber duck, yeah, yeah,

 

You're rubber

 

that's funny.

 

ducking.

 

I

 

Talk

 

remember,

 

into the rubber duck.

 

talking to the rubber duck, I remember I had a developer that works for me, his name's Derek, I'll admit to this, I never told him this straight up, but he would use the term rubber ducking all the time, and for years I had no idea what he was talking about. I was like, okay,

 

Oh yeah,

 

yeah.

 

oh I have rubber duck. I can recall times where I've had entire detailed posts written out on Stack Overflow and like, oh, wait a minute, what about this? You know, I had one written in Discord yesterday in one of the Laravel rooms and I was like, oh, wait a minute, yeah, what about this? Yeah, that rubber duck. Now, okay, let's explain that for a minute. For those who aren't familiar with the term rubber duck. The idea is basically that if you have a problem, you have something that you can't figure out, you pretend like you're telling it to a rubber duck. You know, some, pick your inanimate object. Rubber duck is the one that was used when the story started, and I've heard various stories as to how this term started. And the idea is that as you explain it out loud, event you will come across something or something will happen, something will trigger, they'll think, oh yeah, I hadn't thought about this, or what about this? just because, just by taking the time to talk it out and explain it to somebody. So that's what the term means.

 

what was, to finish my scroll snap problem, it was that if you change the document length, so the total scroll length of the browser, while in the middle of a transition, middle of a scroll snap scroll, Chrome hates it. And so writing it out, I wrote a little thing like, I noticed that the scroll handle, like the little bit that you would click on to scroll, change a little bit in width as I was scrolling down the page, or change a little bit in height, sorry, as I was scrolling down the page. And just having wrote that out, I was like, that's kind of weird. I wonder why it does that. And that's what led me to realize, like, ah, I was turning on and off the footer on scroll and it broke everything. So point is bash your head against the wall. It's the best way to learn. And also stack overflow is great.

 

Yes, right. So all right, I'm going to come back to one more. And this is along the lines of knowing your tools, which is knowing your platform. So knowing your application, I think, is what I mean more of. your tools. Earlier we were talking about tools, like what are the things you use to develop your IDE, your debugger, you know, your deployment, all that kind of stuff. Knowing your platform, how does it work, what is it doing behind the scenes, what are, what's it based on, you know, for instance. The more you know your application, then if you need to add something, then you, oh yeah, this would fit in nicely here, or I could do it in such and such a way, or again if something goes wrong, well it should be doing this, but it's not because this is the way we wrote it. you know, then you're gonna be able to figure that out a lot easier. Instead of, you know, being real, there's something to be said for being good at troubleshooting and being able to follow, but the more you know something, the easier it is to spot anomalies and to know how to do it. A classic example I used to hear, and I don't know if it's necessarily true anymore, when I first came out of college I worked at a bank and I actually used to train tellers. The story I heard was, and we didn't do this then, but maybe this happened years before, is you'd get a new teller in and one of the things you wanted them to be able to do was to spot counterfeit bills. And so what they would do is they would have you, and it's got to be monotonous as heck, is sit there and count bills over and over and over. hundreds, 20s, 10s, fives, twos back in the day, whatever, you're counting and counting and counting. Then pretty soon they start throwing in counterfeits. And because you're so familiar, at that point, it's mind-numbingly familiar what a real bill looks like, the feel and the look and so on. They throw in a counterfeit and you're like, that's odd. Well, that doesn't fit, look at it. Oh, it's counterfeit. But the idea, again, is just knowing what you've got so then you could spot the differences. So obviously when you're coming in, you're gonna have different levels of documentation and help that help you get familiar with the application. That's always the, what's the term I'm looking for? You know. The ideal, I guess, is to have a well-documented application somebody new can learn it. The reality tends to be quite different. I can think of years where I've spent, yeah, I should document this and lay out the whole application and you never get around to it because you're too busy working on the application. And so if you have that, it's great. If not, then it's really just something you learn over time, doing things, having to figure things out. You get more familiar with it and you know it. But... You have to, I think as a good developer, the more you understand that, the better you're gonna be at what you do, the more efficient you're gonna be.

 

Yeah, that actually lines up with my number two, which was, is do your homework, which is basically what you're saying, I think. Which is,

 

Yes.

 

if you see something, like we're all working in code all the time, and if you see something that you don't quite understand, don't just go, ah, I don't understand how it works, next.

 

Ha ha ha.

 

And you'd be surprised, so many people do that, you know. Read about it. Like, what is that? Ah, okay, look it up. You know? the casual, you know, I don't know, the Mozilla docs on like this function, or even the W3 schools one, like that is better than just like skipping over it. I think doing your homework is a thing that a lot of people don't do. Certainly a lot of developers just kind of go like, I kind of know how to do my job, so I'm just gonna do that. You definitely wanna read everything. understand what this function is, understand what this thing I saw does. And that kind of, I think, flows onto what homework can you get access to. So for example, if you're a professional programmer, I kind of explain like this at work all the time, which is like, we're going to do the extra step because we're professionals. Or like, we're gonna do this thing that's tedious, but is kind of, we all know is the right way to do it because we're the best in the world at this. Like act like that, think like that. Don't think like, ah, this is good enough. No, no, you wanna be the best, so do it the right way. Read the right things. So for example, like definitely go, like I hate to be the one out there saying we need more social media, but follow a bunch of like the best programmers on Twitter. You'll learn something, I guarantee you. So, you know, like if you're in the view world, you should follow Evan, the view guy, you know, you should follow all the Nux dudes. You should follow a bunch of like, off air, Steve and I were talking about the content that Michael Thiessen puts out. Great learning stuff. Like follow those things and you'll learn stuff. You should look at Hacker News all the time, like every day. So many good stuff on there, both in the computer space and the software engineering space, but also just in the JavaScript and tech world, it's really interesting. It's interesting and it helps you not just in your job, but just, I mean, if you don't, if you're not legitimately interested in that, then you know, it's painful. But I think that if you're a professional programmer, you will just be generally interested in it and you should read it anyway. And it's good. I think browsing through Stack Overflow is also really good. Like you can go on there and look at the filter by the questions that have bounties on them. So bounties. Stack Overflow, if you're people not familiar with, you accrue points for doing things. It's really gamified and it's kind of fun in that way. And if you've got a question that you can't get an answer to, you can give up some of your points as a bounty. And those questions normally are really challenging ones. And it's a lot of fun. You should read through them, you'll learn a lot, you'll see complicated problems. And also... It's a thing that I make any new program and do that comes to work for Funkhouse is like just spend the day answering questions on Stack Overflow. Go find ones that you can answer, even if they're just simple ones like how to splice an array or whatever it is. It's just good to see what other people are doing and answer it and also get shredded on there. Like it's if you if you answer something wrong, you'll get shredded and it's good for you. It's good to learn that stuff. So do your homework is a really important thing. I think also reading through GitHub PRs, like again, this isn't even, you don't even have to be able to write a line of code, but go read through PRs on Vue and Nuxt and read through like the request for proposals. Just look through that stuff. You don't have to even write a line of code, just read it and you'll learn something I guarantee you. Really interesting to see what pros like these like, There's some programmers out there that are just like God status programmers and you should look at their stuff. It's really like Daniel Rowe, who's been a guest on us here and who just got promoted to like head of architecture or something at NUXT. Look through his PRs. It's incredible. You'll learn a lot. So do your homework.

 

Yeah, one of the things that my boss will frequently tell me is the polite version of our TFM. Read the effing manual. One of the things that in my world, View and Laravel have are good docs. Taylor Ott, when I interviewed Taylor Ott, well, of Laravel, I mentioned that to him and he said, well, part of the reason is because he had a technical writing education in college and so he was able to use that to create good

 

That's

 

documents.

 

great.

 

And VIEW is also known for its good documents. They're not as good to me as other people rave about them. I think they could be a little more detailed sometime, but for the overall, I think they're very good. And for

 

Yeah,

 

somebody

 

there's

 

who's

 

nothing

 

wanting to

 

more

 

get up in speed.

 

frustrating than helping someone with an answer. You know, if someone comes to you on your team and like, how I do this, and the answer is like, I just read the docs.

 

Oh, my boss does that to me all the time because, and I can understand it because, you know, it was him and one of the founder for 10 years and they had learned everything from scratch and they did it by the documents and playing around with it. And so that's their tendency is to say that. So, but the documents for whatever platform you have or whatever you're using, if they're good. Use them, read them a lot. A lot of times you'll be amazed at what you can find that will solve your problem just by looking in there. You

 

Yeah,

 

know,

 

and I would

 

for sure.

 

say if you're going to use something that doesn't have docs, probably don't use it.

 

I have heard, I have seen people say, yeah, I can't use this particular platform or you know, particular library or framework, whatever, just because the docs suck. And it's true. You know, there's something you said for being able to figure out something by reading through the code. But you know, when you got a time crunch, not everybody has the time to be able to go read through code and figure out how something works, you know. So reading

 

think

 

the docs.

 

that the docs thing you know I was back to my like number my point for about think like an engineer having your own sort of docs is a good thing like one of the guys that works for me does that he has his own like notion pad of just like his own Wikipedia for just things that

 

Yes.

 

he needs to know and that's a really good idea we implemented a practice at Funkhouse a year or so ago where I refuse to answer questions directly now, I just write the doc for it and send the link. So I think that's a really good idea. Obviously sometimes you need to like just help with the question stuff, but getting in the practice of writing docs is just a really good idea

 

What

 

and

 

do

 

saves

 

you use

 

you

 

as

 

so

 

a platform?

 

much time. We do it in Dropbox paper actually. Yeah, just cause it's like basically markdown. And we did that because we wanted to unify it across all of the... like the design department, the content department, and client services. So, you know, I was sort of tempted to put it all in GitHub Wiki or something like that, but wanted something that was not necessarily like, needed to be a programmer to do it. So yeah, we do that for all our internal company stuff. Dropbox Paper is pretty good for that.

 

Yeah, I have tons and tons of browser bookmarks, but... Yeah, I know what you mean. You know, I've dealt a lot with elastic search and Apache solar, so I know how the search engines work. And I would love to just get my own internal thing. And I actually, I wish I could remember the podcast episode, but there's a guy who talked about how he created his own internal application for that exact thing. Anytime he wanted to save something, he was, I think it had like a node back end. And I don't remember what his search index was. I'd have to find it.

 

There's

 

I

 

a

 

think

 

few out there

 

I

 

now

 

have it

 

of...

 

bookmarked. I think I have it bookmarked on GitHub. I'll have to look it up. But it was basically his own personal search engine. For all

 

Yeah.

 

this, anything you want to say, something you would stick it in there, and then he could just do a quick search and find what he's looking for. I was like, oh man, that would be so,

 

Yeah, there's

 

so

 

a few of those

 

nice.

 

now, like this idea of mind mapping and it's like your own internal database for just you

 

Yes.

 

as a person.

 

Yes.

 

Definitely worth, if you're that way inclined, it's a really good thing to do, I think.

 

Like what? Do you know anything off the top of your head? Or

 

I

 

off

 

don't

 

hand?

 

know the names of them. I'm like you, I just have a bookmark folder that's just like, you know, I think it's called tools and it's just like all the things I need.

 

Yeah.

 

And then, but I actually, I use my own Stack Overflow account as question and answers because you can, when you write a question on there, you can select, I'm

 

Right.

 

gonna answer this myself.

 

Right, right. Uh huh.

 

And

 

Yeah.

 

I've done that a lot for more complicated things.

 

Mm-hmm.

 

So that's a good one.

 

Yeah, I hadn't thought about that. Or just do your own blog. I've heard, you know, I have blogs on my site and I haven't updated in years, but I've heard a lot of people talk about, you know, if you figure something out, write a blog about it. And then they'll say, you know, down the road, I'll go search them for something. Dang it, how do you do this? And they'll do a search and oh, here's my blog post that I wrote

 

I can't

 

that describes

 

tell you how many

 

how to

 

times

 

do it.

 

I've come across my own stack overflow answer and been like, oh god damn it, I solved this five years ago.

 

Yeah

 

Just forgot about it.

 

Ain't that the truth?

 

What was your number two?

 

I've actually talked about four already, sort of combined them all. Attention to detail, the knowing your platform and your tools and the following the logical steps. The last one for me that I have is the ability to collaborate. There are some people that can work in a silo and just work by themselves, but I personally can't do that. I work at home, but I still and have for 13 years now. But I still like to collaborate as much as I can. I think, you know, my first 10 years in software, I was in a cube form. You know, I was in an office environment. I'm going into downtown Portland. And then a few years later, I started working on my own. And why there's pros and cons to being in the office environment, I think. And the cons are the travel and the, you know, with as much as I eat, having to pack all my food. and stuff like that and being in the office and people have different preferences for temperature and lighting and all that kind of stuff. But being able to have sit next to somebody hey what about this or what about this and sit down and share a screen and learn and be in that same environment together is incredibly valuable. And you know ever since COVID and the great increase in working from home. that has come from that, which was a whole different, true or I won't go down. I've heard, you know, a lot of people are reticent to come back into the office. But what you'll hear managers say over and over is you've really noticed a loss of collaboration, a loss of a lot of the very good things that come with working together in an environment where you can share. and have a literal water cooler, not a figurative one. There's so many more great remote tools from when I first started working, there was barely anything for communication. Now you've got Slack and Zoom and all that stuff. And you can still collaborate. You can have group chats and jump on a video call and that kind of stuff. But you really have to work at that. You really gotta make sure you're using that and as compared to it being much easier when you're physically in the same location. But not only that, you have to be good at doing it. How do you collaborate with somebody? How do you work together on something? There's some people that I can get on a Zoom call with and share screens and look at what everybody's coding. Whether you share your IDE, you know, PHP, Storm, and VS Code, there's way to actually connect literally through your IDE to another one and edit code on their computer. Whatever tool you choose to use, something to be said for the person. There's some people I can do that with for hours, like I did yesterday. There's some people that will drive me bonkers after half an hour and I can't do it for too much. Right? So there's skills to doing that. I think one, having been on both ends of this, for instance, if you're looking at somebody's code, one person's gonna be coding and one person's gonna be looking, right? If you are looking at somebody's code, be patient. If they make a typo, don't be on them a half second later and say, oh, you made a typo there. Give them a little room to breathe, give them a little room to think, don't hover. Conversely, If you are the person doing the typing and the coding and somebody's looking over your shoulder, be willing to, you gotta listen to what they have to say. Maybe they're gonna see something you hadn't thought of. Oh yeah, that's a good idea. You gotta be willing to take, but when you're on the viewing end, you gotta be willing to be a little patient and give the person a little room to breathe, to think, to function. So that's just my experience on collaborating. But. To get back to them, I guess my original point is one, you have to be willing to do it. You gotta be willing to hop on a call, hop on a Zoom, whatever you're gonna do if you can't solve a problem. Be willing to say, I can't figure this out. Can somebody help me? Don't be too proud. But at the same time, like Drew said, don't do it too soon before you've tried to figure everything else out on your own. You know, I... used to have a gal that would come to me when I was a project manager and she was doing tech support and she would come to me and say, I can't figure this out. And I would say, what did you do? Well, nothing. And I had to seriously restrain myself from strangling her after it happened five, six and seventh time and say, okay, we'll try this and this and this and she'd go back and do it. But if you're coming to somebody say, Drew, you mentioned this earlier, try everything. give it a shot and then go to collaborate, then go to look for help. So I think I've meandered all over the place. Anything to add on collaboration there?

 

I think it's a really good point and it's something that I continue to sort of work on myself as well because I'm not sure I'm the greatest at it. I tend to get frustrated easily with some of that stuff as well. But I think being kind of aware of your own sort of weaknesses helps a lot just in general. So you want to be... I try hard. I think paired programming remotely is... one of the most frustrating things that you could do. In-person paired programming is one of the more fun things you could do and you learn a lot. The in-person side part of it is really, I think, very hard to replicate digitally. The ability to sort of sit down, program, get up, walk to a whiteboard, write something out, sit down, do it, it's very underrated for me personally. I get a lot out of the doing it together part of it and learn a lot that way. I think when you ask for help, you want to be aware of you're like deep, deep in this problem now and this person you've brought in knows nothing. So you kind of want to start with a good overview.

 

Yes.

 

Here's what I'm trying to do. Here's what it, like if you're building something, here's what it should look like. Here's what it actually looks like. Here's what I did. Here's what I tried. thousand feet view and then get down and down down. Don't just start at the down, the granular little detail because it's really hard to kind of understand what, you know, you're trying to solve. So that just like reading in the person that you're asking for help is a good way to approach that stuff. But then if you're working on something really complicated, I think it's really good if you can get in the same room together for sure, personally.

 

Yeah, one of the best examples I was given that I, from somewhere else that I can apply to this came from the EMS world. So in emergency medical services, a lot of times you'll be out in the field if you're on an ambulance or even on an engine. And you're helping somebody and you will have a sticky situation that your protocol is required to get approval. And the term that we'll use is called MRH, Medical Resource Hospital. So what that means is there's a designated doctor at one of the hospitals that's on call for medics out in the field. And. He's a busy guy, he's going around, he's taking care of patients, he's got a phone on his belt or her, you know, whoever. And you'll call a very specific number. And the way I was taught to do this was to have all your ducks in a row and say, hello, this is paramedic so and so from such and such a fire department. I'm on scene here, I have this and this and this. this situation, I want to do this and this and this. What do you think? And if he agrees to it, they say, yes, go ahead and do it. And you've got your approval. If not, he'll say, well, no, don't do that, do this, something like that. But the point is, you've got a very busy person and you're time constrained and just have everything laid out. Here's what the situation is. This is what I wanna do. What do you think? And to me, that applies perfectly to

 

Mm-hmm.

 

this type of environment where you're calling maybe it's a supervisor, maybe it's a more senior developer, maybe it's just another developer at your level, whatever it is, being able to have all your ducks in a row laid out and say it that way is going to be, people are going to be more willing to help you and happier to help you if you do that versus coming to them and saying, sorry, I'm stuck. I don't know what to do. Where can I look? Okay.

 

Yeah, the flip side of that, not maybe the flip side, but I mean, that was a great example. But the, another thing to be aware of is the multiple questions, you know, like nothing is more annoying than getting hit up every 10 minutes.

 

Yes.

 

You know, so

 

Yes.

 

batch your stuff, you know, like, okay, can, do I need to solve this thing right now? Or can I save this up because I know that I'm gonna be, probably have three or four more questions by the end of this. So I'll come to this person that's gonna help me with three or four questions, and not just one every 10 minutes.

 

So

 

That's...

 

in coding speak, bring in array instead of separate functions.

 

Exactly.

 

Ha ha

 

Yep,

 

ha ha.

 

exactly. Cool, well, I guess I'm just left with my number one,

 

We're

 

which,

 

number one.

 

yep,

 

We're number one.

 

which I think is a good thing to sort of wrap it up here with, is I really... I think people need to just get in over their head more often. Just take on something more complicated than you're comfortable with. And obviously you don't want to do this in a professional setting where your failure is going to cause real problem. Nothing is worse than the person who is like, I'll do this really hard thing and then they just can't, there's no way they were going to ever do that and now you've just created more work for everyone. So you certainly want to be aware of your own sort of limitations when there's something on the line. But my point is more, outside of that, take on something that you're not comfortable with. So a good example, if you're trying to get into programming more or you're stuck at a certain level and I really want to be the person that can take on these more challenging things, is whatever... Like in my world, that's building complicated websites. Go on a website, there's this website called Site Inspire and it just lists cool websites. It's like a portfolio of cool websites. Go on there, find a website you like and build it. Just clone it. Don't necessarily inspect their source code and just build it one for one, but just look at it and say, how would I build that? And build it. That would be a really good thing for most people to do because as a mid-level developer, you're kind of more tasked with building certain parts of things, not a whole thing. So if you wanna level up to the point where you can build a whole thing, best way to do that is jump in the deep end and build a whole site. Or I would like to like, e-commerce is something I wanna get better at. Well, go and do it. There's no reason you can't. So I think... There's this philosophy in management, which has kind of sucked for me to learn as someone who has a bunch of employees, is generally you rise to the level that you suck. And so the

 

Hahaha!

 

idea of that is I start as a programmer. Oh, he's good. You know, that person's a good junior programmer. All right, great. We'll give them more responsibility. You get promoted. Oh, that person is a good programmer. you know, they can handle these bigger challenges, we'll give them bigger challenges. And then you get to the point where you did this bigger challenge and you failed at it. You'll never get given a bigger challenge again. So now you're just stuck at that level that you, like you've risen to the level of incompetence and now you'll be stuck there because no one will give you the next harder theme because they don't think you can do it. And so that, that's really bad in a management sense when it's like, you know, you see people just get sort of like project manager just gets risen to the point where he can't handle it anymore and then he'll be stuck there. And so if you find yourself kind of stuck at a certain level, the best thing you can do is like prove that I can go to the next level. And oftentimes you won't be given that professionally. You'll have to like do that on your own to kind of up level. So do that. I think that that is something that a lot of people would benefit from. And I know myself. benefited from that a lot, you know, just like build the parachute on the way down.

 

Well, I think it's unfortunate, you know, if what you say is true about somebody who's failed at something and then they're stuck there.

 

Yeah.

 

To me, that says more about the bosses than it does about the

 

Yeah,

 

person.

 

it does. It

 

Because,

 

does.

 

you know, when do you learn the most? Do you learn the most when you did everything right the first time or do you learn the most when you screwed up and effed up and realized that, hmm, yeah, I shouldn't have done this. I should have done this better. I could have done this different. You know, that's embedded. You're gonna learn so much more from failure.

 

Yeah.

 

You know, I heard a classic example one time Don't know if it's true or not, but to me it illustrates the point very well About a guy owns a small plane. He's a pilot, you know little individual pilot and so he goes up and flies one day and While he's flying So I don't remember what the detail is something goes wrong in his plane and it's because the ground crew member who checked out his plane screwed up and missed something didn't do it again and So the pilot is able to land again. He's able to overcome whatever the issue is. And he comes back and he lands. And the ground crew member knows what's going on, knows he's screwed up. And he's just terrified, getting ripped a new one, or maybe fired, or something like that. And the pilot comes down and he says, I want that guy taking care of my plane next time. Why?

 

Hahaha

 

Because he knows the guy learned from screwing up, and he will not make that mistake again.

 

Yep.

 

So anyway, little

 

No,

 

side

 

you're

 

tangent

 

right.

 

there.

 

It's an important thing not to, like in the organization, is to allow people to do that for sure. So, I mean, a quick little story of my own failure. When I, it was my first job out of college, I was working for a... on Wall Street in New York doing cloud computing for like hedge funds and banks. And I was just like the data center guy. Like I was so low, you know, I was my first job. So most of the time I was in a room with no windows and no humidity, like these big data centers in New York, installing like servers, you know, just in a rack. And installing is put it in a rack, screw it in, plug it in with power, put in a network cable, job done. You know. And I remember that there was this big server thing that we had to install and it had to be plugged in to power and network and tested around the world. So there was like four or five teams around the world all sitting there just ready to start setting up all the systems, make sure it's all connecting, blah, blah, blah. And step one is Drew, little old Drew has to take it out of the box, put it in the rack, plug in the power. plug in the ethernet and then everyone else can do their jobs. So I open the box, pull this big rack thing out, put it in, plug in power step one. You know, I'm basically going through the checklist. Step one, power in. And I plug the power in. And a lot of these server data center stuff, they have like redundant power supplies. Plug in the first power and it just like goes, just makes like a tick noise. And I'm like, that's weird. Next one, plug it in. Tick noise, like, that's weird. and then no power, nothing turns on. And now I'm like, I realize, ah, the server can switch between 240 volts or 120 volts, depending if it's being installed in Europe or in

 

Ha

 

America.

 

ha ha!

 

And because the company I worked for was English, it had been sent over to England and it was set to the wrong voltage. And so I blew both

 

You blew

 

power

 

it

 

supplies.

 

out.

 

just plugging it in, right? Step one, this idiot plugged it in wrong. And I panic and I send an email, like this is back in the Blackberry days, saying like, a bunch of curse words, I blew it, you know?

 

Literally.

 

And, yeah, to my company. And I replied all. So it went to like a whole bunch of people and it was just like doubled my failure. Anyway, so, I'm very, ever since then... I am very scared of reply all and I always check the power.

 

Oh my God, that brings back a story. When I was in college, I did construction. I built houses and apartment buildings. I was the framing, on a framing crew. And I had a boombox, okay, if you remember, this is late 80s, so if you know your big boomboxes, you know, portable radio players, cassette, cassette boombox, so that dates

 

Nice.

 

it a little bit. This is right around the CDs that had been coming out. Anyway, and so I... you know, I'm wanting to listen to music, so I took it to a construction site. Well, it was a 110 volt thing. So not thinking, I plugged it into the nearest cord. Well, that was a 220. Turn it on, pop.

 

Yep.

 

And that was last of my boom box that I had worked so hard to save for. I worked a summer job and saved up and I loved my boom box. And I took it, I just blew it out. Pop. I can still remember the sound. It was so funny.

 

Yeah, so you have to be able to fail. They didn't find me, which was good. But

 

You Bluetooth servers.

 

I blew up just a giant thing. Yeah, anyway.

 

Oh, that's too

 

So.

 

funny. All right, so I think we've covered all of our items. If you want to be an excellent programmer, just follow our advice and you got it made. So

 

Easy.

 

easy, easy as pie, right? All right, so let's move on to picks. Picks are the part of the show where we get to talk about anything we like that might interest this. It could be tech related, it could be non-tech related. Yeah, so I'll go first. First of all for those of you watching on video. I wanted to make one point my shirt here says PETA What you don't see underneath it is that PETA stands for people eating tasty animals So hopefully you're not offended if you're a pet person, but I love my PETA shirt second is My dad jokes of the week. It's been a while. So I've had a few built up that I'll just go somewhere my recent favorites so I actually have a Oh, dang it, I need my sound effects here. Wrong mouse, wrong mouse. When you got two computers and two keyboards and two mice, you get confused sometimes. So I actually have a statistic joke, but it's not significant. If you know anything about statistics, you'll get that one quickly. So the other day, my wife texted me and she says, what does IDK stand for? And I replied, I don't know. She said, dang, nobody knows. IDK, I don't know. Anyway, and then finally. Mouse, mouse, come on, work mouse. Okay, so, couple questions for the day, deep things to ponder. Number one, is a person who takes care of chickens called the chicken tender? right,

 

Should

 

you're

 

be.

 

tending to chickens, right? And then second, before electricity was discovered, what were electric eels called? Deep

 

There's

 

thoughts

 

gotta be an

 

with

 

answer

 

Steve.

 

to that actually, doesn't there?

 

I know I was thinking about going and looking that up on Wikipedia. What were they called before Benjamin Franklin discovered

 

Yeah.

 

electricity, right? So anyway, those are the dad jokes of the week. What do you got for us, Drew?

 

Nice. I can't, no jokes, but my picks, really interesting thing I came across the other day, it's CSS scroll timeline. It's a spec, it's not, can't really use it yet. I mean, you can use it behind flags and stuff, but it's not ready for production or anything like that. But it's CSS animations instead of tied to... a time, you know, like normally you run this animation over one second or something, it's tied to the scroll position of the container, which up until now has only been able to be done in using JavaScript and is super annoying to do it generally. And in fact, if you try and do stuff like that in Chrome, in your console, you'll get a warning being like, we see you're trying to do some scroll-based animations and we recommend against this. It's one of the worst performing things that you can do. But Unfortunately, and especially in my line of work, it's one of the number one things we get asked to do, you know, these parallaxy pages or things tied to scroll and clients love it and it looks really cool and it's the worst thing in the world to actually program those sites. But this looks really interesting, scroll timeline, and I hope it could really make things easier for us, which I'm excited for. So that was one that I looked at. and we'll put the link in the show notes. And then the other one was a View3 animation library called anim... I don't know how you would say it but it's animxyz animxyz.com

 

Animixes.

 

animixes animxyz.com amyxyz

 

That's it.

 

and it's uh... just a really useful little library of composables and things for and even like it even has like components to make stuff work. Kind of very similar to the view transition component but it's in favor of that and then you can tell it to do a bunch of things. Very very interesting and you should check it out if you're doing a lot of animation stuff. Looks good.

 

Yeah, that's one of my weak points in CSS is animations and transitions between things I really would like to get better at for sure. So yeah, anytime there's a tool that makes my life easier, I'm all for that.

 

Yeah, especially this one works in view and they have a react version as well.

 

Okay,

 

And it looks really good.

 

cool. Alrighty, so with that, we will wrap it up. First of all, I'd like to say thank you for the studio audience, you've been awesome. Thank you. Thank you. And thank you to world traveling Drew Baker for coming back on the show. He and Luke are the Aussie element of views on view. Just the accents alone make them worth having as guests, but it helps that he has good looks and a lot

 

Yeah.

 

of knowledge on view too. So

 

Thanks, Dave. Anytime, man.

 

anytime. All right, so with that, we will wrap it up. Thanks for joining us and we will talk at you next time.