Transcript
‍

‍
The more we learn, the more disconnected we get with the position where we were when we didn't know something. And so if you don't stay in tune with that, it's really hard at times to be like, Oh, this is, I remember what it was like not to know XYZ. Let me break this down in a way that it makes sense to you.

Vibe coding right now feels like that where it's like, Oh, I can build a video game, I can do XYZ, I can have this idea. And then like three months later, everyone's going to be like back to just just do whatever they do so i love it as like the death of excuses if you were using ai as a tool to learn from you would ask why did this go wrong what's the way to implement this what how can i fix this for the future you would understand and not just understand what the error message is saying but you would understand for the future if you ever got the error message again how to implement that solution in a meaningful way if you are not intervening at a level it's impossible to get to where you want to go that's number one but number two ai is great at just building something generically ai is freaking terrible at anything related to maintenance it is not even close to understanding the logic unless you provide it i saw this thing where people were like you want to be in my um daily stand-up discord it's 25 bucks a week i was like that was my exact that was my exact reaction last night when i saw that video on i think it was tiktok if i'm not mistaken and i was like i can't believe what's going on everyone we are back with another one i'm one of your co-hosts of the programming podcast. My name is Danny Thompson.

I'm the director of technology at a company called this dot labs. And I'm Leon Noel, manager, director of engineering at a lovely nonprofit called resilient coders and community member, a hundred devs. Let's go.

Let's go. I have been doing this week has been crazy busy, like next level busy. Um, I'm finding myself having to do stuff at 10 p.m 11 p.m that never happens and uh a mixture of it is i have some really really big goals that i'm chasing right now some like gigantic ones and it's kind of kept me going but also part of it is as people know we're still in the cohort right now as of the time of the recording this we're in like the last two weeks actually 12, 12 days.

So it's crunch time. Everybody is pressured, freaking out. There's a lot going on.

I'm leading one of the teams now. We had an issue with a couple leads, and basically I had to step in, and now I'm leading the team solo. And so they were really, really behind.

And so now I'm trying to number one fill in whatever knowledge gaps there may be but also really getting them on a structure where it's like we can execute six weeks of work within three weeks definitely pushing them to their limits for sure in a certain way a lot of them are uncomfortable in certain things but that's been pretty fantastic because it's kind of gotten them out of their comfort zone a little bit i've been really really proud of not just my team but all of the teams in the way that they've adapted like man just going through the team channels we have 13 teams in total this this cohort and just seeing all the things that they're doing is just next level but i realized something one thing that we're doing with my team is we're doing weekly demos. And so it's like every Wednesday, they're kind of just showcasing what they've worked on, but also walking through the code. So that way, if someone is on the back end side, they can see what the front end team is doing.

If someone's on the front end, they can kind of see what the back end is doing and understanding concepts, right?

You're probably not going to be able to regurgitate the code the exact same way within a two, three-minute demo, but that knowledge is there. And in doing so for one of the demos, someone had did a fresh pull to kind of pull somebody's changes in and it created a merge conflict. And in that situation, another team had the same issue and I kind of went to go help them as well.

And without knowing why or how or what was going on, they just started doing a git merge, right?

Not knowing what was preferable. And I chimed in and I was like, hey, in this particular situation, you probably want to rebase instead of merge. And they're like, well, what is rebasing?

And it's funny because this is something that I do habitually on the regular, right?

Like every day, every other day, you're rebasing, you're dealing with merge conflicts, et cetera, et cetera, et cetera. You don't really think about it. I just go through the motions.

And so when they ask me that, I just pause for a second. I'm like, I haven't had to explain this in years, right?

What do I go through to make this make sense?

What example do I use?

Because I don't have an example prepared because I haven't really thought about it in a while. And I'm like, wow, I i realized that as you gain knowledge you start taking for granted the fact that you know this thing because you're just going through those motions and when it's time to really break it down i froze for a second i'm like i really need to think this through before explaining it because i don't want to miss something i don't want to poorly explain something i said give me a couple minutes and i'm starting to like write down my thoughts and brainstorm to be like okay this is this is the reason why here, here, here. That way when I explain it, it's very smooth, and it totally clicks for that person.

