The Laracasts Snippet

Recently, I've been updating a book I wrote a number of years ago. Over and over again, I found myself hitting the delete key. References to bad practices and SRP were laced throughout every chapter. How could I have been so arrogant?

Today, we're discussing the importance of building little projects for yourself. Whether it's a podcast, or book, or web app, pick something and force yourself to see it through to completion. Along the way, I'll tell you about my completely rewritten book, and why I'm so excited to share it this time around.

Last week, we talked about development trends - and how they sometimes have a tendency to make developers feel as if they're falling behind. "These are the new trends of 2016! Get to the mall, stat!" Today, let's continue the discussion a bit more. Will this new trending architecture bring you closer to launching the project of yours that's been sitting at 90% complete for a year now? Maybe...but maybe not.

If you think about it, every single year, certain development trends take the community by storm. Whether repositories, or service classes, or the command bus, this is undeniably true. Let's talk about it.

Let's do another Q&A episode today. I'll answer the following community questions. Why won't Laracasts expand to cover more technologies and languages? What are your top three favorite podcasts? Are Forever Plans smart business? What's one piece of advice that you'd offer entrepreneurs starting their first business? Will there be a Laracasts series on what's new in Laravel 5.3? Vue or jQuery?

We have enough data to show that the typical 9-5 work day schedule is entirely arbitrary. The reality is that humans simply aren't good at holding their attention for such long spans of time. So - with a two-week-old baby in my house, I've begun re-thinking my work schedule. Is it possible that we can get the same amount of output from two hours of work, two times a day?

If I were to pick my most favorite aspect of programming, it's this: no matter how difficult or confusing a bug/feature/refactor may be, if you stick with it long enough, you will figure it out. Every single time.

I'm a big fan of the tv show, "30 Days." I even apply it, at a lower level, to things in my own life. Whether it's contributing to open source every day for a month, or working out six days a week for a month, I've done a bunch of them.

Whether we like it or not, humans have a tendency to insert themselves into small communities or factions. In the coding world, it's certainly no different. And that's specifically why it's so important that we think long and hard about which tribes we choose for ourselves. That single choice can have huge ramifications, when it comes to how we approach and think about code.

I use task apps religiously for, mostly, two specific reasons: I want permission to forget about it, and I believe the process of checking off items gets you in the habit of being productive for the day. Listen to me ramble, if you'd like to hear more.

We forget that there was a time when the terms "introvert" and "extrovert" didn't mean anything to the common person. Naturally, the internet has shined a huge spotlight on these personality types, but, yeah, a decade or so ago, things were a bit different. Some of us thought we simply awkward, detached individuals.

Every six months or so, it pops up again: "Frameworks are dead." But...is that the case? What does that really mean? Let's chat.

This week's episode takes a detour, as we talk discuss the alien living inside my wife's belly.

The vocal consensus in the PHP community seems to be that, unless a class is perfectly unit-testable in isolation, it's inherently poor code - and in need of refactoring. But are we sure this is true? Let's talk about it.

If you're a developer launching your first product, it sometimes easy to forget that it's now exclusively your job to tell the world. Luckily, you don't have to reach into your pocket and spend thousands of dollars to get the word out; there are free - and more effective - alternatives.

In the early days of my coding career, I had a tendency to spike things out. Go fast, toy around, get it to work, and then hit deploy...all while quietly saying to myself, "I'll go back and clean this up later." But I rarely actually did...

What do "PostRepository", "TooManyMembersException" and "StaticallyTriggeredHydratorFactoryInterface" all have in common? The suffix! Are you sure that you really need to tack on the name of the pattern to each class?

Here's the thing about code-focused workshops, magazines and commercial blogs: they may not always have your best interests at heart. Let me explain...

The topic of discussion for this episode is a pet peeve of mine: treating developers like children. "Bobby, you're likely to cut yourself, so, no, you may not use sharp knives." Is that really the type of community we wish to foster? I hope not. DHH was talking about these issues a half-decade ago. Give it a listen.

I keep a list of frequently asked questions, related to Laracasts and being a programmer in general. In this episode, we'll breeze through a long list; everything from Jim Henson, to DHH, to facades! What music do you (Jeffrey) listen to when coding? Why not branch out and teach more subjects on Laracasts? Should I be using Laravel facades? Should I test every single class? Sublime, PHPStorm, or Vim? Why do developers disagree so much on best practices? Doesn't that defeat the purpose of a best practice?? Do you have any advice for first-time conference speakers? What do you do if you can't grok a particular coding concept? How do you refactor code, if you have no idea where to start? What theme do you use? Who are your personal, coding, and education heroes?