PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

Web developer

Note: This article was originally published at Planet PHP on 20 April 4180.
Planet PHP

Over the weekend, I saw a discussion on Twitter about a particular developer who is worried about his future as PHP becomes less the de facto platform for all web development, and he moves to other technologies. (These are my words, and my interpretation, not his.)

This got me thinking about how I've recently gone through a similar change in how I think about my own career, and how I was in a similar place for a long time.

I've been doing PHP for a really long timea-aI remember toying with it in 1999, and I started working with it professionally, after stints with Perl and ColdFusion (laugh it up), in 2001. I have this theory that almost everyone who was doing web stuff before the dot-com bubble burst, and stuck to it, is probably a decent (or better) developer today. Anywaya for a long time, I considered myself a PHP developer. I even fought somewhat-zealous, and somewhat-religious platform/language wars when one company I worked at decided (and ultimately failed) to move to J2EE.

At work, we deploy code on many platforms. We've got PHP, Python, JavaScript, Ruby, and even Erlang in production. We're targetting Python and Flask for new projects, so we're all on the same page.

This weekend's conversation revived some thoughts I've been mulling over for a really long time. I no longer consider myself a PHP developer. Sure, the vast majority of my actual platform experience is in PHP, but I'd prefer to think of myself (and of good web developers in general) as simply a web developer.

The reason for this change lies in the fundamentals of the work we do. I've realized that it's the hard parts that matter, not a language's syntax or frameworks. The hard parts are things like security, architecture, HTTP, scalability, performance, optimization, debugging, and knowing how to identify problems. By comparison, syntax is the easy part.

For developers who are well-versed in these hard parts, working with a new platform is usually a matter of learning new tools, new methodologies, and new libraries. In my experience, there's certainly a learning curve to these parts, but it only requires research and practice if you're already good at the hard parts.

These hard parts are what separate great developers from amateur developers. Learning something like web security, solidly, takes potentially years of paranoid practice and review (even though the fundamentals are simple). Learning something like pip, gem or composer isn't even in the same league of difficultya-aespecially if you're familiar with the concepts of a similar tool on another platform.

So, experienced developer-friends who are already intimately familiar with one platform: fear not; the best of your skills are transferrable.

For those of you who might not be so experienced, I'll make a recommendation: learn, practice, and find a mentor for the following; these skills are what I look for in colleagues.

HTTP HTTP seems WAY easier than it is. I suppose that's kind of the point, but in practice, HTTP will trip you up. It will find your code in a dark alley and do unspeakable things to its clients. For this reason, you must be prepared for battle by learning the gory details of cookies, sessions, headers, keep-alives, caching, proxies, and load-balancing. Really. It's way harder than you think. Security The fundamentals of security are easy, but within these fundamentals lie an unimaginable amount of nuance. Learn about CORS, browser implementations, CSRF, XSS, header injection (well, actually, all types of injection), sandboxing, client security, mobile security, SSL/certificates, and databases.Scaling Scaling and performance are different things. In order for something to scale horizontally, some basic principles must be applied to your application. Learn about resource sharing, node isolation, sticky sessions, client-cookie-sessions, load balancing, data partitioning, sharding, and caching.Debugging One of my greatest skills as an experienced developer is being able to identify problems. These days, when I encounter a tough new problem, it usually reminds me of a problem I've experienced

Truncated by Planet PHP, read more at the original (another 897 bytes)