And, of course, when I tell them, wait a minute, they're like, this dude's weird. Why am I having to wait for you to just explain the thing that I just did?

But I didn't want to do a bad job of it. And it's kind of made me realize the more we learn, the more disconnected we get with the position where we were when we didn't know something. And so if you don't stay in tune with that, it's really hard at times to be like, oh, this is, I remember what it was like not to know X, Y, Z.

Let me break this down in a way that it makes sense to you. And I know you, of course, doing a hundred devs, resilient coders, et cetera. This is something that has to be constantly on top of mind for you.

And I know I do a lot with juniors, but I mean, know you, of course, doing 100 devs, resilient coders, et cetera. This is something that has to be constantly on top of mind for you. And I know I do a lot with juniors.

But, I mean, for you, you're more on the full on. You don't know what a div is. You don't know how to make a button or an event listener.

So mine is sometimes a little bit more advanced than that. But it's got me really partially humbled but also impressed with, like, what that path looks like to educate somebody yeah and um i thought we could kind of talk about that a little bit today that'd be fun yeah i think some of the first things that popped to mind uh we we call this drawing the owl you ever see like those old school like how to draw books where it's like you want to draw an owl it's like a big circle and then the next thing is like the full drawn out with all the details and everything. And you're just sitting there like, what the heck?

Like, how do I get from that to that?

And like, everything's missing. And so I think as software engineers, we've accumulated all this knowledge. We have all these mental models that we didn't realize we put.

Like, we put in all this hard work to have these mental models. And so it's hard for us to, in certain instances, break down the step from A to Z because we're just going to jump to drawing the out which is hilarious as programmers that instruct computers on what to do right but this is like a very common problem and so and it's also frustrating for newer folks to engineering as well because you're coming in you see all these people with all this knowledge and it's often very hard for them to break it down into something that you can understand and go through all the steps. And so when you are giving feedback as maybe someone that's more senior, or you're trying to help someone that is earlier in their learning journey, and this could be at any stage, doesn't have to be just like folks learning the basics, can be advanced concepts too.

You have to be super mindful of not telling them to draw the owl to like break it down into more concrete steps to show the path from a to z and it's a skill that i think you can develop over time but yeah definitely something that i see a lot and i guess we can talk a little bit about kind of our thought process on how to do this why it's important to do it but i think it could be something exciting to talk about. I guess when it comes to the whole idea of breaking something down or the owl, I totally get that analogy. It makes sense to me.

And it's funny because there were times where I was truly begging for each step, and then now it's like, well, I already know how to do this, so in my mind, those steps exist already, or it's really just one step. Like, hey, how do I get my boilerplate going?

Before, I was like, what the heck does boilerplate even mean?

And so I think that is really interesting. We'll get back to the episode in a second. But first, a word from our sponsors.

Financial literacy is important, especially if you are in a position where you are changing careers and income brackets. More income can create larger financial issues if you don't budget correctly. So this episode is sponsored by Lucas Casares, certified financial planner and founder of Level Up Financial Planning, where he specializes in serving early and mid-career tech professionals to help you take your financial confidence to the next level.

Danny and I have helped thousands of people level up in tech, often going from zero to six-figure careers, and we've seen all kinds of mistakes. Level Up Financial Planning helps you gain clarity on all your finances. This includes prioritizing, managing employer stock, retirement planning, tax planning, and preparation, college planning.

college planning and as a special deal for our listeners to get a complimentary meeting with lucas visit level up financial planning.com to find out more his link will be in the show notes he's been our first sponsor for a while people have already called him give him a shot check it out and see if it works out for you now back to the show all right so i guess with the drawing the aisle and breaking it down i think that's skill set that we've both really developed over time, right?

We put a lot of work into making sure our code is approachable for the folks on our teams and through the programs that we run. And so I guess for folks that are listening, can we give them like a concrete example, maybe going back to the Git example that you mentioned?

Like, how did you break down that idea of merging or rebasing and the differences?

And how did you explain that to folks that might have been using Git professionally, honestly, for the first time?

So, yeah, let's talk about that. So when it comes to Git, there are a couple of commands that you should absolutely be familiar with, especially if we're working on a team. Probably the most typed in thing in my terminal is GS for Git status.

