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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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?
Let's take a break from code this week, and talk about the person behind the code. When I found out my wife was pregnant last year, a million different thoughts and concerns went through my head all at once. Having your first child is like nothing you've ever experienced before. If you have one on the way, here's what to expect...from a male's point of view.
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.
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!
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.
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.
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.
1. Why won't Laracasts expand to cover more technologies and languages?
2. What are your top three favorite podcasts?
3. Are Forever Plans smart business?
4. What's one piece of advice that you'd offer entrepreneurs starting their first business?
5. Will there be a Laracasts series on what's new in Laravel 5.3?
6. 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.
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.
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!
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.
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.
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?
If we're being frank, in the last month, I've felt somewhat burned out. As developers, it happens to us all at some point or another. Let's talk about that for a bit.
The concept of mental debt is something that developers never talk about. We're obsessed with pointing out technical debt, but isn't there value in worrying about our limited mental energy? There's only so much complexity we can take in.
Making the transition from employee to business owner is, to be frank, scary as hell. If you're not careful, you'll freeze. The "what ifs" will quickly assume command, and you'll once again fall back to the safe path. But, if you can fight it, there just might be something better on the other side.