Developing applications are fun. Whether you get paid to develop apps, or have to develop apps to get paid, the process of development is something I find to be so interesting and fun.
But the thing I absolutely hate? It is networking with other developers.
I can’t count how many times people have asked me what’s my favorite stack and side-eye treatment I have got when I say them the answer – PHP or Python.
Someone even asked me, “oh well, you’re still stuck on Laravel then?“
I got tired of answering everyone separately and decided to put up a blog online on why I do what I do, so if anyone to be curious, I could simply ask them to read the reason in my blog. Absolute brains – innit?
Before I explain why I do it on PHP, I have to explain how I do it on PHP.
In PHP, I use the approach called procedural approach. That’s to say, you will have all your working code at the top, and then use HTML as usual below and display data as needed.
Why it works?
Because it is simple, no dependency nonsense, and everything I need is already built as helper functions over the decades.
Why is the best?
Well, same no dependencies for one. I certainly don’t want to use tons of third-party code which I don’t understand in my applications to make it “modular”. That’s a serious security risk as well as performance bottleneck.
And apart from that, PHP and Python are something that I would call it as “Metal Level” coding languages. They interact with the hardware level without tons of layers on top of them. In fact sometimes you can go beyond the limits with C# with custom partitioning, memory optimization and more.
To me personally, languages like Py, Php and C# gives more control over the environment. I don’t have to worry about a thousand plugins or packages I have.
Why it sucks?
The control and optimization aspect is a double-edged sword.
You can keep your files anywhere. Organize them anyway you like. Keep your application distributed across nodes. These languages are so flexible that you can feel like you are flying once you get the basics right.
But at the same time, if you don’t keep your codebase tidy, it is going to become a hot mess. A non-performing, ultra-slow, unreliable piece of crap not worthy to be called as an application filled with bugs, bottlenecks and what not.
How you ask? Here’s a small backstory:
The year was late 2010s and I was expanding our company. As you might have guessed, I thought it was time to hire additional developers to get the work done. So I did hire a couple of new grads with PHP know-how’s with formal interview.
So the team was ready. There was a senior developer (new hire too) along with a couple of new Jr. Devs. I assigned them a project, handed over design docs, requirements and everything else. Months passed, project got completed.
Then I took a look at the codebase (I know, a costly mistake). I don’t know whether I can even call it a codebase, because what was in it was only chaos. Purest form of absolutely chaotic code I ever seen in my life till date. As a web host and cloud consultant, I see codebases everyday and work with bad-written code almost every hour and that says something.
At that point, I really understood why MVC is being adopted in every enterprise, particularly Laravel. Laravel is opinionated. It guides you on how exactly you should code. You are forced to keep your code tidy, or in other words, as they ask you to do.
And that’s why it worked for everyone, just not me who already is a perfectionist, who takes pride in having the no-nonsense codebase that’s highly optimized.
Very well.
That day I understood no two coders are the same.
There are people like me who loves to keep things optimized and obsesses over very small performance boosts. There are also people who work for the sake of completing tasks and taking paychecks.
And that’s why I believe that in an enterprise standpoint, where there are no KPIs to track a person and their style of work, it becomes very useful to have an opinionated framework which doesn’t accept anything else but cleaner code.
To this day, I take pride in writing procedural code. There’s a certain joy in having control to yourself in PHP and Python. But as they say “with greater power, comes greater responsibility” – that is very, VERY true. Those who cannot control, cannot have control. Simple as that.
We have a wonderful team to build and maintain procedural codebases now. It took me a while to get them to understand the nuances, and I am proud to see that some of the guys who generated mediocre codebase are now running enterprise-grade applications with better optimizations than what I would have thought of, initially.
As a seed that germinates and grows into a tree – a team does evolve. It takes patience, care and love to guide them in the right path. To make them understand how things need to be done. That’s an investment a leader makes.
But as always, would I recommend you to do this? No. Not without knowing you. If you love this, you should absolutely do it. If you love importing packages and boosting your time-to-market, then do that all the same instead.
There are no right answers here – as there isn’t anywhere else. It comes down to your vision, your situation, and your opportunities.