in thing that I, in my terminal is GS for Git status. Like that is 10,000 times a day, every day. I'm over overly utilizing Git status, not just to check if something is right or wrong, but just to see if one change happened in the way that I was hoping for, or if multiple things change, I'm constantly using Git status.

But the other is like going between branches, especially on a team, you need to be very familiar with how to, number one, make a branch, but number two, how to hop to that branch. Now, I will say this. I historically have always been very, very adamant about you should know how this thing is working.

And knowing those terminal commands to the detail and utilization within the terminal, I have always felt is very, very important. My stance on that as of recent has changed drastically. The UI and GUI tools have just come so far along that there's tons of ways that you can utilize this if that's your preference.

Now, here's what I will say. Not all companies utilize those tools. So you got to make sure, like if you become overly dependent on like GitHub desktop or something like that, you might be in a situation where your company doesn't use it.

Now you're so dependent on it, you don't know how to do the thing. So it's almost the way that I talk about like Tailwind. It's good to know how the CSS is working for the shorthand that you're doing with Tailwind because it's going to be really bad if you only know Tailwind and then you get a job doing vanilla CSS and you're like, I don't know the first way to make this responsive.

So it's very good to understand the abstraction, but also what's happening underneath that level. So for me, if you're using those tools, it's fine. But understanding the branching system is very, very important.

If you're using those tools, it's fine. But understanding the branching system is very, very important. But with branching comes merge conflicts and understanding where git merge and git rebasing really plays a factor in.

And for me, the way that I kind of look at it, and I'll maybe explain it like this to where it makes sense. If you're like a single developer working on a branch, merging works well because you can kind of control the branch and its history. So I'm very big on having a very good, detailed, linear history of your commits and your pulls and pushes, mainly because if something goes wrong, I need to pinpoint where it went wrong, right?

And so after a branch is merged or a pull request is merged, squash your commits, put it into one, you're good. But until then, I kind of want to see and have at least i'm big on version control to where some of my prs will have like 30 40 commits but it's mainly because i look at it like a save point in a video game and so it's like oh i could totally save it when i complete the level but what happens when i fail that level isn't it demoralizing to a certain extent to go all the way back to the very beginning of that stage instead of the last item that you completed at a checkpoint or something like that, right?

So that's kind of the way I look at version control. Do I want to start all the way back to that previous point that was so far away?

Or would I have frequent commits where it's like, okay, this one item went wrong. Cool. I'll just do a fresh pull, be back to where I was.

Everything is happy-go-lucky. And this was the interesting thing. When I was explaining this in the cohort, they were committing locally and not sending it to GitHub.

It's like the whole point of GitHub is to store that version for you. If you're committing everything locally, you do have a chance of potentially going back one commit. But the thing is, if that branch gets corrupted in any way, shape, or form, you've lost all that history because you didn't send it up to GitHub.

Just send it. I don't know if people are like, well, they're going to see I only progressed 10%. Who cares?

No one's checking how frequently you're sending that commit. What they are checking for is when it's finally done is the right thing there. What do you think about auto-pushing?

Yeah, I'm not against that. But the only thing is, I like there what do you think about auto pushing yeah i'm not against that um but the only thing is i like knowing what that save point is and so when it's auto pushing sometimes you're not really in control of like if that one component is finally finished where you feel like this is the save point but i'm not against it if it helps somebody frequently have a safer version of online the other thing is uh with merging and you're like that single dev if you're working on your branch by yourself, it totally makes sense. It's perfect.

But when you start having multiple devs commit to a feature or a branch, this is where things really, really change up in a big way. And so the example that I gave for this was like, let's assume, for example, like you're dealing two devs, like what do you call it?

Cards. So imagine merging, like you have two decks of cards. Leon has one deck, I have one deck.

We're working on the exact same branch together. So when he pushes his deck up, if I'm merging, I'm literally just grabbing his deck and I'm just kind of smashing them together. Whatever open spaces there are, it's just going to fill in those crevices, right?

It's not ideal when you're working with others. But now if I'm by myself, it totally makes sense. It's just going to fit naturally.

