The Laracasts Snippet

Let me tell you a story about the programming-induced anxiety that my former self once felt. If you are constantly online, you will have the impression that you are constantly falling behind. But...are you?

Should you learn PHP first or jump straight into Laravel? 🤔 It’s a question every newcomer asks, and in this episode, Jeffrey breaks down both sides of the debate. We’ll talk about the benefits of mastering PHP basics, the faster “time to first win” that Laravel offers, and how beginners can balance learning without feeling overwhelmed. Whether you’re just starting with HTML/CSS or ready to build your first CRUD app, this video will help you figure out the best path forward. 💻✨ Share your thoughts in the comments — what worked for you?

In the last year, the way we program has changed dramatically. Perhaps, more dramatically than at any other time in my career. We can thank AI for that. So that begs the question: how does Laracasts fit into this new environment?

In this episode, we dig into the subject of AI... and whether it's going to steal your job or not. Don't worry: no bait in this video. Just an honest conversation about where we are, and what it all might mean.

There was a time long ago, before the internet, when each of us had the ability to be a big fish in the small pond. At least in some small way, that's true. But not anymore. And I wonder... what does that do to our confidence levels?

We love tools: linters, type checkers, test runners, asset compilers, et al. Whilst these tools can help solve problems, they might also be a sledgehammer when all you really need is a screwdriver. Let me tell you a little anecdote about upgrading my personal site to Laravel 11, and why sometimes removing a tool is even better than adding one.

Tell me what you think of this. We all have certain stories about ourselves that we repeat, like mantras. "I am the type of person who is X, therefore..." But, for all the reps, I'm not sure these are doing us any good at all.

Luke, here! I recently got the chance to attend and speak at Laracon EU 2024, and it was fantastic. The venue was awesome, the talks were amazing, but what really makes the event special are the conversations you have with like-minded developers. Let me tell you about it.

It occurred to me recently that, if my job consisted exclusively of writing code 40 hours a week, I don't think I'd be a programmer today. I might go out of my mind. The secret, from my experience, is to find your fit. Figure out how to combine all of your skills into some unique concoction that gets you through the day with a smile on your face.

If someone on your team presents a business idea to you, they've likely had it simmering in their head for quite some time. Don't be so quick to toss that idea aside. If there's such a thing as anti-patterns in business, this is one of them. Give the idea its due.

Programming taught me an interesting life lesson: be a stickler for the details. You see, getting the thing to work is only half the battle. You’re not done. Not even close. Yes, make it functional. But then make it readable. Should it also be flexible? Then do so. And certainly make it beautiful.

When it comes to business, I - like many developer-turned-small-business-owners, I’d imagine - am really quite green. Not just green, deep green. No MBA in sight. I’m not even sure what that stands for, to be honest. Master of Business Administration? Is that it? Yep, a master of business… yours truly is not. Can you relate?

In this episode, we'll talk about stealing techniques and approaches from other hobbies or industries. What have you learned from one hobby that might be useful for your programming career? I can think of a few.

It's hard to believe, but the last Laracasts Q&A episode was published over two years ago. Let's fix that with a new 2022 edition. I'll answer a wide variety of questions, including: how to initially plan a business, are lifetime accounts worth offering, why don't we have dedicated Laracasts apps, how to avoid content creator burnout, and more.

I often hear about flat organizational structures and how they lead to more autonomy and better collaboration. That could be true! It sounds appealing. But my worry is: don't you lose the zoomed out perspective in the process? From my experiences, that multi-focus hierarchy is essential.

For a number of years now, I've found myself quietly mumbling the words, "Don't participate," every time I feel the need to insert myself into events or conversations that have nothing to do with me. It works wonders. Nearly every time, I delete the draft and get back to work.

In this episode, I take some time to ponder over which programming bullet points I wish had been drilled into me more in the early days of my learning. We'll discuss the psychology of learning, design patterns, SOLID, and, of course, the never-ending river of programming opinions.

