Coming Up With Project Ideas

About this Episode

In this episode, the panel dives into the nuances of learning and developing as a coder. They discuss various approaches to learning, such as "committing" code every day, even if it's just a tiny chunk, to build fluency and comfort with programming. Mark mentions the trend of long online tutorials aimed to take someone from "zero to master" and the varied success of these methods. However, they stress the importance of building foundational skills first and note the ever-increasing capabilities of technology, stating that if you can imagine it, you can code it.

As the conversation progresses, they focus on managing one's learning through their work environment. There's a discussion on the benefits of aligning one's professional tasks with personal learning goals by steering management toward mutually beneficial projects. They also discuss various approaches to learning from online video tutorials, with some arguing that replicating a project step-by-step doesn't provide real value. In contrast, others see merit in iterative learning, especially when the tutorials are feature-focused. The panel then discusses the importance of balancing this with hands-on coding, experimenting on personal projects, and checking out the latest documentation to stay updated.

They conclude with an emphasis on adequately utilizing video tutorials and online resources for optimized learning. While video tutorials are helpful, they aren't the end-all solution; referring back to community insights and updated documentation is crucial for growth. They also appreciate the duality in learning methods, acknowledging that there's a time for guided learning through tutorials and a time for experimental, hands-on coding. Overall, the episode serves as a comprehensive guide for developers at all levels, highlighting that the journey of learning and growing in coding is ongoing and multifaceted.

Transcript:

DAVID: Hello and welcome to the Acima Developer podcast. I'm your host today, David Brady. We have a small panel with us today. We've got Eddy Lopez, Kyle Archer. We've got Mark Hymowitz. It's going to be a fun, tight little show. Today, we want to talk about picking projects to learn from. Or how do we pick personal projects? Where do we get the ideas for that? I will just open it to you guys right off the bat. How do you guys pick personal projects? Or what problems do you have?

EDDY: When I first started working with the idea, well, actually, before I even got into the tech industry, right? Here at Acima, I started to discipline myself and be like, hey, I want to learn programming. How can I better rearrange my habits so I can learn and hit the ground running when I do get hired on, et cetera? When I get good enough to convince someone to hire me [laughs].

And my origins when I started learning, I was like, cool, yeah, let me pick up random projects, you know, let me watch a tutorial on YouTube, you know, about someone who is walking me through on how to implement an app on a certain framework, et cetera. So, that was my origins. And I was extremely motivated to do that.

Now, when I was finally able to progress to the point to where I was able to convince someone, "Hey, yeah, bring me on the team," you know, and they accepted, the majority of the bulk of the learning that I have had up to this point has just been business needs, right? Like, "Hey, Eddy, I need you to implement this. Hey, we need this to work this way. Can you make the changes?" Under pressure [laughs], I worked pretty well, right? But suddenly, as far as having personal projects to work on, et cetera, has kind of dwindled to better cater to specific business asks. So, the bulk of my learning has been on the job versus personal projects, if that makes sense.

MARK: For me, the first part of personal project was just creating something that didn't exist. Like, my first personal project wasn't some elaborate code or anything complex. It was, hey, I wanted to make an EPUB file of an online book because you can read the book online, but there's no offline version of it. And they didn't sell a paperback or digital copies. My first project was to, hey, how do I create an EPUB file? How --

DAVID: Nice. EPUB, that's like send it to your Kindle, right?

MARK: Yeah, it's a book format just like PDFs and other file formats that you can import into Kindles, iBooks. It's a very generic book file that you could just import and just start reading from. So, my first project was like, hey, I wanted to create an EPUB file for this book. But I didn't want to make it for everything. I wanted to make sure I properly broke it down into multiple EPUB files for each volume of the book. And from there, I started going, hey, I want to automate this. I got into Python and just learning web scraping and trying to automate my process of getting the book from the website and turning it into an EPUB file so I can just read it offline.

And that's been my kind of goal since, like, personal projects: build something that doesn't exist. My current personal project is I have so much media now. I can't keep track of where it all is. So, I'm trying to create a web app that can organize it and then be able to use that web app both on my phone and my laptop while having a universal experience.

DAVID: Back in my day, back when the dinosaurs roamed the earth, there was a thing that we kept in our kitchens called a recipe box. And it was just a thing the size of, like, a stack of three-by-five index cards. And when the first PCs were coming out in the '80s when I was a kid, the first program we all went off and wrote...well, the first program was always "Hello, World."

