Codyssey.dev @codysseydev

📢 The first course Building Maintainable PHP Applications: Foundations is now live on @codysseydev Over the years of working on startups, scale-ups and enterprise products, I've noticed that most codebases end up in the same place: hard to maintain, slow to change, painful to work with. It doesn't matter how successful the product is or which framework it's built on. Something about the way we think about code pulls projects toward the same fate. This course is not about patterns, frameworks, or "clean code" rules. It's about the mindset that comes before any of that. It's the course I wish I had years ago, because most tutorials, books and academies focus on the basics or the short term, but very few talk about what happens to a codebase after year two, year three, year five. More theory than code, and that's intentional. You need the "why" before the "how" is worth anything. codyssey.dev/courses/buildi…

It’s been a while since I posted about the status of my project @codysseydev The good news is that the product is fully finished and in production, and I’ve been working on the content, slowly releasing and scheduling the draft content that I have planned. It’s going to take a while to get so much free and paid content on the site but at least it’s not fully empty right now. I am also bringing all of my old articles to Codyssey but this time I reworked them to be better. This means that I don’t have a personal blog anymore since I redesigned it recently and all of the written content will now live on Codyssey. Currently, I only have some free content, one published course, one learning path, two insights and a few hundred community links (articles, books, videos, video courses etc.) but there’s a lot of content scheduled or in draft. If you are curious to see the platform and start learning stuff, visit codyssey.dev and let me know what you think about it. It took me a long time to build it, and I should’ve talked more about it but I’ll be more active now so expect a lot of content to start showing up everywhere.

📢 Codyssey Phase 1 Update We are really close to releasing the first phase with free content of @codysseydev to the world! The platform is almost ready, we are in the last phase of testing and polishing it. The plan is to release the platform this week if everything goes as planned. Here's a sneak peak demo video of the platform, how it will look like with some dummy content. If you want to keep up with the updates and stay in the loop when we release it officially, subscribe to the interest list at codyssey.dev

💡 Top 20 mistakes PHP developers make when they use Laravel I have been working with Laravel for about 10 years now and I have seen how people use Laravel in both startups from scratch as well as the enterprise BigTech world. I've also done some of these mistakes myself but I've also had to figure out workarounds to solve some of these problems when working on long-term projects. Here's a list of bad practices people (including me) use or have used in the long-term projects I've worked on: 1. Injecting controllers into other controllers or even models in order to reuse some code 2. Saving or updating data multiple times during the same use case 3. Using the $with Eloquent model property to eager load relations by default for every query 4. Executing additional queries within Eloquent model accessors 5. Using Eloquent for very complex queries 6. Using arrays everywhere 7. Selecting all table columns by default 8. Using Auth::user() or Auth::id() in a service or action class 9. Passing around Eloquent objects everywhere 10. Using `$request→all()`, `$request→validated()` and similar methods 11. Using a single API endpoint for multiple use cases 12. Forgetting to validate the requested data 13. Implementing important business related code in traits 14. Using a single form request for both create and update endpoints 15. Not splitting the code into multiple files when it becomes complex 16. Using primitive values everywhere instead of objects 17. Using the default folder structure 18. Using `app(SomeService::class)` (service location) instead of dependency injection 19. Sticking to MVC as much as possible 20. Loading all of the data from the database and processing it in PHP I'll be expanding on these ideas over time as well as release a detailed insight on @codysseydev when it launches next month.

✍️ The initial planned content for @codysseydev There's a lot of technical and non-technical content I want to write about and showcase examples from a different point of view but this is something I am currently planning to work on as a starting point. - Building maintainable PHP applications (Free Text Based Course) - it will cover general ideas about software architecture, design and planning. - Building Codyssey (Free Text Based Course) - The experiences of building Codyssey - Top 20 mistakes that Laravel developers make when building long-term projects (Free Insight, possibly split into multiple insights or a series of insights) - Top 10 books for PHP Developers (Free Insight) - Top 8 Code Quality Tools For PHP Developers (Free Insight) - The difference between Software Engineer and Software Developer (Free Insight) - How to plan software as a service products (free text-based course) - it will get into the details of planning a software as a service product (covering both technical and non-technical planning) - Different types of software architectures (free text based course) - it will cover the different types of software architectures and their pros and cons when used in different contexts - PHP Mastery (free learning path) - Everything related to learning PHP from the basics up to the most advanced content and its ecosystem - Laravel Mastery (free learning path) - Everything related to learning Laravel from the basics up to the most advanced content and its ecosystem - Symfony Mastery (free learning path) - Everything related to learning Symfony from the basics up to the most advanced content and its ecosystem - Building a Learning Experience Platform (paid text-based course) - it will cover everything from planning, designing and architecting to building and deploying a software as a service product - Building a All-In-One Restaurant management system (paid text-based course) - it will cover everything from planning, designing and architecting to building and deploying a software as a service product - Refactoring LifeOS - refactoring an existing open source Laravel project built with vibe coding Additionally, I will be reviewing some code from existing open source projects and we will be discussing the pros and cons of each approach focused on long-term maintainability and support. You can always share some ideas in the comments so that I can add them to the list but the list above might already cover most of the things you might be interested to read and learn about.