It's far too easy for developers to fall into a trap of never shipping new code to production. "It's not ready," we tell ourselves. "Just one more month to clean things up, and then we'll push it up." But if you're not careful, there will always be a reason why it's still not ready. In this episode, we discuss habit building and why it's necessary to not be a perfectionist.

If you've worked in programming spaces for any period of time, you will surely have heard the advice, "It's better to go slow than fast." We all instinctively know this, and, yet, we're simultaneously obsessed with optimizing every facet of our workflow.

Whenever I ask a slightly controversial programming question, the responses often take one of three shapes. Let's talk about each of them in this episode, before taking a few moments to discuss why it's so important to play gracefully with ideas.

Every time I learn something new, I have to re-remind to trust the process. I'm not sure why. That feeling of "I can't" never goes away. You would think we'd eventually make the connection that if you work on something a little bit today, and a little more tomorrow, you'll eventually become quite skilled. And, yet, why do I always begin the learning phase with a hesitation that says, "You'll never be able to do this."

In this episode, we discuss the three-month process of converting Laracasts to a single-page application with Inertia.js.

Four words can derail any programmer's day. Those four words are "If I could just..." Ask yourself if you frequently fall into this trap. "If I could just configure my code editor properly, then I could get some work done." Or what about this one? "If I could just get my office the way I want it, then I could begin this new feature." Have no doubt; this is a form of procrastination that infects most of us.

Few topics in the programming world spark debate quite as much as TDD. There's enough dogmatism from the evangelists of TDD to warrant an equal and opposite reaction from those who aren't on board and are tired of being told they're doing it wrong.

Developers passionately disagree with one another on most programming issues. For every tutorial on class inheritance, duck-typing, naming conventions, and mutability, I'll show you another resource that argues vehemently in the opposite direction.

One of the more frustrating aspects of front-end development stems from the fact that even the smallest of alterations has the potential to derail your entire week. In this episode, we'll discuss how to track browser-specific CSS performance issues.

Traditionally, there are three primary locations when most friendships are formed: school, the workplace, and church. But what if you're unable to tick any of these boxes, as is increasingly the case for remote workers.

Every developer goes too far at some point in their career. It's unavoidable.

Moving to a new server while upgrading to the latest version of a framework is always a scary thing. Even the smallest change can send you down a two hour rabbit hole, as you search for a solution. In this episode, I discuss my basic process, as well as the tools I prefer.

When you have a full-time job, it's far too easy to ignore that side project or business that you've had your eye on. Think about it: most projects never come to completion. How come? And, more importantly, what little steps can we take to ensure that we don't fall into that same trap.

It has occurred to me that I might have made some teaching mistakes in the past. Learning sticks when it can immediately be applied to a particular task or need you have. If you don't have an immediate use case, it might as well go in one ear, and out the other. It's not going to stick.

I keep seeing oddly similar threads around the web that relate to Laravel 8's "increased prerequisites." They all seem to share the view that, if you want to upgrade to Laravel 8, be prepared to also learn Livewire, Inertia, and Tailwind. Of course, I find it odd...because it's not even remotely true.

Here's an uncomfortable truth about the programming world: we all want to sit at the cool kids table. It was true in high school, and it remains true today. It makes you wonder how this might be reflected in the tools we choose.

One thing I love about Laravel is how, for any given project or feature, there's already a clearly defined pathway I can follow to complete it. For example, we take it for granted that a robust queue system with model serialization is always at your fingertips. We take it for granted that a powerful event dispatcher with automatic event registration is available for free. We even take it for granted that the decision of where to store your secret API keys has already been solved and documented.

My wife recently paid me a compliment. "You're a good troubleshooter" - to which I replied, that's because it's all I do every day. Programmers are professional troubleshooters.