But, like, the first, like, real big program we always wrote was, hey, let's put recipes on computers. And we were able to, like, transcribe all these recipes into computer format and put them on a floppy diskette and then lose them because floppies were wildly unreliable. But, you know, that was educational as well.

Mark, you said something that caught my attention. You came up with a problem. Like, you had the idea after you had a problem. And one of the things that you will hear in the open-source community over and over and over is scratch your own itch. And I think you've nailed that right on the head, right? Find a problem, find something that bugs you, and then figure out how to solve it.

MARK: Exactly. Like, no matter how much I search online, I can find, A, there's a web app for just tracking one thing, or, hey, this is the greatest news app for learning all the new media you want. I just want one app that I can just index to all these things and say, hey, I'm tracking all these things. Where do I go to find it? I have five apps on my phone. I have 13 bookmarks in my browser. I have Amazon and Apple. Where am I keeping all this stuff?

Because I want to make sure I don't fall behind or forget about it because there are so many things I enjoy, and then I just lose track of them and forget about them. And then I come back, like, months to a year later and be like, oh, I remember that. I liked it a lot. But I'm, like, so far behind now I don't want to...I'm a little scared to actually jump back into it again. Hence, my current project: something that indexes my life so I can actually remember where everything is.

DAVID: I can confirm to you that that is a common itch. And, actually, what I'm going to say I'm going to say this very carefully. I have scratched that itch many times and have never been completely satisfied with my own scratching of that itch. I'm not going to tell you that, "Oh, good luck with that. You'll never solve it, da da da." No, no, no, you're going to learn a ton coming up with partially great solutions to that problem. Pick an itch that's just chronic, right? And just find a way to scratch it, find a way to scratch it, find a way to scratch it.

I gave a talk at a conference years ago about building a planner page. Like, I used to work for Covey Leadership Center years and years and years ago. And so, I designed my own day planner system off the back of that, and I would print them out. And every week, I would print out a single eight-and-a-half by 11 sheet that had the week's plan on it, and then I would fold it up and, you know, stick it in my pocket, and down the road I go.

And I ended up writing a thing that would open up a Visio document. This was, like, a Windows automation script that would open up a Visio document, fill in all the dates and stuff like that, and then send it to the printer. And it would run every Monday morning, and I would have a day planner for the week. And then, a few years later—I got into Perl at the time—I automated the Visio scripting thing with a Perl script. A couple of years later, I got into Python, and I just ported it straight over from Perl to Python. And then, when I got into Ruby, I ported it from Python to Ruby.

And the interesting thing was is I had written the original version in Perl. And I had not used any object orientation. I had not used any object messaging. It was all just start at line 1 and just go for 1,200 lines of manipulation code. At some point, I stopped printing a Visio document, and I switched to drawing a PDF document myself by hand because [chuckles] Visio quit making Visio. It kind of sucked. But that's the problem with having a project that lives for 20 years, right? It outlives the architecture it's built on.

So, I got to a point where I was writing this thing in Ruby. And I was literally trying to port it to Smalltalk, which is a very object-oriented language. It's very hard to write imperative scripts in Smalltalk. And I couldn't do it. And it's because I had written this thing in an imperative style so many times that I did not know how to do it in object-oriented. And so, this was, like, a super great learning curve for me or a way to approach a learning curve. And this is a really subtle thing of, like, how do you pick a project to learn? The question is, what do you want to learn, right?

When I ported this from Python to Ruby, I had two goals in mind: one is, I wanted my stupid planner sheet to work again. I just needed to solve that itch. But the other thing was I wanted to know how to automate this from Ruby, the same kind of automation that I was doing from Python. And I did not want to know how to solve the problem of drawing a planner sheet. That was solved. That itch was well scratched.

But now I wanted to learn this new language, and I wanted to learn this automation system. And I wanted to have the planner sheets working again. Those were the itches that I wanted scratched. So, it's a really important thing to think about what exactly is the itch that you want. And sometimes, finishing the project isn't the itch. Does that make sense?

MARK: I know exactly what you mean. Besides, like, my current project, I've had several other projects over the year where the itch was just thinking of the project or just starting out some of it and then just getting a bare-bones thing working. Like, there's many different phases to the itch.