But when I rebase it, it's like I'm taking the deck of cards and I'm taking his, which was pushed maybe the last push there. But I know my changes are going to be brand new and it's going to bring the branch up to date with everything that's needed. So it's taking his deck and placing mine on top of it and for those listening audio i decided to put my right hand and place my left hand on top of it um and it's essentially making the new source of truth or bringing the branch up to date with my changes first to say this is where our starting point now is and so if leon now pulls it he now has the current starting point being my latest changes instead of it all just kind of being jumbled together right and because that now if you look at the linear history of the git commits everything is like in order on point and we know exactly what went where and that's kind of the way that i've explained the difference between rebasing and the concept of it uh rebasing i mean conceptually is probably one of the best things you can use on a team especially like keep preserving that the difference between rebasing and the concept of it.

Rebasing, I mean, conceptually, is probably one of the best things you can use on a team, especially like keep preserving that linear history. But I think the bigger thing too with rebasing is it just helps you go through all the commit history in a good way to where if you are replacing code, you know exactly what it is that you're replacing, commit by commit, instead of just merging it all together at once. And I think that just helps protect things in the longterm.

When do you find you're using rebase the most?

Is there like a specific, like before you're converting back to main or like what's the, if I'm working on a feature where there's multiple individuals there, that's definitely more than likely going to be when I'm using it the most. If it's a solo project, I'll probably get merged most, but I will be honest. I've kind of just become in the habit i've not become i've kind of adopted the habit of i will always rebase unless proven otherwise and so it's like i can't understand why i would never want my starting point to be exactly where i wanted to be each time and so if a merge conflict exists it's generally because our starting points are conflicting.

So unless I'm given another reason to do it, rebasing is my default, and then everything else kind of follows. Similarly, I don't even know if that's a hot take, to be honest. Now I'm wondering if it is.

Let us know in the chat or the comments if this is a hot take. I don't know. But rebasing has kind of always been my default approach to things um it just kind of saves you in my experience are you typically working on feature branches like by yourself depends on the org so uh when i worked at autozone right we rarely had merge conflicts and it's mainly because if i was working on a page, nobody touched that page.

And so now I will say there was another team, not giving any details, but their code was also in our repo. And so sometimes it would clash. But it was very, very seldom that I ever had that issue.

It was other organizations that I worked at where it would constantly get conflicts multiple times a day even, just because everyone was working on the exact same thing and it was just a mess. And so there it was very crucial for your starting point to be the latest thing for everybody just because of how much friction was happening. And so if you didn't do that theoretically, you would just have many other issues, not just for yourself but other devs.

It kind of just saved you. And so that's kind of where I just started adopting that process. And I would still rebase even an AutoZone just by default, even though I probably theoretically didn't need to.

But it's just the habit that I've kind of developed at this point. And I remember the dev who introduced me to it. I'll even give him a shout out, Mark Gibbons, one of the best devs I've ever worked with in my life.

He's retired now, but God, the brain on him was next level. And the way that he even explained rebasing to me, because he actually led the charge for the whole team to start using it, because he's like, we're having all these issues right now because we're not doing that. And I still remember when we were in that team meeting, we were going through the motions.

I was like, this sucks, dude. This is so complicated. And he's like, no, you're overthinking it just go with this and let's let it was almost like vibe coding before vibe coding was a thing and uh but then it actually started clicking and now the entire team at least all the developers that i worked with on the team i know for a fact are rebasing significantly more than merging if we got to talk about vibe coding at some point too which is we can talk about it take it over the world uh yeah i think that i think to kind of come back to that point maybe we jump to vibe coding after but like i think people kind of get like a really irrational fear around git too i mean it's not irrational because it can really cause you a lot of headache at the end of the day but especially for folks that are going through your the program right now the cohort right now folks that have gone through 100 devs, I think you're going to find yourself in certain patterns, right, where you're doing the same kind of consistent git commands over and over again.

That's fine. But when you find yourself in this situation where things are not going well and you have to figure something out, it's okay to, like, look these things up like we've been do we i used to get day every day for 10 plus years and i still run into a thing where i'm like i i messed this up i don't know like i don't know where i'm at and it's okay to get help with those things i've looked at oh shit get too many times to count uh for like the the little things that pop up and so i think just as a word of encouragement as folks that are like learning and using it like you're that you're you're dealing with lots of code different people lots of collaboration and like stuff's gonna happen it's okay when that happens to ask questions to figure it out to google it i have to take some time to like look at the things that see what makes sense in that scenario uh and i think that's something i just want to put out there into the world for folks to believe and understand and the other thing too is that when you're just working on projects by yourself, you're not going to run into any of this stuff. It's just really hard to run into a lot of this stuff.