After you've maintained a popular open source project for any length of time, you begin to notice a pattern. Certain issues and pull requests bubble up to the top of your todo list, and certain issues...are ignored. Let's talk about why that's often the case.

We recently pushed a new "goodbye" landing page for the Laracasts website. In an effort to not succumb to the usual, boring "Goodbye, hope to see you again" copy, I opted for a different approach. Unfortunately, it didn't land for everyone the way I thought it might.

I recently hired a new instructor for Laracasts. Now that the team has grown to four people, including myself, I thought it might be interesting to discuss my personal hands-off approach to running a small and low-stress team.

As parents or teachers, if you want to instill a joy for learning or reading, it's important that you meet them where they're currently at in life. The goal, as we've discussed in past episodes of The Laracasts Snippet, is to get them excited.

I recently came across a month-old YouTube channel with two million subscribers. The content...was fine. The audio...was fine. And, yet, two million subscribers! Often, the way in which you frame your content is significantly more important than the content itself.

We're living in an interesting time, when one person - anywhere in the world - can start a business without leaving their bedroom. Even better, this business has the potential to bring in revenue while the person sleeps. This is the secret sauce to wealth, and it's now available to anyone with an internet connect and a decent idea. As a result, we have now regular folks - often with little business sense - running highly profitable small businesses.

Every open source project begins with the best of intentions. In fact, they usually begin with excitement. One developer has an idea, and thinks, "Hmm - I can do this!" So why is it that, more often than not, these projects eventually spiral out of control?

We can all surely relate to the sense that our ability to focus has slowly deteriorated over the last decade. If this scares you as much as it does me, let's talk about how we reverse the process through habit forming.

I think you'll find that intermediate-level developers tend to be the most passionate and rigid of the entire community. It is at this stage of your learning when you are most susceptible and attracted to programming "rules," or instructions from above that, when followed, lead us to clean code. But that's okay. While we all eventually realize that rules are meant to be broken, in certain phases of our training, rules very much serve an important purpose, and we'll talk about it in this episode.

To offer something different this week, let's tear down and inspect a recent conflict on the US presidential debate stage.

In this episode, I offer a brain dump on the intricacies of raising two little kids, and fatherhood in general.

Too often, we hear politicians spew the tired "learn to code" slogan in response to difficult questions related to disappearing jobs in remote America. Let's talk about the logistics and practicality of a middle-aged coal miner making this switch.

I've thought quite a bit about types in the last year or two. I know - borrring - but I find it interesting to observe how intensely talented developers can disagree with one another on this particular issue.

Every developer should develop and manage at least one project themselves. Doing so not only harnesses your discipline, but it also forces you to flex product-related muscles you've never used before.

That simple rule we all learned years ago in school may not have stuck properly. Why else would we, decade after decade, incorrectly and constantly draw "cause-and-effect" lines from one variable to another?

It occurred to me recently that I've likely recorded more programming screencasts than just about anyone. In that time, I've picked up a number of small tips and techniques.

A recent study found that a small percentage of individuals are largely responsible for the widespread sense that online interactions are hostile and toxic. Assuming this is true, is it possible that muting a handful of people will instantly remove the negativity in your feed?

In this episode, we'll discuss a series of performance improvements that you can apply to your own projects right now. You'll learn about everything from image lazy loading to inspecting the cost of an NPM package.

No, this isn't the last Laracasts Snippet. But we will be discussing PHP's final keyword and the arguments for and against applying it by default.

In the last few years, I've noticed that my eyes simply aren't as resilient as they used to be. After staring at a computer screen for so many years, the daily eye strain and headaches have been getting worse. Much worse. In this episode, I discuss the steps I've recently taken to improve my situation. If you're in the same boat, have a listen!

Each of us is born with a unique personality that defines much of how we view the world. Is it possible that this also cascades down to the code we write? Maybe!

Today, I have four completely unrelated topics to discuss with you today. As a (cheesy) way to connect the dots between them, we'll call this episode the four P's: Personal, Professional, Political, and Parental.

