I think around 2015, there was a big splash of good training online for PHP. Frameworks upgraded/changed, helped programmers write better code faster earlier than that. Before that, it was a lot of RTFM. So, before, in the earlier days (maybe somewhat still today), I think PHP developers did this:
- create crappy functional code
- create crappy OO code
- choose a random framework and mess up the implementation of it
- write your own framework
- choose you framework of choice and start to implement things great and rigidly to that framework
- create great code, using a framework as a tool and time-saver
I think some of these steps are skipped now because of the sheer size and quality of training that we have access to now these days.
However, I was talking to Big Boy the other day (you might remember big boy from entries such as these) He had a different explanation of the lifecycle of programmers:
- Stage 1: write shitty functional code
- Stage 2: write shitty half assed OOP code
- Stage 3: write awesome OOP code
- Stage 4: Write awesome functional code
- Stage 5: hack shitty stuff together based on business needs
I think I can agree with this, too. But, I want to abstract this a bit. What I think we’re both saying is that there is a progression of PHP (and other language) programmers that is manifested by the way we implement and use our tools at hand.
- brave new world of programming, you’re excited
- try to do better at it
- do the “best practices” of it according to “everyone”
- develop a flow that fits your logical brain/skillset best
- start to focus on creating efficient code that solves business problems, code is secondary to problem solving
I think the point I’m trying to make is - there are many ways to get to the end - but the end is crafting quality code, that fits you, that solves the business problems the best. All of those are equally important. Great code that doesn’t solve the problem - or shitty code that solves the business problem (short-term) will always be a failure.