And so really try to put yourself in an environment where you can practice these skills, because there's skills you're gonna need every single day on the job. And so joining a cohort like Danny's, contributing to some smaller open source projects to get your head around these things, super important. If you're just a solo developer learning, you've got to put yourself in an environment where you're collaborating because it's what you're going to do every single day.

And you want those skills before you're on the job. Man, you said something that really triggered an idea and a memory here. Number one, kudos to everything that you said.

But the other thing that I want to really point out here with the commands, there's so many tools now, like we're not sponsored by them, but shout out to warp.dev. They have an entire terminal that is AI based, which, you know, for some that may be overkill, but I really tried to trick it in the sense that I was asking it to rebase something that didn't need to be rebased. And what's funny is it literally said, this doesn't need to be rebased.

What you would want to do here instead is da-da-da-da-da. So it's like if you're ever in a situation where you're like, I don't necessarily know what the command is or what to do, you could use a tool like that where it's like AI can kind of guide you through what it is that you need to do in this time. But the other thing I really want to highlight is the dang commit messages that you need to be sending.

And this one, funny enough, was something that really confused a lot of my team because they were just throwing in random messages, right?

And here's the thing. When you follow YouTubers and stuff, and there's, of course, the memes like, please work now, da-da-da. But the reality is, in an enterprise-level organization, you're not really doing that as a regular.

You might do it once in a blue moon as a joke with your buddies and coworkers. But you're not really putting that in to enterprise level software where the director of engineering is going to come there like, really, this is what we're putting in here. We can't find what you were working on.

But the structure that we've been doing it with the cohort is kind of the structure I've always followed in organizations where we follow like a fix, chore, feature, that kind of situation. You start the commit message off, right?

So you get commit dash M, you put your quotation mark, and then you're putting, what is it?

Is it a feature?

That means it's the first introduction of this PR to this feature coming to life. Is it a chore?

Is it a fix?

Was there a bug that's causing an issue so you're fixing it?

Et cetera, et cetera. You put a colon, and then you type in whatever you get messages. And you shouldn't necessarily type in like, oh, I'm adding this now.

No, no. It should be just exactly what it is so that way it's searchable. So implementation of new card feature, right?

Honestly, I don't even like that as a commit message. I'm just trying to think of something off the top of my head. But it's something along those lines.

But then what we do after that is we put a parentheses and we put the ticket number associated with that thing. And then we close the parentheses and close the quotation. And the reason why I explain it like that is if I have a merge conflict and I'm like, oh, I don't actually know which version of this code I need.

What is the first thing that I do?

I can go look up that commit. And if there's thing that I do?

I can go look up that commit, and if there's a ticket number there, I can then look up that ticket number to be like, okay, this is what they're implementing. This is the code that they wrote. I now know I need the current changes that are coming in instead of the incoming changes, right?

And so I can choose then and save my merge conflicts. It's really, really important, to me at least, to have very good, valid commit messages. And you'll find people really appreciating that because if they ever have an issue or they need to look through that history, those detailed messages go a tremendous distance in helping them out and saving them time.

But what sucked is, prime example, the other day there was an issue on the team and it took me probably five to six times as long to find the exact commit that had an issue because none of it followed conventions that are normal and what's funny is when you have like 30 commits inside of a ticket now i'm scouring through every single ticket for each individual commit because i can't even find the commit or the message that i'm looking for in regards to that feature so um good messaging goes a long way. And it's such a simple practice. It's so wild.

And GitHub works so well together when you do the parentheses with the ticket. It just kind of helps pull everything together automagically as well. And so if you're not doing it, it's gonna cause more headache.

But also, these are simple patterns that you just want to be muscle memory, right?