DAVID: So, okay, I have a trick question. And that kind of sets up everyone to understand that this is a trick question. But I'm going to ask it with a straight face, and then we can decide...we can get into answering it, like, straight. And then, we can get into, like, why it's a trick question and what is the trick here. Big project or little project? Should you tackle, like, oh, hey, I'm going to go learn this web framework, and I'm going to do full-stack JavaScript to database and back again, or should you take a little, tiny thing like, oh, hey, I want to boldface the titles in all of the EPUBS in this directory?

MARK: I'd say little projects are better. You have incentives of thinking, hey, this isn't a lot of work. You can get this done over a period of time. But you should try and have an idea that have these little projects stacked on top of each other or expand on each other so that, eventually, it becomes a fairly big project. But you never thought of it as a big project. You always thought of it as many small projects.

DAVID: Nice. I like that answer. You've got half of the trick figured out. When would you want to tackle a big project?

MARK: I guess that depends on, like, what the problem is I'm trying to solve.

DAVID: The trick to it is that it's the exact same answer, just in the other direction, right? You can take on a big project. How do you take on a big project? Well, you start breaking it down into smaller and smaller things, right? On one end, you can start small and stack your way up. On the other end, you can start big and crack your way down.

I tackled learning Ruby and Ruby on Rails in, like, 2005 because it looked like a really interesting language. And I was making a good living as a PHP programmer, but I hated PHP. And I thought Ruby looks like a really interesting language. I want to get paid doing this. So, I jumped straight into; I'm going to learn this whole darn framework from tip to tail and just grind my way all the way down through it and see how far I can get. So, the itch there was I wanted a job. Does that make sense? I wasn't trying to learn how to stack up bits and bytes. I was trying to learn how to get paid.

MARK: I understand that feeling. But my experience is, like, with a school, like, I had a teacher who gave us one large project, but instead of having us build the whole project at once, she would make us build each portion of the project over the quarter. If you fail to make even one portion of the project, you were going to fail that class.

DAVID: Wow.

MARK: Because you just couldn't build on what you had achieved.

DAVID: Yeah, that's a great way to teach someone how dangerous the waterfall process is [laughter]. You tripped in week one. Congratulations, you're going to flunk the entire year. That seems a little excessive. Although I guess that would be an important lesson, wouldn't it?

MARK: Yeah. Anyway, how do you guys think of project ideas?

KYLE: Well, as far as coming up with, like, project ideas, for me, I look at kind of just issues that I run into in my daily life, maybe not just issues but just, like, things that I think could be more convenient or make my life easier for me. Like, you know, my dream project...I worked in restaurants for a really long time. You know, I've used ten different POS systems, you know, point of sale systems for selling different stuff. You know, there's a nickname for POS, but we won't go into it.

But, you know, dream project: I've always wanted to make my own POS just because, you know, I think I have valuable insight just working in the industry. So, I think there's at least some part of me that might be able to do some things better than, you know, the big competitors: Square, Toast, whatever. Obviously, that's a long shot to dream.

But more, like, reasonable more, like, viable things, I suppose, is I'm really into chess. So, I really always wanted to create some kind of application where it's like, oh, I can record all my chess games and figure out a way to, I don't know, make some algorithm or study some books into my site that's able to, like, tell me where my weaknesses are or, you know, things like that. So [inaudible 12:31] will improve my game. I guess, really, it's just personal things that I think I can improve. That's usually inspiration for projects.

DAVID: Absolutely. That is awesome. One of the best examples of scratching your own itch...I had a friend. He and I had worked in the gaming industry together, the video game industry. And we went our separate ways after leaving that company. And he decided to go back to school. He had been making six figures as a developer, and he went back...because he was going back to school, he had to work part-time, and part-time pays entry-level. So, he was making, like, seven bucks an hour doing data entry.

And his job was to key in all of these checks, like, literally paper checks that people were writing with dollar and cent amounts. And he had to balance up the till at the end of the day with, you know, like, typing these 150 check amounts. And he would be off by a penny, or he would be off by 11 cents somewhere. And he'd have to go back through all these things. And he was on, like, a Windows, you know, like, Windows 95 or Windows 2000, just a desktop and with, you know, no tools, no dev environment, nothing. But he's like, this seems like a problem that a computer would be really good at solving.

