Larry Garfield has been developing websites since he was in school and is been in the development industry since he was a budding child. Before his name was applauded as a top PHP influencer in the industry, he first served his major time as a freelance developer whose love interest was to develop different websites and learn the art of diverse programming. Being a PHP development expert, Larry is currently Director of developer experience at Platform.sh. So here at Cloudways, we have conducted an interactive interview session with Larry Garfield to know his experiences about development and Drupal industry.
Here’s what he has to say about it:
Cloudways: Hello Larry! How are you? Thank you for taking out your precious time for this interview! Could you please share some highlights of your career as a developer? What motivated you to choose this field as your profession and develop websites from high school?
Ans: Oh dear, you’re asking about ancient history… My father was a history professor at DePaul University for years, and as his son I was the precocious kid who always came into fix everyone’s computers (where “fix” meant I knew how to move icons around in Windows 3.1). So I had a reputation as the computer department geek from the age of 13. In 1996 when the school told the department that they had to create a “site” on this new fangled thing called “the web”, they drafted me. I didn’t know anything about building websites at the time, so went out and bought “Creating Cool Web Pages with HTML 1.1” and started working. And the rest, as they say, is history.
I also took a detour through IT journalism and Palm OS development, but that’s a whole other saga.
Cloudways: You started development since long ago, possibly in young age and became a successful freelance developer. So how was your experience of freelancing? Can developers go for full time freelancing as career?
Ans: Being a freelance developer is absolutely a viable career, but not for me. You have to be really good at the “hussle” and the business side of things. In college, I worked mainly for local politicians as a tech consultant, and I had a few other clients afterwards, but I never built up the network I needed to make it work. Instead I started working for an agency, which suited me much better. I often joked that I hated the business side of consulting so I hired my boss to do it for me.
Consulting was fun for a while; every few months I had a new project to work on, essentially greenfield. The downside was that after every few months I was on a new project and long-term evolution and improvement weren’t part of the game. “Do it fast” always conflicts with “do it right”. Eventually I got tired of it and moved to a product company (Platform.sh), which I’m enjoying a lot more at the moment.
Cloudways: Drupal is also built on PHP and now its core has been migrated to Symfony framework. So are you satisfied with the current version of PHP? What new features you suggest to add in new versions of PHP?
Ans: PHP is one of the most rapidly evolving languages in the market today. That can be good and bad. We’re fortunately a long, long way from the dark days of PHP 4 and early PHP 5 when we were stuck in a chicken-and-egg upgrade problem. At the time, I kicked off the GoPHP 5 initiative in order to make it possible for me to use PDO in Drupal. (Yep, it was mostly selfish, but I’m happy that it moved the whole community forward.) A massive initiative like that isn’t needed today as the language is more forward compatible and the community more aggressive in pushing updates, and we’re a better community for it.
I’m really happy with recent developments in PHP; PHP 7 is delightfully fast, stricter typing is wonderful, and I find myself in love with generators lately. Most of what I’d still like to see added boils down to more functional, declarative, terse options for common cases. Typed object properties, object property accessors, comprehensions, short lambdas, and other functionality of that sort are all on my Christmas list.
Much of the really exciting work in the PHP ecosystem these days is outside of the engine itself. Efforts from the PHP Framework Interoperability Group (PHP-FIG), the development of Composer and its ecosystem, and other similar developments have really transformed the community. PHP today is almost nothing like PHP 15 years ago; we’re way better than that. I’m happy to see those developments continue and to be part of them. (I’m an active member of the PHP-FIG.)
Cloudways: Larry, You have done a lot of open-source contribution over the years. So please elaborate how a budding developer can get started to contribute in open-source projects. What value does it adds to the developer’s career?
Ans: I have extremely mixed feelings here, to be honest. I am a firm believer in Free Software, on moral grounds. People have a right to control their own computers and digital lives, and Free Software offers that protection better than anything else right now. Open Source as a development model (which is not the same thing) also tends to produce better software in the long run, although not always in the short run.
Some of the most amazing people I’ve met have been through Open Source projects, and it’s also a great way to learn from others. But there’s also an ample supply of jerks in Open Source, too. It’s not immune to human frailty.
Too, our economy has become far too dependent on the free, volunteer labor of unpaid heroes who get far too much grief for not donating even more work for free. I’ve written about the ways in which Open Source is Awful (https://steemit.com/opensource/@crell/open-source-is-awful) before, so I won’t repeat myself here.
My recommendation is to spend time volunteering on Open Source projects (you own or someone else’s) to the extent you find it personally rewarding or educational, and to the extent that it looks good on your resume. But do not let yourself fall into the trap of your volunteer work becoming a dependency for someone else’s work. If that happens, and someone starts guilt-tripping you into doing even more work for free just to help them, start charging for it. You don’t owe *anyone* free time. (Except your parents. Always help them out if you can.)
Remember: Neither Free Software nor Open Source require you to give your time away for free. Value your time; find a job that will pay you to work on Free Software, be it freelance or for a company. Don’t let it turn into “spec work” for you.
Also, not all Open Source communities are created equal. If you find you don’t fit well with one community or another, or are not treated well by it, get out and find another one. You have no obligation whatsoever to put up with stupid.
Cloudways: For rapid application development, one of the toughest challenge is the choose right PHP framework. How do you think Symfony and Laravel best fits this requirement? What should be the criteria for framework selection?
Ans: Oh dear, are you trying to get me skewered? 🙂
In all honesty, I’ve never used Laravel. I’ve seen various demos of it, read some documentation, etc. but I’ve never built a site with it. So take my views with an appropriate volume of salt.
The historical answer has been that Laravel is better for “quick and dirty” site that won’t need to be maintained over the long term while Symfony had a higher learning curve and was harder to bend to your will but would give you a more sustainable product. I don’t think that’s true anymore. Laravel clearly does have long-running sites built on it. And with Symfony 4 Flex, the Rapid Application Development experience of Symfony is way smoother than it used to be. I would say Symfony has definitely closed the RAD gap with Laravel, and what you get out of it will be more elegant and maintainable than global functions wrapping calls to a global container.
At the end of the day, the best framework for a project is the one you’re most familiar with, and/or you can most easily get help on when you’re stuck. For me that’s Symfony. For someone else it could be Laravel, or Zend Framework, or Slim, or Cake, or whatever. None of them are bad choices, just familiar choices.
Cloudways: You always discuss lot about performance and security of web applications and recently you have given a nice response to my tweet regarding PHP performance as well. So in your point of view what are the key aspects which can give performance boost to PHP applications?
Ans: Most of the time, the way you write your code is going to be less important than factors outside of your code itself.
* Always run the latest version of PHP. (If you’re not already on at least PHP 7.0, you don’t care about performance.)
* Minimize your IO (eliminate SQL queries)
* Make sure your server (nginx, PHP-FPM, SQL, etc.) is properly configured. (That includes good indexes in your database.)
* Don’t do things that are known to be super expensive along your critical path, but outside of that go for whatever is most readable/maintainable.
* Profile before you refactor for performance.
In general, clean, well-decoupled code is going to be faster than spaghetti code. And if it’s not, it will be much easier to clean it up to make faster. (I’m quoting someone else here, but it’s absolutely true.)
Far too many people focus on “user experience is everything” or “shipping is everything” and ignore the fact that you can’t get a great user experience without investing in it. That investment comes in the form of good design for the user but also good design for the code. Good, clean, well-decoupled code that is easy to refactor when needed will let you improve performance when you need to, improve the user experience when you need to, and will be much easier to secure, to boot.
Everything else is just implementation details.
Cloudways: Developers from other languages often criticizes PHP. Any suggestions or advice to those people?
Ans: If you don’t hate a programming language then you haven’t used it enough. I firmly believe that is true of all languages.
Every language has warts, design flaws, and legacy decisions that can’t be gotten rid of easily. PHP has them but so does every other language. I like Go, for instance, but could rattle off a list of things I dislike about it. There’s a long list of issues I have with PHP, but it’s still the language I use the most by far. And with 80% of the web running PHP it’s clear PHP’s warts haven’t gotten in the way of success.
Finally, it’s OK to not like a language. Really, it is. But that’s not the same as the language being bad, and it’s immature to confuse the two. I personally do not like Python much at all, but it’s clearly a successful language that gets the job done and is growing rapidly in popularity. It’s obviously doing something right.
Cloudways: Larry being a director of developer experience at Platform.sh, would you recommend cloud servers to the scalable projects or shared hosting servers? How the developers choose hosting for their needs?
Ans: Your choice of hosting environment depends on your use case, and the “best practices” and trade offs are constantly evolving. What I would have recommended 5 years ago for most developers is not what I’d recommend today, and in 5 years I’ll probably be recommending something else. Don’t get too stuck on a particular approach or a particular marketing pitch; get stuck on “what serves my needs best?” Largely it all comes down to what kind of flexibility is important to you.
A PaaS such as Platform.sh works best for cases where you want to focus on your application and data and not worry about servers. With Platform.sh, you pick your PHP version (or Node version, or Ruby version, or whatever) and go. You don’t need to pay attention to “What version of Nginx am I running?” or “what’s the most efficient way to clone this data to a staging environment?” or “Is there a Linux kernel security release this week?” You just deal with your application and the configuration it needs. Cloud computing has largely decoupled physical hardware from logical resources, and that’s a good thing. It’s now very easy with a good cloud host to “throw more resources at it” when needed without worrying about hardware.
I firmly believe that is the best approach for most web developers today. It gives the most flexibility that you really care about for the least incidental effort. However, it does have its trade-offs. If for some reason you really do are about the exact version of Nginx you’re running, or you need a very precise non-standard PostgreSQL configuration, or you need to run some extra obscure additional software that your host doesn’t support, then you’ll need to manage your own systems on a lower-level Infrastructure provider. But then you’re also on your own for the care and feeding of those systems. Sometimes that’s a worthwhile trade off, but usually not.
At the other end, many sites don’t even need a custom developer. If your site is “a dozen pages and a blog”, then an all-in-one platform with a built-in web-based editor is probably going to serve you better than getting a “server” in the first place.
Ultimately the decision boils down to “how much flexibility and control do I *actually* need?” vs. “how much time and effort am I *actually* willing to put in to babysitting my application and infrastructure and getting it all right?” Different projects will have different answers to that, and you should go with the hosting provider that offers you the trade-off you’re most comfortable with.
Naturally I would argue for most project’s that’s Platform.sh, but I am maybe just a little bit biased.
Cloudways: What do you think about managed hosting solutions like Cloudways, which provides a full-featured and highly optimized PHP stack with Laravel and other applications? Do you think that managed hosting solutions help developers kickstart web projects without worrying about server management issues?
Ans: This is largely the same as the previous question. When you use a web host that is further “up the stack”, you are trading some control for not having to worry about some problems. Most of the time, especially when just starting out, that’s a good trade.
If the web application you’re building relies mainly on well-crafted PHP, you probably don’t want to also be bogged down by server management. If the web application you’re building differentiates itself by a novel, elaborate assortment of custom daemon processes, you probably need to control your own servers.
The former outnumber the latter by at least 50 to 1.