Like it's something you're doing every day, day out, so that when you get the job and you're on the job it's something that you can just kind of do very quickly you mentioned kind of the rise of the desktop tools and so what are your thoughts on them do you recommend beginners use them i have some ideas i'm curious here my my rule on this is the same right if it helps you and you know what you're doing cool i'm all for it like we had a hot take in our discord the other day too where it was um somebody was suggesting use ai for learning and then somebody else was like no don't use it for learning it's a terrible tool and really it's not that it's a terrible tool for learning it's the way we're using is absolutely horrible in regards to especially at the junior level they're like hey just make this thing. They don't know what it did. They don't know how the code is working, but they're looking at it.

And yesterday at the meetup, somebody saw that conversation. They're like, okay, Danny, then how do you recommend learning from it?

And I was like, well, this is how. Let's use something generic like a for loop. If I were to ask AI, hey, can you make this for loop?

And then AI will make it, obviously. It's super simple to make that. Then I would say, hey, can you explain the different parts of this for loop and explain why I would need it in this way?

Now I'm learning from this. Then I would say, if I were to use it in ABC fashion, will this break?

Will this work?

And then it would explain to me why that would be optimal or not optimal. That's how I would use AI as a learning tool and leverage all the resources there to learn from. The problem is almost no one at the junior level is doing that like i won't say everyone isn't doing that i don't like blanket sam as we've already covered that but like 90 ish percent of juniors are not using ai in that way and if they if they say they are they're absolutely lying.

Mainly because I see it every single day. And prime example, shout out to AppRite. AppRite, in their Discord, I just got tagged right before this recording where someone's like, hey, you mentioned this in a podcast that juniors don't read the error message.

And here's someone asking the error message and it was plain as day. You have a max of too many XYZ. This will not work.

But they're like, I don't know what to do. It literally tells you there's too many of the XYZ. Remove a max of too many xyz this will not work but they're like i don't know what to do it's like it literally tells you there's too many of the xyz remove a couple of them then this works but if you were using ai as a tool to learn from you would ask why did this go wrong what's the way to implement this what how can i fix this for the future you would understand and not just understand what the error message is saying but you would understand for the future if you ever got the error message again how to implement that solution in a meaningful way.

And so I kind of look at it like that. And it's the same thing that I'm even looking at this whole rise of vibe coding, which we kind of talked about. People are literally to where they're like, hey, I'm just talking to my IDE now.

I'm not even typing anymore. Forget typing. We're talking.

Voice commands to make these applications where we have it do 95% of the work. And then I saw somebody adding on to this like, hey, if you're getting too many error messages, delete all the code and start over again. And I'm like, we're not even solving for the error message now?

It's like, hey, we're just talking through. And this is my whole issue with the CEO of Anthropic. He went viral two days ago because he said in six months, AI is going to write 90% of the code.

In a year, it's going to be 100% of all code for all developers. It's like, what are you even talking about?

I understand there's a certain aspect of shareholders are going to totally love this comment. But let's just be real. I could barely get to the point where we're 20%.

And I know some people, especially on Twitter, will be like, prompt, diff, prompt. No, dude. There's no way we can realistically say, I'm sure you can build a marketing page.

I'm sure you could build some of this basic template stuff, right?

But when we start getting into more complex things, if you are not intervening at a level, it's impossible to get to where you want to go. That's number one. But number two, AI is great at just building something generically.

AI is frigging terrible at anything related to maintenance. It is not even close to understanding the logic unless you provide it. So I don't – I'm sorry.

I'm getting passionate right now. I need to stop. I need to calm down.

No, no. You're good. You're good.

I had too much caffeine, and this is what happens when I drink too much coffee. No. But I'm so serious.

I don't understand where – and I know social media is like this echo chamber where they just get hot and bothered about something for a while, and it's the everything. Web 3, you couldn't go anywhere on social media without people talking about it. Web 3 is still around, but did it kill every other industry the way people talked about it?

Not even remotely close. Blockchain was going to be the solution for all databases. I know there's blockchain fans and aficionados and utilizations and this and that but it's not even close to replacing every database and i'm sure there's arguments like well it's better for this and it should be used for this that's fine enterprise doesn't switch like that like it's never fast and so even now with ai adoption i'm having all these events with uh executives to where they're like should we allow our devs to use AI tools?

Like, should you?