And so, he went home. He wrote a little application in Visual Basic that let him key in all of the checks to copy and paste them because he could copy them out of the system that he was entering them into. So, he would key in all the checks into the system. And he would be off by 22 cents somewhere. And he would select the whole thing–paste it into his app.

And all his app would do is it would just go through every single item and add one and subtract one from every item. It would swap every pair of digits. And after each change, it would add up everything and check to see, you know, do I have the same wrong answer that you do? And if I do, I'm going to show you what mistake I made so that you can go look for it and see if that's the mistake that you made.

And he went from spending, like, 30 to 90 minutes a day tracking down, you know, transposition errors in his ten-keying to just copying and pasting and getting these answers out. And the hilarious bit is, because programmers are terrible at optimizing their time, he probably spent 15 hours writing the application to solve that kind of problem. And so, it was probably a wash by the end of, like, the semester. He probably had gotten those 15 hours back, probably. And if he worked another semester, he probably would have been time ahead.

But I think it was really, really neat for him to spend 15 hours doing something he loved to solve a problem that really pissed him off. And, in a way, it's an immediate victory because he's spending time doing what he loves in order to not have to spend any time doing something he hates.

So, it's not really, like, a 15-hour, you know, loss against a half an hour gain. He's, like, the very first time I pasted this in, and it found my error right off the bat; I sat back and pumped both fists in the air and just went, "Yes!" And everybody was looking at me like, "What? What's going on?" He's, "Oh, never mind, I just found what check I messed up. I'm off by 22 cents. And I had keyed in a minus 11 instead of a plus 11, and that's why I'm off by 22." That kind of thing.

I think it's a lot of fun to, like, scratch your own itch. Find out what bugs you because when you're done with it, instead of going, "Oh, I can't believe I spent all this time working on this stupid thing, and now I'm just happy that it's over," you're like, "Ah, I got to spend all this time learning this really cool thing. And now I have this cool tool." So, it's like you're doubly ahead instead of, like, just trying to struggle to break even.

MARK: What's also nice is having that tool to look back on and whenever you're, like, working in the same language again, and going like, how did I do that again? Oh, right, I built that within my app. Let me see if I can find the code.

I once interned at a place where they had me write the same program twice, once in Python, once in...I'm forgetting the other language. And I still had a copy of both programs in my GitHub repo. So, I was referring back to the Python version, going like, I definitely did this before, and the documentation hasn't changed. But, like, how did I do it in Python? That helped me understand the API a lot quicker than trying to relearn the entire documentation again.

DAVID: You've fallen neatly into the trap that I have set for you. You have stepped perfectly into a segue to something that I wrote down before coming on the show today, which is that I love really small tactical learning. Like, I love to just sit down and go, you know, I don't have a built-in sort of method. How am I going to do this? Or how do I do this thing in Python? That kind of thing. I know how to do it in Ruby. How do I do it in Python?

So, there's two repos that I keep on GitHub; one is just called bin. And bin is always in my path. And anytime I need to do anything from the command line––if it's more than 20 characters long or it's hard to remember, I will write a script and put it in there. And my scripts do two things: one is they do the thing I need to do, and the other one is they print the thing on the screen the way it needs to be done.

So, I see the correct command fully typed out. That way, if I ever don't have my script folder with me, I'm like, oh, yeah, yeah, I remember. It's dash dash force, or whatever, right? Whatever the options are to that particular script. And so, that's like, super, super useful.

And so, bin is this place with tiny, tiny solutions, right? I literally wrote a thing to remember when I create a pull request on GitHub. I wrote a thing called git set PR. So, I can go in, and I can say, okay, this branch is PR 10902. Then I wrote two more scripts; one called git get PR, which then just says, oh, you're in this folder, and you're on that branch. Yeah, you made a pull request for this, and you told me it was 10902. Go nuts.

And then the other one I wrote was because I don't want to have to open a browser and type in github.com, slash the name of the company slash name of the project. The computer knows all that. So, I wrote a thing called git open PR that opens up the git config, finds the fetch URL, where is it on GitHub, what's the repo name. And then just puts in the slash pull and then the PR number, which was recorded earlier. And then it tells the computer, "Open this in a web browser, please." So, I type git open PR, and I'm in a webpage with the PR, super handy.