As part of managing Laracasts, I've been lucky enough to speak with countless developers. Whether newcomers or seasoned veterans, they too often seem to share the same insecurity: sooner or later, they'll be found out.

The subject of this week's episode is gamification. I'll begin by gushing over Outer Wilds, and then move on to discussing the pros and cons of general gamification elements in web apps and schools.

I recently made a bittersweet commit that removed jQuery from the Laracasts codebase entirely. Let's discuss how important the library has been to the JavaScript ecosystem as a whole.

Are you as annoyed as I am that there are five different points of entry, if you want to watch a movie you own? Is it a Blu-ray? Is it on your DVR? Did you buy it on iTunes? Or was it Amazon Prime? Recently, I've been trying to consolidate all of my purchased media to a Plex server I set up. If you're in the same boat, here are some things to watch out for.

After working with PHP for over ten years now, there's one question that continues to pop up - no matter what year it is: "Isn't PHP Dead?" Let's talk about it.

The first draft is almost always crap. There's no getting around it. But once you accept this harsh truth, it can be freeing. Not everything you do is gold.

This episode, I have four things to discuss with you: children and values, old PHP, developers and back pain, and finally a new UI component we're working on for Laracasts.

I recently spent an entire day making a small, but tricky Vue component for the Laracasts forum. There's no doubt that it took longer than I would have liked. But, the fact remains: at the start of the day, I had no clue how to build it. When I clocked out that evening, it was finished and deployed. Let's talk about why this is my favorite aspect of programming, and how it can overflow into the rest of your life.

Representation in the tech community is a tricky topic to discuss. Like a minefield, be careful where you step on this issue. But let's see if we can trace a safe path through.

This week, we're discussing focus, social media, and why we all need to try harder to keep our heads down.

Lately, I've been thinking about the importance of providing examples. Whether you're writing new code, or preparing documentation, or even discussing code, I'm always left with the same thought: "Give me an example."

Developers seem to have a peculiar need to protect their peers from themselves. While I've no doubt that this desire stems from a good place, you need to let people make their own mistakes.

In the last year - after breaking a few of my personal rules - I've become incredibly sensitive to lifestyle creep. In this episode, we discuss why, eight months ago, I asked my pregnant wife to help me slash our lifestyle in half. We'll also talk about important considerations for your own life.

In this episode, line by line, I'll answer a recent question related to remote contractors. We'll discuss choosing an applicant, tips for getting the job, tooling, workflow, and more.

I've focused a great deal on discipline this year. I'm not sure why, but it might be related to the fact that I now have two increasingly time-consuming children that I'm responsible for. While, in the past, I'd often find myself edging toward the "I'll do it tomorrow" path, this year, I've worked hard to sprint in the opposite direction. Or, in other words, even when you're desperate to avoid it, deal with your shit.

It's been over two years since Laracasts last received a fresh coat of paint. For those who know me (Jeffrey), that's two years too long. In this episode, I discuss every facet of the redesign process.

Today I completed a year long project that I'd like to talk to you about.

In the United States (and surely many other countries), financial literacy is not taught in schools. You might think that basic investing and a review of compound interest would be profoundly important learning material. But according to the school board, you'd be wrong. Perhaps it's only natural then that those living in the US are deeper in debt than ever in our history.

While most episodes generally focus on one central idea, today is more a stream of consciousness. We'll discuss everything from the struggles of running a business, to Metroid, to social media addiction, to Cobra Kai. Grab a drink and let's hang out.

I've begun to find that, in so many cases, the basic, boring path - for learning a skill or achieving some result - ends up being the correct one. It's not the fancy twelve-point program that costs $899 to unlock. Nope, not even close.

It's time for another Q&A. This week, we'll discuss everything from how I'd build Laracasts differently today, which controversial ideas I subscribe to, reflections on having a two year old child, and, of course, code editors...

