The Laracasts Snippet

Over the years, I've come to realize that, what folks advertise and say they do, often bears no resemblance to what they actually do. Consider the broke financial advisor, or the event sourcing evangelist who sticks to basic CRUD and Active Record for their own projects, or the TDD expert who secretly doesn't TDD. The truth is that folks advertise what they're excited by. And, too often, what excites us is what's new and undiscovered.

Over the years, I've been party of many programming communities. And in all that time, I've found one thing that is entirely unique to the PHP world...

At all times on social media, we are surrounded by folks at the top of their game. With so much genius and success circling us like hawks, sometimes it can get you down. Even worse, around this time of year, there's so much talk about "crushing it" and "10x'ing" it.

When it comes to open source code, how exactly should you decide what to build? Will anyone even care or want to use it? Who knows! But, maybe, a secret gold mine will reveal itself, once you ask a simple question.

It's that time again. I have six new community questions to answer, ranging from the most stressful thing about running Laracasts, to new content in 2017, to a developer's Christmas list.

I have no clue what I'm talking about, so listen to me discuss my marketing pet peeves.

In this episode, we're focused entirely on simple performance tips that anyone can implement right now. Every kilobyte counts, so try to implement at least a few of these, if you aren't already! Show Links https://www.cloudflare.com/ https://imageoptim.com/mac https://pngmini.com/ https://github.com/turbolinks/turbolinks

Today, we're exclusively discussing the new Laracasts refresh. I talk about what I've learned in the 3-month process, interesting techniques - both front-end and back-end - that I leveraged, as well as why I spent more time simplifying, rather than complicating.

In this episode, we'll discuss a basic, but incredibly useful technique that I use to write more expressive code.

We're all over the place today. If you're walking the dog or on your way home, tune in as I discuss everything from Turbolinks, to my annoying, broken bank. I also provide a few updates on the Laracasts refresh that I've been working on for the last few months.

My favorite sorts of people are the ones who allow themselves to get carried away over simple things. It's contagious. I dare you to listen to an incredibly passionate fan, of any possible thing, and not be pulled in and inspired by their excitement. Society refers to this as nerd culture, which I find a bit dismissive and critical. If "nerdy" translates to "someone who can't help but get excited," then count me in.

We're all aware of the notorious Twitter mob. Don't you dare go against agreed upon opinions, or you will be sliced to pieces. We've seen the wake of these viral slander campaigns countless times over the years - all the way up to the creator of JavaScript, himself. Why are we okay with this again? And are we creating an environment that encourages any person with differing views to remain silent, out of fear of losing their job?

Lately, I've been making more of an effort to focus on my energy levels, and how to maximize them. If your energy levels aren't where they should be, then any desire you might have had to finish up that side project goes out the window. This is paramount to our financial and happiness goals, so why isn't it at the top of our priority list?

Lately, I've been forcing myself to journal tiny dev realizations I have, as I work on various projects. How often have you hit a roadblock, switched to Stack Overflow, found a fix....only to completely forget it six months later, when you encounter the same problem again?

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.

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?

So you're a developer planning to launch your first SaaS or subscription site? The business side of things get really complicated... really fast, right? In this episode, I rattle off ten tips and notes to be aware of, as you prepare for launch. We're less focused on code-specifics, and more the realities of starting and running a business. Your naivety is your greatest weapon. As soon as you make enough revenue to consider going full-time, get a good accountant fast. Many business books are irrelevant for this type of business. Be skeptical of their advice. Don't fake it. You're not CEO of a one-person business. Automate as much as possible. If you're doing it manually over and over, that needs to be fixed ASAP. The guilt is the hardest part. Eventually, you must schedule office hours, and adhere to them. When handling customer support requests and social media, be a human being, not a corporation. Think small - and then iterate. Decide the life you want to optimize for.

One of the things I've been tinkering with these last few days is a mechanism for performing Russian-Doll caching in Laravel. In addition to determining if I can even make it work, I've been pondering whether this truly has a place in your future projects, or if there simply isn't enough value to warrant its usage. Who knows - let's talk about it. Here is the series of videos mentioned in the podcast: https://laracasts.com/series/russian-doll-caching-in-laravel

An interesting question popped up recently. Should college be mandatory for your children? We all bring our own pasts and experiences to the table, when a question like that pops up. Here's what I think...

Remember, back in high school, when your English teacher prescribed countless rules and techniques for writing well? Remember how we all quietly applied these rules? Why not? Who are we to disagree at that age? However, fast forward a half-decade or so, and you start to realize that so many of these "rules" are simply...gibberish. Does that remind you of any other industry?

Even a site as innocent and helpful as Laracasts has had its fair share of malicious users. It's a simple fact of the business. Are you lucky enough to have built a relatively popular product? Excellent! Now, get ready for the attacks.

Particularly when building open source tools, I think it's important to remember that the 100% goal is wrong. Or, in other words, when you repeatedly make compromises to make everyone happy, it might just turn out that you've made no one happy.

Rather than big New Year's Resolutions, I prefer to make three simple lists. Prioritize the things you love to do, incentivize the things you need to do, and optimize the things you hate to do. It's cheesy as hell, but stay with me...

There's no two ways about it: taking things too far is simply a rite of passage. Whether it's developers over-evangelizing microservices and command-oriented architecture, or guitar players forcing newly learned modes into their solos, we all take it too far...before finally pulling back.

So my wife and I recently took a trip into Nashville to see Amy Schumer perform. And wouldn't you know it: the moment we arrived, Bugsnag began sending me error reports. No laptop, and two hours from home. ...Crap.

90% of developers don't test their code. Made up percentages aside, I think you'll find that this is fairly accurate, when you gather the entire development community. How come? With so much evangelism across the board, what's the reason behind this hesitation?