And that's just something that's, like, bothered me off and on. And I got that working, like, yesterday at work. Like, we were in the middle of, like, deploying three PRs, and I was switching back and forth between them. And I'm like, this is annoying me. It's making me crazy. I'm just going to switch back and forth between these. And so, [inaudible 18:56].

So, bin is where I keep tiny, tiny, little solutions. But, Mark, you nailed the other side of this. I keep another repo called scrap bin. And scrap bin is where I store fragments or scraps. So, scrap bin is where I'm going to have a thing that says, how do I get the current date stamp in Python? Like, in Ruby, I just know it's time dot now dot star f time. How do I do that in Python? Oh, it's import date time, date time, dot date time, dot...and down the road, you go. But you have to know what module it's in.

And if you forget the module, if you're coming from Python to Ruby, you might want to make a little scrap that says, hey, here's how you get the date stamp, and you open...oh yeah, it's time dot now. Okay, cool. That's what I keep in scrap bin is, like, oh, how do I loop over this thing? Or how do I...it's like Python doesn't have a detect method. I might be a liar about that. It might not be detect. Like the ability to loop over a collection and find the first thing that matches some criteria.

And I want to say I'm going to get flamed in the comments. You know what? I need to learn, so teach me a lesson, people, if you're listening to this. I think in Python, you have to give it either like a lambda, or you just have to write a loop and loop over the collection, and if you find it, then bounce out. And that's how I ended up solving it, as I recall. This was a couple of weeks ago on the Python team.

And I love that Ruby just lets you say collection dot detect or collection dot find, and you give it a block that matches a condition. And that's great. I love it. It's super easy. But I couldn't remember how to do it in Python. So, I ended up writing these four lines of code loop every time I needed the stupid thing. And once I've found a good way to do it, oh, I take it back. I did find a way to do it. You build an enum, and then you call next on it. That's right.

My point is that's in my scrap bin. I don't have my scrap bin open, or I would have known this off the top of my head, which, by the way, is the value of the scrap bin is: you don't make yourself look dumb on a podcast. But yeah, anyway [chuckles], the point is, I have two repos: one for solutions and one for fragments of solutions, itches that I have scratched in the past. It helps you build the next back scratcher.

MARK: You're reminding me of my...Slack gives you your own channel of just you talk to yourself. And I've been using that as my scrap bin where I'll post any useful commands or pieces of information that I need to remember. Now that we're switching teams, I need to export that entire scrap [laughs] bin into, like --

DAVID: Nice.

MARK: A git repo. You just reminded me of another scratch that I itched recently. It was a...I had a pull request that was, I don't know, 50-60 commits long. And every time I rebased it, I was so concerned about things getting overwritten because of all the merge conflicts that kept popping up every time. I ended up writing an alias to squash the entire branch into one commit, destroying the history, but it put all my changes into a single commit.

So, every time I get a commit list that's too long, I will squash the branch. That way, it's just all right in that nice, one commit. So, even though it gets rid of the history, it gets rid of, like, all the conflicts or at least most of the conflicts that you have when doing your rebase. And the other concern, I added conditions to it to say, hey, if on master, if on develop, if on main, abort because I don't want to be the guy responsible for erasing our entire [laughs] Git history.

DAVID: Yeah, I've got a thing in my bash prompt that will check to see what is the current branch that we're on. And yeah, in my bin folder, I have a script called git current branch, you know, git space current dash branch, and it tells you what the name of the current branch is. And there's a peer script in my bin folder called git main that gets the main because five years ago, the master branch was just master.

And that's become problematic in some cultures here in the West, especially because it's problematic language. So, there are people that are switching to a main branch called main or a branch called develop. Well, now you have this problem that, like, what do we call the master branch, right? If we can't call it that anymore because, problematic.

So, I wrote a thing called git main that figures out what is the name of your main branch. And when I put the git branch in my bash prompt, if it's the main branch, it will bold white text on a red background, like just a warning label in your bash prompt letting you know, hey, you are on the main branch, right? Have a care. Go cautiously. But if you're on a story branch, it turns green. And I find this, like, super, super helpful, as, like, just a little warning flag that says, hey, maybe don't squash the entire branch history right now.

MARK: [laughs] Yeah.