Like, I thought we were all on board with the idea that AI is not this terrible thing, but they still haven't even let them use it internally. And so six months from writing 90% of the code for all developers, we still have companies that haven't even allowed their devs to use Copilot yet. Copilot.

God! I'll get off my soapbox. There's no way that a CEO of an AI coding company would say that AI would be coding in six months, would there?

I don't think that's what they would do, right?

They wouldn't go out there and try and sell their software more. I just wonder in six months when he's like, oh, my bad. My bad.

We overshot this yeah i don't know it's like why would this is like it's too close to like like we're not even talking about cutting where i'm just like the state of society like why would you get online and say like you just like lose trust like you already have one of the hottest products since sliced bread everyone's using it you're the talk of the town why make those statements that are going to make you lose credibility like you you literally have the world in your hand right now there's no reason to say it's just zero like and if it doesn't come true like we can't believe your estimates going forward right and we want like that's the only thing you have right now is like our belief in your estimates that's why we use your product like come on like it's just a wild concept to me i just don't understand it i think we just like live in a world where it just doesn't matter anymore and people just won't care like numbers go up like i can make flying planes it shocks me because it's like the one audience that you shouldn't say to is the one that is technically inclined to know how this product works at some degree right why are you not saying this about an audience that doesn't know the first thing about code to where like dude said it totally have to believe this must be true right so to me i just don't understand logically why the developer audience is the one that they target with these messages, because it's very easy for us to audit the usage. Just, you know, and the crazy thing is like social media, you know, it's an eco chamber. Right.

So they love regurgitating the hot takes that they hear. Right. I see it all the time.

We all see it. That's why, like, the YouTubers do those shock things. And if there's a trend, they'll follow it.

uh like right now there's a very popular rapper in india and his music video just dropped now you see people that aren't even reaction content creators making a reaction to that because they just know it's a trend that's going to go viral every single time right now no hate to the dude he's awesome i like his style of rap i like his lyrics choice words the way he's even embracing his community. Matter of fact, I'll even give a shout out to him. His name is, I know I'm going to butcher it because I was even practicing the name yesterday and I forgot it.

But it's Humankind, which is like, it's a take on it. But he just came out with a song, Run It Out, I believe it's called. And he said the first album went so viral.

He's not just feeding his family. He's feeding the entire village. And he's bringing up his entire village and he he like he's bringing up his entire village to another like quality of living standard based off of the money he earned like i love supporting people like that to me that's that's worth it the guy that did the like motorcycle going around yes yes that's fine that went crazy viral i mean the project pat flow definitely hit um but i will say he's that's the way that I like looking at success.

That's kind of the same thing that I have with my belief with the community, where it's like, we could easily make money off of all this. And to be honest, man, sometimes I saw this thing where people were like, you want to be in my daily stand-up Discord?

It's $25 a week. I was like, what?

I'm free. I'm free. up discord it's 25 bucks a week i was like that was my exact that was my exact reaction last night when i saw that video on i think it was tiktok if i'm not mistaken and i was like i can't believe like i could be raking it in if i didn't have a conscious man if i i make so much money bro bro my swimming pool whatever swimming pool bro i have 12 000 people my discord let's just do the math on that i'm just curious right now bro 12 000 times 25 bucks a week that's 300 grand a week man this is always i just don't i just don't understand folks you don't need to spend any money to do any of this there's so many places you can get all this for free better community better pizza like you can it's just oh you can get this for free like there's so much out there that you just don't need to do that anymore better better communities better pizza like it's just you just don't have to and it just it just bothers me so much because people sometimes think that if you put up a little bit of money you get better value but it's just not the case like it's just not and that really just just bothers me so much because like I see like I just I just wish I could I could convey to people that like you can get value in other ways and we have communities that show up every single day to support people that are completely free and there's so much time and investment and energy and passion that people just miss out on and I think you'd be way better off finding a community like that than paying some 25 bucks a month.

Somebody's just going to ignore you. It's wild. Sorry.

You're too generous. It's per week. Say again?

Not per month. You said per month, but it's per week. Hold on.

I got to start grifting. Sorry. I'm going to wrap this up.