Too many ideas and practices in programming are accepted as basic truths. "Don't do it like that! It's dirty." What I'm concerned with is who gets to determine what is and isn't acceptable code to write. Today, I'd like to share four common practices and ideas that I tend to disagree with.

Do you ever feel like you opinions are being spoon-fed to you? Even worse, what if you didn't even realize it was taking place?

You've seen the same headline all over the web: "This one technique can triple your income overnight." Really? And I only have to click through your article, split into fifteen pages full of ads? Where do I sign up!? But what if there was a simple technique to drastically improve your chances in the job market?

It doesn't matter which new thing I want to learn, step one is always the same: immerse yourself.

In this episode, we'll begin with a five minute discussion of Home Alone, because I know my audience - and that's what you're truly craving from me. Then, we'll move on to a variety of realizations I've come to 2017 - and they're not all related to code.

Every year around this time, I feel it. "Oh, yet another email from that business, asking me to buy their thing...again." The abuse of power is what makes marketing efforts like these feel so slimy.

It's okay to internally kick and scream your way through, just as long as you do the work. Such practical and obvious advice, yet few of us are able to follow it.

From time to time, I'll come across discussions related to the best approach for teaching aspiring developers. And it never fails: there will always be those who recommend the driest possible introduction. Forget excitement and curiosity, as they see it. They don't factor into the equation. Wait, what??

When exactly did developers get it in their heads that to colors outside of the lines is an offense worthy of banishment? And who invented these lines in the first place? They don't exist. They never did.

I've come to learn that discipline is the key ingredient to every successful person I've ever met. It's obvious; we all know this. So why is it so hard to apply to ourselves?

We all have the tendency to reach for our pitchforks upon hearing information that doesn't line up with what we've decided to be true. How does this affect the coding tools and practices that we defend so vigorously?

In the previous Laracasts Snippet, we discussed social media and how it tends to have a draining effect on me. Let's continue that conversation today, but more from the point of view of solving the problem. What specifically am I doing to increase my mental/physical energy levels?

I've been noticing lately that I feel mentally drained at the end of most days. But strangely enough, it's not the code I write that causes this. No, instead it's the day-to-day social media interaction that drains me. Why again are we participating in platforms that actively encourage addiction and negativity? And why are we okay with checking our phones a hundred times a day?

Developers have come to dread interviews. What sort of silly, gotcha question that has nothing to do with building web apps whatsoever will I have to stress about this time? If I were hiring a new coder, I'd asking them an almost laughably simple question...

In the development world, you'll frequently hear the phrase "you are not your code." At its core, this is very good advice, however, too often it is used as an excuse to publicly belittle your peers.

I noticed something this morning: the developers I most frequently disagree with on Twitter place code acronyms in their bio. SOLID, DDD, etc. On the flip side, the coders I most respect nearly 100% of the time never do. How come? Let's talk about what this might indicate about the type of developer you are.

I recently published a short video on what I refer to as "visual debt." Shortly after, the critical tweets began to roll in. How dare you propose that all of these keywords and types and interfaces add noise, they declared. Well, let's talk about it...

The Single Responsibility is both simple and complex to comprehend at the exact same time. In fact, many people find it to be so vague to the point of being worthless. Let's talk about that in this episode, while reviewing how I personally interpret the advice for my own projects.

Today, we're discussing my personal workflow, when planning a new conference talk. Unfortunately, it's never quite as simple as opening your presentation app of choice, and typing away. Any typical conference talk likely took months to prepare.

"Don't use tools," they say. "It won't exist in a few years, but these design patterns will." Of course, the argument is that, if you dedicate any time at all to embracing libraries and frameworks that actually allow you to get the job done, you're somehow, as a result, doing yourself a huge disservice.

In the last six months, it has been made very clear to me that, for better or worse, we're all parrots. Whether tech, or politics, or religion, or programming, this can't be denied. How do we fix this?