DAVID: There's two fragments that I ended up writing. One is called git is clean, that checks to see if you've got any files just hanging out modified and not committed. And a lot of my git tinkering operations, the first thing they'll do is check to see, do you have modified changes that are staged or that are modified and not staged? Maybe you don't want to remaster this branch right now. Maybe you don't want to pull in everything and rebase the main branch back into this. You're going to clobber something important. So, I will use that git is clean all the time.

And yeah, and then the other one is, are you on the main branch? If you are, maybe don't do the thing you're doing, or if you do, you need to rerun this script again but run it with dash dash force or dash dash––I know what I'm doing. Let me shoot myself in the foot.

MARK: [laughs]

DAVID: Force is a lot simpler to type. By the way, for the people that have gone to their keyboards to yell at me, it's a list comprehension in Python that then returns something that's enumerable. And if you call next...you build a list of all the things that match the criteria, and then you call next on it, which gets the first item from the list. And I believe that's lazily evaluated. So, it's not actually, like, doing dot map dot first.

It does actually lazily evaluate through the generator, through the list comprehension to find the thing that you want. So yeah, you say item for item in collection if, and then you give it the matching criteria. And then, you wrap that whole thing in a call to next, which returns the first one. And I got that by looking it up in my scrap bin just now. So, there you go.

MARK: It feels like we're going off-topic because, like, our --

DAVID: Oh, yeah, yeah.

MARK: [laughs].

DAVID: The whole point of, like, learning projects is to get off into the weeds, which I think is great. But you're right.

MARK: [laughs]

DAVID: Let me hang a lampshade on this exact problem. Sometimes, the thing that you want to learn is a meta thing, right? So, you want to take a project you already know and use it to do a thing. So, like, if you want to learn how to do TDD, or if you want to learn how to...I did a thing a few years back where I wanted to get in the habit of committing code every single day. Because I was in the habit...at that point in my career, I was in the habit of authoring 1,000-line commits, which meant that I would go for 2,3,4 or 5 days without committing anything to the source code repo.

Now that we're on git and everybody's got kind of a tiny process, and we're like, you know, we're deploying things that are, like, five-line code changes and that sort of thing...but 10-15 years ago, the tools that we had were much more unwieldy, and it made a lot more sense. It was a lot more efficient to just drag a lot more work in one go. And so, I had to train myself to make tiny commits. I had to literally break the habit because if you're going to do something big, you can keep pushing off some important part of your commit. You can keep pushing it off to the end.

And by saying I have to commit every single day...and I'll tell you what, I spent better than half of the days in that experiment timeframe frantically writing code at 11:45 p.m. because I had spent all day pushing something important down the line, right? Sorry, I'm off in the weeds again. But this is kind of the point is that I was trying to learn a technique for how to commit. And so, I just picked a project that I was very comfortable with. Largely, it was my bin folder and my scrap bin folder.

I would go learn a thing, figure out how to do the thing, and then write a five-line thing and, push it up and commit it. And that was my commit for the day, and I was done. And now it's very, very easy for me to write stuff and commit. And it's weird in my development process if I'm not writing commits at least every half hour to an hour, which is fantastic. When I'm on a roll and really cranking code, the commits come every five minutes. Honestly, it's insane. So, the point of that is you can take learning projects in a direction where it's not the project itself that you want to learn.

MARK: Learning can happen in weird and strange ways. One of the most interesting things that I've been seeing now is that there's a lot of online videos saying, "Hey, take you zero to master in X language," right? [laughs] And it's, like, a 12-hour long video. I tried going to a CSS one, and I only got about six hours through before I kind of gave up on it. But you learn so much just getting the basics, learning the cool features they have. And it just causes so many new ideas to spring up in your head.

Even though I'm a developer, I kind of wish I took more user design courses now before I graduated from college. Because I'm now just thinking, like, if I can draw down what I want properly, then there's no way in hell I can't code this. We're, like, at that stage with technology where if you can imagine it, you can definitely code it. Like, there are websites that if you scroll downward, it looks like you're moving in 3D space, seeing stars move around you, and just have amazing animations.

DAVID: When CSS 3 and the 3D transformations came out, there were two things that people wrote and put in the browser that were just amazing. One was an asteroids game where they gave you just a little ship from asteroids, and you could turn and flow and fly it around. But you were shooting the document model. Like, you literally could shoot the title off of the webpage. And then you could shoot the pictures embedded. And the page would, like, collapse. They'd literally shoot words out of the [inaudible 28:44]. It was just weird. Like, why would you want that? Well, because it's cool.

