1. Web developer

    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 time — I 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. Anyway… 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 difficulty — especially 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 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.
    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 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.
    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 and worked around or fixed in the past. Sometimes, new problems just smell like old problems, and the path to a functioning system lies in the experience of fixing the old problems. This one is hard to learn independently, and comes with time. I once heard someone say that airline pilots don’t get paid a lot because of their regular day-to-day flights (where autopilot and assisted-landing do the majority of the work). They get paid a lot because the few times in their career when they need to make life-saving decisions in the middle of an emergency; the still-alive passengers might think it’s worth it to shell out a few bucks more than minimum wage.

    TL;DR: don’t be a PHP/Python/Ruby/JavaScript/Logo/Erlang/ColdFusion/Perl/Scala/Go/Fancylang developer. Be a web developer. Learn your trade. Be an apprentice. Practice your trade.

    9 Responses

    Feed for this Entry
    • The hardest part of transitioning from PHP Developer to a Web Developer was the feeling of inefficiency. I would think "I can do this so much faster in PHP!" because I know PHP really well. I stuck with it though and the feeling goes away fairly quickly.

    • Rafael Izidoro

      2012 Oct 29 11:46

      You said exaclty what I think about these things. It's annoying this war about languages... "I can make a Hello World with just one line", "Javascript sucks, use Coffee", "PHP if for amateurs", "Ruby is for … lol"... and when someone face a real problem, "Oh …! Let's look for a new job..."

    • Maximilian

      2012 Oct 29 12:56

      Thanks for these hints. 
      At this Time i try to become a webdevoper. I think i know almost everything about my language php, but your hints are the thinks i am looking for to make the step to a webdeveloper. 

    • Spot on!
      I'd also add:
      5. databases
      to the list of skills a decent web-developer has to master

    • I always said that if I were to start teaching people "web development" I would start with HTTP first. No markup, no server side processing, just plain-ol-http. In my years of development, it seems that the first thing to trip up junior to mid-level devs is the transition between what happens where and how it gets there (if that make sense).

    • I have mixed feelings on this.

      While syntax isn't the hard part, certainly, but language isn't just syntax. The constructs and idioms inherent in a language greatly affect how you approach a problem, and proficiency (not to mention mastery) of the associated concepts takes much more time than syntax.

    • I agree completely to that. Indeed, we are currently looking for a web developer, not a developer knowing x, y, and z.
      Someone knowing to a certain depth about web development in one technology, will switch to another one easily, even more if there are gentle coworkers helping in the switch.

    • I once read an article that someone said something like: "Being a master of many languages provides no depth, being a master of one language and you can solve the worlds problems" or something like that. I guess the basic meaning was that learning every language under the sun might make you experienced in many things, but when shit hits the fan, you need to be a master in the particular language which is not behaving the way you expect. Every library & framework has it's intricacies, as does every language you may work with, some languages (php/python/ruby/perl) have more syntatic sugar and thus more complexities to their implementation. The key is to learn to become comfortable in learning new tools on the go, and hopefully you have a client or employer who gives you the time to do this. If you are lucky enough to work for a company, or even yourself to have the time necessary to learn many new languages at the same time, and also have the necessary patients and inclination, you will go far. All the things that @Sean has talked about are real & true, but the reality is look at what you currently know, and if you can accomplish most of what you need on a day to day, you should consider picking up a new language or a new "Popular" framework, you will never go wrong if you do, because languages & frameworks built communities and communities are what help produce jobs. Communities of people who use languages are what keep the work flowing because they get the word out to their employers and employers are part of these communities. Find one you like, and keep at it. But make sure the community is large. Just my 2 cents on making sure what you know / learn is not irrelevant. 

    • Nice thoughts, I can relate to this also, having recently learnt and am now moving towards Python development.

      I wrote about it http://blog.jmoz.co.uk/learning-python-the-pragmatic-way