The Laracasts Snippet

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.

A few nights ago, I was fast asleep when, all of the sudden, the building's fire alarm went off. It definitely woke me up, but I didn't respond in the way you might think. My instinct was to ignore it entirely. How come? And why is this also often true for the tests you write?

Whether in life or software development, I think a good approach is to push for as little as possible. The fewer lines of code you must write, or the fewer items in your bathroom cabinet, the better.

A decade ago, I was taught that the beauty of CSS is its ability to completely alter the presentation of a website without touching your HTML. Yeah... "you never have to touch your HTML again." Sounds great, right? Too bad it's BS.

"Fake it 'til you make it" is a great idea, just as long as you back it up behind the scenes with actual work toward the thing to which you're faking.

Sometimes, the appropriate and responsible thing is to throw it all out and start again. Now, of course, not everyone has this luxury. Business requirements and deadlines often make these sorts of things impossible. However, is this true for your own business, or your own open source projects? Sometimes, that muddy code or CSS you wrote three years ago is begging to be deleted. How much better could you write it, knowing what you know now?

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.