MARK: You're reminding me of, like, all the cool Google searches. Like, if you just search—I think it was monkey bear on Google or gravity in Google—amazing things would just happen to the web page. Like, all the text would fall down spaghetti-wise. -

DAVID: Nice.

MARK: Or it would drift around in space.

DAVID: Nice.

MARK: There's probably [crosstalk 29:06]

DAVID: I like “askew.” If you Google the word askew, A-S-K-E-W, that's a fun one. I had to show this to somebody a couple of weeks ago, and it works on a phone. So, if you're just hanging out around, open up Google and type A-S-K-E-W and hit Enter and just, you know, see what happens.

MARK: Oh my God [laughs].

DAVID: I think Mark just did it. Fantastic.

MARK: [laughs]

DAVID: Circling back around, Eddy, you said something at the top of the call. You mentioned you tend to learn things when your boss hands it down to you. This is something that I was kind of in the same way, well, a little bit in the same way. I've always had just, like, this unnatural fascination with learning things. But this taught me how to kind of manage my manager.

And I'm curious if you've given any thought, like, if you walk into work and you know that you learn things when work gives them to you, have you ever considered steering your boss into saying, "Hey, I want you to give me an assignment that lets me do a thing that we can both agree on that I would like to learn, and you would like to have done"? Have you ever tried playing that game?

EDDY: I have not. But I know that's an option that is given to employees, right? Just recently, we talked about, hey, if you're wanting to work on a codebase from a different team, you're more than welcome to do that, right? And we're open to the idea. As far as me flirting with the idea of doing that practically, I have not, but it would be something to consider, for sure.

DAVID: Absolutely. I learned this from a boss, ironically. I was really passionate about learning stuff, like, on my lunch break. And I was learning crazy stuff that had nothing to do with what work wanted me to do. So, all right, that's fine. I'm just kind of off in the weeds, learning my own thing. And my boss came in and sat down. And she's like, "Okay, so, I've got this really crazy hail Mary just bat poo crazy idea. And I think you're the guy for the job." And I'm like, "Oh, do tell."

And she said, "We've never been able to script our application from an outside language." This was back in 2002. And so, she was like, "I've heard good things about this language called Python. I want you to go learn enough of that language to see if we can embed it and script our application from Python." And so, it became my job to learn Python and to figure out how to hack into it and to, like, compile it into our application so that you could write Python scripts to control the code.

So, I was basically writing, you know, like the Lua console that when you play video games, that you open up the console and type in cheat codes. It was literally that but for a Planetarian controller, which was crazy awesome. And it had never occurred to me to collaborate with my boss on coming up with weird things until she literally walked in and said, "We were in a team meeting today. And they said, 'Well, we got this crazy idea, but we have no idea if it'll work.'" And she said, "Oh, I've got a guy who loves crazy ideas."

EDDY: I have a question. So, a lot of us, when we take inspiration on building an app, do you tend to lean towards something that's more stabilized and uniform in a sense that, like, you'll follow a project where it will walk you step by step to implement something that you're wanting to implement, you know, and then you learn that way? Or do you just start from scratch and you just build it from the ground up, and that's your best method of learning?

KYLE: For me personally, I'd say it's probably, like, a combination of both. I don't see any benefit of just, like, pulling up a YouTube video and copying down a project word for word, bar for bar, because, you know, anybody can do that. You just install something and then just copy exactly what they're writing. But I think having a video like that is helpful because you're able to, like, get a basis on, like, what kind of goal you might be trying to achieve, what kind of project you're trying to make.

And then, given that foundation, I think it's important for you to, you know, experiment. And that's where I think, like, reading articles online and checking out what other people have to say is helpful because you can start with this foundation of a project and kind of customize it and explore, create as many new features as you can. And I just think that's the best way to get exposed to new technologies.

EDDY: Let me ask you this: do you think it hurts you in the long run to watch a video tutorial on how to build something?

