Introduction
I sometimes get emails, Twitter messages, and LinkedIn messages from developers asking for hands-on approaches of how they can improve as Laravel web developers.
There is a huge amount of amazing content out there, such as blogs, books, courses, videos, and podcasts. We're really spoiled for choice! But sometimes getting hands-on with code can help you to understand certain concepts and topics that might be a bit difficult to understand without context.
So I thought I'd put together a Quickfire post talking about how reading through the Laravel codebase and packages can help you to improve as a developer.
It's also worth noting that everything I cover in this post isn't specific to Laravel. You could also use these same approaches in other frameworks and programming languages.
Learning from Laravel
Not only do I like to use Laravel as a tool for building awesome web applications, I also use it as a learning resource. Laravel is over 10 years old now and has over 2970 contributors. So, it's had a lot of great developers' eyes on the codebase to help shape the framework into what it is today.
I like to use this to my advantage and improve my skills as a developer by reading through the framework's code.
For example, if I'm using a method that's provided by the framework (or any packages), I like to inspect the method and see what it's actually doing. By doing this, it allows me to do multiple things:
- Check that the method I'm using is in fact the method that I need. While searching through a class, you might find that there's actually another method that would be better suited for your needs.
- Read through the method and see how the solution has been implemented. This can help to expose you to new ways of thinking and approaches.
- Improve your knowledge of the inner workings of a particular feature.
More often than not, I find that I end up going down a rabbit hole and reading more into how the feature is implemented as a whole, rather than just the specific method. To give an example, let's say that I'm implementing some caching and using the Cache::rememberForever() method in my codebase. From here, I might check to see how the rememberForever method is implemented for the particular cache driver that I'm using. I might also check to see if there are any differences between the ways that the different cache drivers implement this method. From here, it might also spark more questions about some of the code in the caching feature and lead me to researching online.
Now, don't get me wrong, this isn't necessary at all for development and it's not something that you need to do. However, I've found that it works really well for me and has helped me to improve my skills and understanding as a developer. I feel like it gives me a good chance to sit down and take a look at problems from a different perspective.
Sometimes, it also leads to me asking myself "Why is this feature been implemented this way?". I then end up reading online through GitHub issues, pull requests, forums, and discussions to get an understanding of the context behind the code. I find that this is a really good way of finding out about different design patterns, best practices, or approaches that I hadn't heard of before.
You might think that this approach may take a long time. And it definitely can do! But you can spend as little or as long doing this as you'd like. Maybe you'll just want to quickly inspect a method that you're using and nothing more. Or, maybe you'll choose to go down a rabbit hole like I sometimes do. The choice is entirely yours.
Another great benefit of doing this is that you might also find some code in the framework (or package) that you think you can improve. This could lead to you tinkering with the code, thus helping to improve your understanding even further, and maybe being able to make a pull request to contribute. You may also spot bugs or places in the documentation that could probably be improved. So, as a bonus side-effect, you might be able to make a pull request to update the repository. This could lead to you becoming an open-source contributor, which can have some huge benefits for yourself and the web development community.
Learning from Packages
You can also use a similar approach when you're working with any packages in your code.
So if you're thinking of using a new package in your project, you may want to spend a few minutes reading through the package's code before you download it. This will help to give you an understanding of how the package is implementing the features that you need. As a result, this can give you further exposure to other peoples' ways of thinking.
In the past, this has sometimes led me to actually opt against using a package and writing the code myself after realising that the solution was really simple. On the other hand, it's also sometimes led me to using the package because I've realised that the feature was a lot more complex than I imagined, and I wouldn't want to write it myself. I've briefly touched on this in the past in my "6 Quick & Easy Ways to Speed Up Your Laravel Website" article where I discuss being more selective with the third-party dependencies you use and asking yourself "Do I really need this package?".
In particular, I learned a lot from Spatie's Laravel Permission package (spatie/laravel-permission). In a project, I was tasked with implementing roles and permissions using this package. So, while I was adding it to the project, I read through the package's code and it gave me a better understanding of how the authorisation system in Laravel works. So, as a result of this, I started to feel more confident working with roles, permissions, and the authorisation system in Laravel. Since working on this project, I've implemented this same feature on multiple other projects and have felt more comfortable due to the fact that I have more of an understanding of the authorisation internals.
Research One Area at a Time
Another approach that I really like to use is to split my reading up into smaller chunks. I do this by dedicating 10-20 minutes a day to reading into a particular topic and avoiding context-switching.
For example, let's say that I've decided I want to learn more about how queue system works under-the-hood in Laravel. So at the end of the day, I'll spend 20 minutes reading through different parts of the queue system code (and documentation). Once I feel like I've read through a significant part of the queue-related code (after a week or so), I'll then move on to another topic that I'm interested in. Staying focused on a particular area or topic, makes it easier to remember what you were looking at the day before, rather than changing topic every day.
By doing this, I feel that it makes future development easier when working around a particular feature because I have a better understanding of what is available and how it works under the hood. This doesn't mean that you need to know the feature's code inside and out, but having some exposure to the code and understanding it at a high-level can definitely be useful.
Having a high-level understanding of something's inner workings is a skill that isn't specific to development either. It's something that can be transferred into the physical world. For example, let's say that you have a car. If something breaks on it or needs replacing, you might want to take it to a mechanic. But if the issue is only something small and you have a high-level understanding of what the issue is and the area that it's affected in your car, you might be able to fix it yourself. This is a skill that you'd probably only have picked up by diving in and tinkering with it. Having this knowledge might also make things like buying a car easier in the future because you'll have a better idea of what things to look out for and what things to be aware of.
But going back to Laravel, if you're looking for a starting point of different areas to read into, the following topics could be useful:
- Authentication (guards)
- Authorisation (gates and policies in Laravel, or Spatie's Laravel Permission package)
- Exception Handling
- Logging
- Eloquent
- Collections
- Queues
- Caching
- Events and listeners
- Validation
- Routing and middleware
Conclusion
Hopefully, this post should have given you an insight into how you can look at the code within the Laravel framework and any packages to improve your skills as a developer.
If you enjoyed reading this post, I'd love to hear about it. Likewise, if you have any feedback to improve the future ones, I'd also love to hear that too.
You might also be interested in checking out my 220+ page ebook "Battle Ready Laravel" which covers similar topics in more depth.
If you're interested in getting updated each time I publish a new post, feel free to sign up for my newsletter below.
Keep on building awesome stuff! 🚀