💡 Vertical Slices in Laravel Laravel comes with a folder by type folder structure which is fine for small projects in which you are the main developer but that doesn't scale well in a bigger team on a long-term projects. Why? The folder structure doesn't tell you what the project is about, or how many projects are in there, as well as it doesn't tell you the features of the project. It will take you months or even years to get to know what features the project has and where are all of the files for a specific feature. All of the files are scattered around and hidden away. A monolith can have 5, 6 or maybe 10 projects (or more) into a single monolithic project GitHub repository. Vertical slices solve this problem by colocating all files grouped by domain / bounded context / module. The hardest part of figuring out vertical slices is understanding of what the business is about and how it works from a product point of view to be able to figure out how each domain communicates between the modules / domains. Imagine that you are joining an e-commerce project with 10 teams and each team works on and owns a specific part of the system. One team works on the Order Fulfillment domain, another team works on a Warehouse Management domain, the third team works on an admin panel / content management panel for the internal team, the fourth one works on the Customer Portal and so on. If you join the Order Fulfillment team, you will most likely get up to speed with the domain very quickly because everything is grouped by the domain you are working in. This may not make sense to you if you are the only developer on a project who knows the project 100% (both from a product and code / technical point of view) but vertical slices are awesome for small teams as well. It offers you to set things up for the future so that when the project scales up in number of people, code, complexity and features, you will be able to quickly get up to speed about the project and find the things you are looking for easily. To set these things up, you don't need any packages, all you need is to set up the service providers to load files from different places. The best part about vertical slices is that besides the visibility and understanding of each domain / module is that you can create an infinite amount of files (as many as you need), you will know where to put them and won't be scared to move code around, because everything you need to look at is just one domain / module, not having to jump between a bunch of folders all over the place. If you ever need to split the modules out of the monolithic project and deploy them as separate projects, you should be able to easily move the folders from one project to another if done correctly. The first picture shows an example of how Vertical slices may look like in a Laravel project, taken from the @codysseydev codebase. Everything related to Codyssey lives into its own Codyssey main namespace. Codyssey has a Learning domain / module which is the main domain / module of the product. Everything about the courses, learning paths, and the other types of learning resources live in the Learning module (see picture 3 and 4). Same folder structure is set up for the other domains and subdomains / modules and submodules. Now that the project has a way of structuring files, it's easier to figure out a way to add the code related to the Membership Dashboard, as well as the future Mentoring domain that is coming next year. As Codyssey is being built, I'll be sharing more examples of how the code is structured and how it is written to showcase that it's not too hard to do it, but rather it's just different. It may take you a while to get used to thinking differently about structuring folders your applications, but I highly encourage you to experiment and try things out to see a different approach to building software.

keyboard_arrow_left Previous keyboard_arrow_right Next

📢 Introducing Codyssey (@codysseydev) Codyssey is a an educational online platform that helps software engineers learn how to build and maintain long‑term software products, not just ship quick demos and prototypes that are not ready for production. The platform will offer content in a form of: - Text-based courses - Self-paced learning paths - Quick tips - Useful community links - Insights - In-depth code review analysis The content will be about: - System Design - Software Design and Architecture - Software Planning - Software Design Patterns and Principles - Legacy code refactoring techniques - Infrastructure design and setup - Quality assurance and testing Additionally, there will be other types of content related to being a software engineer (career advancement, leadership, communication, product management etc.) The content will be focused on real-world scenarios from a long-term product building point of view. It will showcase multiple different approaches of building products and comparing them for different types of contexts (MVP startups vs multi-year successful startup / scale-up / enterprise products). The content will be theoretical where the concepts and ideas will be explained with detailed examples and later on showcased in a practical product building courses where multiple concepts and ideas are combined so that software engineers will be able to understand the big picture and see how they can use them in their own projects when they make sense based on their own context. Codyssey will bring a fresh perspective on technical and non-technical content which will expand the ideas of existing video tutorials, blog articles, books, conference talks and other types of learning resources. The initial content will be mostly focused on PHP (Laravel and Symfony) as well as other PHP related tools and frameworks which are part of the PHP ecosystem but the content is meant to be language and framework agnostic as it will expand into or be combined with multiple other ecosystems over time. The content will help software engineers who already have some experience building products and want to expand their knowledge beyond the MVP project building phase. There will be content for people at all skill levels. Here's a rough timeline of the initial releases: Phase 1 (free content) is expected to be released by the end of 2025. Phase 2 (paid content) is expected to be released by the end of June 2025. Phase 3 (online 1 on 1 mentoring) is expected to be released by the end of 2026. If all of this sounds useful to you and you are interested in following the journey, check out the coming soon page and and subscribe to the interest list at codyssey.dev

Forge Your Path to Software Mastery Set sail beyond quick demos. Embark on a voyage to master the craft of building enduring software. Navigate by proven principles through text‑based courses, code reviews, guided paths, and curated community resources. codyssey.dev