KYLE: I think if you watch the video and then just copy everything down exactly, absolutely. Like, you know, I could go, you know, watch a three-hour video on how to make a glorious full-stack application, and then I'll do that six times and then put them all on my resume and be like, hey, look at what I did. Like, these are my skills. And then I actually get to the position, or I get to the interview, and I have zero idea what I'm talking about. It's definitely a negative.

MARK: I'm going to have to push back a little. I've done some of those online projects. And it's like, I agree, doing one large video project is bad. But if you're following, like, say, a learn the language guide where they take one project, iterate through it, or make several copies of the same project and then tweak each one separately so you learn the language, I find those helpful. I've done one of those to learn how the Vue framework works, as well as I did the same thing with the CSS.

So, again, one large project is not helpful, but finding a video that says, "Hey, you're going to make several, maybe a dozen projects throughout this video. All of them are going to be very bare bones, but they're each going to go over highlighting a different piece of code or how something works within this language," I find those useful because then you can actually see, hey, here's a prime example of what this code does, and a bare-bones method of how it's implemented.

KYLE: Yeah, I mean, I think that's fair. I think for learning purposes, it's definitely, like, just going through a video and kind of mocking out the steps going through how, you know, how to actually start doing something; I think that is definitely beneficial. But I wouldn't really consider those to be, like, projects per se.

You know, my definition of projects are more something that you come up with that, like, has some kind of application that is useful to you or other people that you don't just copy online because, you know, there's a million copies of every single one of these videos. You know, there's a million different people who all made the exact same project. So, it's like, it doesn't add any additional usefulness to do the exact same thing. So yeah, for learning purposes, that definitely is true. Following a video would help. But, like, that's just...in my definition of what a project would be, it doesn't quite fit the criteria, if that makes sense.

DAVID: That's actually really well put. My initial answer to Eddy's question was: it depends. And you guys just beautifully represented both sides of the it depends. There's a time when you want to just, you know what? I don't need to scratch an itch. I'm in a completely foreign land. Please show me how to build back scratchers. And that's nice to have. Well, we start here, and we build all the way to here. And it's undirected. I'm not trying to finish anything.

And then, there's other times where it's like, no, just tell me how to get this out of the database and transform it. I don't even need to know how to build a clock. I just need to know what time it is. And those are both, like, really, really useful.

EDDY: I think I've found when working on personal projects myself, I've got this thing where I'm always wanting to use the latest and greatest. So, videos are great for a start, I feel like, but by the time a video is out, it's old information. Some of it will be applicable. But I feel like I have to go to the documentation to figure out, what have they changed? Why is this function not working? Something like that to where may be a good starting spot, but I always refer back to the documentation in the community to be able to move forward.

DAVID: That's well put as well. There was a set of videos called RailsCasts back in the late noughties that were really, really good. Ryan Bates, I think if I'm recalling correctly, Ryan would put together these videos, and he would explain, here's how you do this in Rails. But he would then peel the top off and say, "And here's what you're doing."

And so, he's got...I don't know if it's still up there, but, like, the video that he made that made the biggest impression on me was called “How to roll your own authentication or authorization.” And it was literally how to deal with, like, what Devise or Warden or CanCan what all those things do. And it was super useful because then when we stepped into using Devise or some kind of authentication product, I knew what it was doing under the hood.

And 15 years down the line, there's a different way to do this every single time. But every time I open up those tools, I find myself, you know, saying to myself, ah, this is solving that same problem. The same three problems that we had in 2008 we still have today. We just have a different DSL for dealing with them, and that's, like, super, super useful.

What's less useful is finding a video from three years after that shows you how to solve that problem in a different language that's now too old to be useful and doesn't show you what the underlying problem is. It's like, oh yeah, that's a coat of paint on a different house. And it tells me nothing about architecture, and it doesn't fit the house that I have now. You run into those, too.

That is actually pushing us close to time. We had a late straggler join. Ramses, welcome. We're talking about how to pick a project to learn from. You've got 30 seconds to give us our closing thought. Go for it.

RAMSES: Pick something that you're passionate about or not passionate about, something that you hate, or something that's really monotonous and brings you pain, and try to solve that.

DAVID: We've been talking about scratching your own itch, but picking something you are passionate about and then saying that you hate it, beautifully put. There you go. Pick something you love or something you hate. That's a fantastic way to sum it up. Thank you, guys, for coming. This was a lot of fun today. I had a great time talking with you guys. We will see you in a couple of weeks.