I got to get to figure this stuff out. It's so wild. And it's just i don't even know that we're trying to edit some of this out because like i just don't i just it just like really mystifies me and i'm gonna be honest this episode has gone completely off the rails i don't know what we're gonna do with this episode oh my god dude have you uh done any vibe coding we did it as a challenge at work work so um like transparency this dot labs is a tech consultancy and we have a lot of lot of lot of demand right now for ai tooling not just like basic stuff like a chatbot but like very very interesting proprietary things internally for organizations um and in doing so we're trying out any ai trend that comes up just so we have some level of knowledge into it but the other aspect too is like we're trying out any AI trend that comes up just so we have some level of knowledge into it.

But the other aspect, too, is like we're just being familiar with everything. So anytime there's a new editor that comes out, we're testing it just to see and understand. So that way, if we're asked about it, we're able to talk about it at a very high level and explain the pros and cons of whatever it may be versus their current usage versus other.

And so we definitely did a test on vibe coding. I personally can only see it really, really, really useful for things that are devoid of a lot of logic. And so once you start getting into logic territory, it's just not there.

And the other thing is, especially with vibe coding, you have multiple editors going in order to do this. That's the whole theory behind it. And so it's just a pain.

I personally just don't see why anybody would go that route. It's a fun little experiment, but I just can't see it at the level. When you start getting to very, very large code bases and when you start getting to the level where a lot of logic is necessary for your application to work, prime example, I tried to do it with the event platform that I'm building.

It did not go well at all. Like, I will say, though, I have started adopting more AI usage in it, and I can definitely see, and very vocally say, it has definitely sped up my progress in a lot of areas significantly like significantly um i was avoiding it quite a bit because like i'm in my ways and i kind of know this stuff um but as i've gotten way more comfortable with ai and ai usage uh it just kind of made sense at that point so um i've got several editors now installed on my computer that i go between um there's some that i like better than others in certain aspects maybe we do an episode on that i don't know um but i will say that uh there's a company that i'm not even necessarily like the biggest fan boy of but i like their tool better than others right now and so i'm kind of using that a little bit more um but i don't know have you tried the vibe coding yeah i've been vibing uh the thing for me is i wish i could vibe with my more established code bases i feel like a lot of like the like bolt and replit agent stuff like that a little harder for that or just outright don't do it um but with fresh stuff i kind of feel like it felt like with chap gp when it first came out like the first big wave of everyone being like oh my gosh this is amazing all the knowledge at your fingertips like i could do anything and then people went back to watching netflix right and so i feel like the the vibe coding right now feels like that where it's like oh i can build a video game i can do xyz i can like have this idea and then like three months later it wasn't like back to just do whatever they do and so i love it as like the death of excuses right like it's just like you have all these people that think that oh if i could do x y and z i'd have the next million dollar app or if i could just code like this like now you can kind of get pretty close with mvp but like are you actually going to do it and so for me with a lot of like smaller like one-off things like smaller like smaller apps like pomodoro apps and stuff like that i get this phenomenally well yeah stuff that's well defined kind of already exist out there on the internet it'll one-shot it pretty quickly you can add to it you can make it your own so if you're trying to make like simple stuff that's more customized towards your needs like i think it works phenomenally well. I've been very happy with it.

Could I build my next business off of vibing?

No. I think it would be a very difficult task to get it to where I want it to be over time. Like you said, we'd be jumping through a lot of different pieces, a lot of different hoops.

And then you hit these really weird edge cases where the common advice right now is just like start the whole thing over and so for me it's like just not there i don't see it getting there i do see like smaller one-off ideas mvps maybe i don't know but i just also feel like it's excitement and then that excitement's just going to go away i'm going to be left like still trying to figure out how to orchestrate all this stuff pull the pieces together get to do what we wanted to do and yeah i think the code will get there i think eventually like it'll be a more practical way of like getting stuff started but it's kind of probably going to be like we started off this conversation with like do you use the terminal or do you use like this gui to like do it um do you get your hands dirty with the code right out the gate or do you like use these like whizzy wig tools like i think that's where we're going to get to and you'll have to decide for yourself what the best pathway forward for you it's not there yet i don't see it there in six months um but it's fun it's exciting and maybe that excitement gets somebody interested in coding and building and then they actually learn the tools they need to do to do it well you know there's so much to say i think we've all said it it's been real it's been fun we will see you on the next one goodbye everybody peace

‍