I personally believe (in my experience), that developers who hate testers have huge egos. As much as I (as a programmer) can think of all possible scenarios - it is up to the tester to actually prove me wrong. IF the testers has managed to break my code - I have to yield and fix it because I am at fault.

Everyone's answer are great. One thing I would add is: You should always learn "root" programming languages in order to appreciate modern languages. C and C++ - you dont have a string class. you have to manage pointers. ITS SUCH A PAIN - however on the flip side - you can learn a lot about class constructions this way too. Some may argue that it is not needed however root basis languages are very helpful (also considering it is core to Linux boxes). Another similar trend would be why learn jquery when angular and vue does everything for you. A) that is not true b) you will always be able to appreciate and refactor code that spawn from the root programming into the more modern one. At the University of Concordia during my 4 year stay I saw them flip from C to C++ to Java in terms of intro to OOP. C was harsh - C++ was rough and Java after a while you appreciate it only because you went through C and C++. If you are asking this question due to a time factor, my answer is still the same: you will know more about how internally other languages work if you know the the parents of the language (ever wonder why memory management is important ... its about them pointers and other things)

looking for something in the middle of laracast forums. where noob questions may go into tumbleweed but at least you don't get castrated like Stackoverflow.

@mgiambanco Fair remark - here is an explanation: If you are a complete noob - yes go for a project BUT make sure its a small one. Don't go for a full CMS for example (hence big) - yes a CMS can be big - ie think wordpress ...its not a light weight thing now is it? Take any github project out there (since its open source) and see if you can tinker with it - visit stackoverflow and take any give project that someone asked a question there and work on it yourself in another language (if you do it in another language - you won't feel compele to think in the language you just learn, you might end up copy paste). For the more advance people (seasoned people) - lets say you went to laracast - just learned vue.js 1.x and you've been trained in Angular.js - maybe try to see if vue.js is good for you .... reformat your old angular project into vue.js to see if it fits. Start one from scratch and make side by side comparison. Etc etc Bad Habit vs Good habbit. Internet + blogs - there is an over abundance of code out there - you can't learn that a bad habit is bad if you never seen a bad habit. promise vs callback for example or old mysql_query vs PDO (whomever is reading this - yes yes never go back to mysql_query ...but first tell your employer that he/she is a dunce for not upgrading their project's PHP first ugh....). There are countless ways of doing loops ... for, while, foreach .... collections->each etc...you have to start somewhere. Also the author of this post never stated he was a beginner, what If someone picked up Jeffrey way or Adam Wathan's tutorial about collections and TDD course. I would be on the look out for my own code after reading and go "it worked but I feel It would be better this way" ... it might fail or it might not.

forget project - project is too big scale and will make you think too much. Can you find a situation where you can apply what you learned, i.e. refactor. Refactoring something old into something new and does it work well in your eco-system means that the tutorial you just watched is useful. If you try to apply everything you have learned - you will be jack of all trade and master of none and being master of nothing only get your feet wet but you never become immerse into it to actually see how useful the book/tutorial is. Furthermore a tutorial is a stepping stone. You need some bigger scale application in real world to see if what you have learned is useful.

clean-code: as much "SOLID" and "DRY" principle as possible - HOWEVER let us not be fooled - don't start morphing your code because you got 4/5 of the solid and you really want to fit your code in. Simple and concise classes that don't make a coder go and read how the code is created in the core is very helpful and classes/functions that are intuitive without the need to switch back to documentation (though adding documentation to code helps). Finally: least amount of comments in function headers help (if i need to read a paragraph to know what that piece of code does means it smells IMO)

Silex / Lumen They both provide minimum bootstrap. Reading your comment about millions of records - has nothing to do with your framework and has all to do with SQL queries and how you code. People who bash Lumen/Laravel + Symfony/Silex because its PHP and hop into NodeJS because of raw performance doesn't understand the architecture of scalability. Both provides json output which is what you need as an API (try not to give back XML, as i will go Liam Nielson on you) Request objects to ease up the code able to bootstrap various ORMs to your framework (yes lumen is compatible with eloquen since the core is the same - however you can bootstrap silex with eloquent since illimuminate /eloquent can be part of your composer) LTS both provides LTS support I'm partial to Lumen because of pure community helpers - however if you try to do anything advance you might be stuck in a bind as i have faced. There are more out of the box packages compatible with Silex than Lumen/Laravel - however the community is getting more and more support to dev out compatiable drivers/packages. Watch out for documentation also - a lot of laravel base operations cannot be done in Lumen because it is a minimal framework - the minute you creep out of scope - you will want to ponder if it is not best to move to the big brother laravel in the end.

As much as I like SO and use it - I try not to. 1) too many opinions going around 2) unless you have a great title - you won't get noticed including a bounty 3) not enough high level helps 4) too many repeated beginner helps `

@mevrael has too many concise positive and realistic points that make Laravel a great framework, however, if you listen to Taylor's laravel Postcast (creator of the magnificent framework), he actually branched off from CI into Laravel and he was also once a CI user. As @mevrael mentioned: Business Needs Over fandom... If your business is xbox exclusive but you are a ps4 fan boy, you will learn xbox sdk one way or another. being a new developer I always suggest to go the harder route in order to appreciate what the better framework has. Let us not forget that by default Laravel used to be symfony driven (and there are still a lot of component from symfony that is still in the core) therefore if you know symfony first, transitioning into laravel will make you appreciate it better. Same as CI goes back when it PHP wasn't composer driven. I personally prefer Laravel over CI because all point raised by @mevrael, however I bare no ill will towards CI because I came from CI when CI was the choice over cake and zend.

@emilmoe if you have tested in 5.2.31 then you should update your doc right?